Google Application Integration CVE-2026-85298

Requires an authenticated user with at least low-privilege access to Google Cloud Application Integration within the target project (PR:L), plus the specific attack requirement implied by AT:P: the attacker must exercise the AuthConfig validation and integration execution runtime path in a vulnerable (pre-2026-08-27) version so that incorrect authorization permits binding execution to a higher-privileged service account. Limiting factors: no path exists for unauthenticated/external attackers, the attacker must already be a tenant/user in the project, and the flaw was fixed server-side on 2026-08-27 - meaning it is no longer exploitable on current Google Cloud, and no self-managed customer deployment is affected.

This is a moderate-severity, authorization flaw (CWE-863, Incorrect Authorization) in Google Cloud Application Integration's AuthConfig validation and integration execution runtime. The input CVSS 4.0 vector (7.3) shows AV:N (network-reachable API), AC:L, but AT:P - meaning a specific attack requirement/condition must be present - and PR:L, so exploitation requires an already-authenticated, low-privileged user within the project. Per the mandatory precision rules, PR:L confirms this is an authenticated-user attack, NOT remote-unauthenticated. The impact is significant: VC:H plus subsequent-system SC:H/SI:H/SA:H reflect that successful service-account impersonation grants broad access to project resources (scope-crossing privilege escalation). However, several real-world risk signals are MISSING: no EPSS score, no CISA KEV listing, and no POC were provided, so there is no public exploit identified at time of analysis. Critically, Google states the issue was patched server-side on 2026-08-27 with no customer action needed - this is a fully vendor-remediated cloud (iPaaS) vulnerability, so active live risk to properly-functioning Google Cloud today is effectively eliminated. Net: a legitimately impactful privilege-escalation bug in principle, but the authenticated prerequisite, specific attack requirement (AT:P), and completed server-side remediation substantially lower its real-world priority. No conflicting signals, but the absence of EPSS/KEV/POC data means exploitation likelihood cannot be quantified.

An authenticated user who already holds low-privilege access within a Google Cloud project crafts input that abuses the AuthConfig validation path during integration execution, causing the runtime to execute under a higher-privileged service account. The attacker thereby impersonates that service account and gains its permissions across project resources. No public exploit code was identified, and the flaw was remediated by Google on 2026-08-27 with no customer action required.