Google SecOps CVE-2026-15587

Exploitation requires the attacker to already possess a valid authenticated account on the Google SecOps (Chronicle SOAR) platform (CVSS PR:L), and to be able to reach the service over the network (AV:N) with no user interaction (UI:N). The specific technical prerequisite named in the description is the ability to supply a crafted internal authentication header that the backend improperly trusts - i.e., the vulnerability lies in the platform's internal service-to-service auth header validation. Limiting factors: the flaw is only exploitable against versions prior to 6.3.85, and only during the window before Google's server-side patch; because the product is a vendor-managed cloud service, self-hosted/default-config exploitation by end users is not applicable post-patch. No unauthenticated access path is indicated.

The signals point to a genuinely high-priority issue but with meaningful mitigating context. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) indicates network-reachable, low-complexity exploitation requiring only low existing privileges and no user interaction, with full impact and a scope change - hence the 9.4. However, PR:L confirms the attacker must already hold an authenticated (low-privileged) account, so this is a privilege-escalation primitive rather than a pre-auth breach. No EPSS score, KEV listing, or POC was provided in the input, and no public exploit is identified at time of analysis, so there is no evidence of active or automated exploitation. Critically, because the product is a Google-managed cloud service that was already patched server-side with no customer action required, real-world residual risk to customers is effectively neutralized - the CVSS score reflects intrinsic severity, not current exposure. Note the vector includes a non-standard 'U:Clear' urgency flag from the vendor; treat the 4.0 base metrics as authoritative and the urgency annotation as informational.

An attacker who has obtained a legitimate low-privileged Google SecOps user account (e.g., a standard SOC analyst login) crafts an internal authentication header and submits it to the platform's API. Because the header's origin is not properly validated, the request is trusted as coming from an internal system component, granting the attacker system-level administrative access over the SOAR tenant. No user interaction or additional exploit tooling is required, though no public POC is identified at time of analysis.