Incorrect Authorization in Google Cloud Application Integration Enables Privilege Escalation and Service Account Impersonation

An Incorrect Authorization vulnerability in the AuthConfig validation and integration execution runtime in Google Cloud Application Integration versions prior to 2026-08-27 allows an authenticated user to escalate privileges and impersonate a service account in the project. This vulnerability was patched on 27 August 2026, and no customer action is needed.

• Google Cloud Application Integration: affected from 0 before 2026-08-27, using the date-based affected status in the record. The default status outside the listed range is unaffected.
• Google states that the vulnerability was patched on August 27, 2026. The record does not provide a customer-facing release number or separate branch-specific fixed version, so it should not be expanded into an open-ended statement such as “that version or later.”

The weakness is CWE-863 Incorrect Authorization in the AuthConfig validation and integration execution runtime of Google Cloud Application Integration. An authenticated user can reach the runtime over the network, encounter an authorization failure, escalate privileges, and impersonate a service account in the Google Cloud project.

At a high level, the supported sequence is:

1. An authenticated user reaches functionality involved in authorization or integration execution.
2. The runtime processes AuthConfig or an execution request without enforcing the intended authorization boundary.
3. The user obtains the ability to operate under a service account identity and may use permissions assigned to that account.

The record characterizes the issue as network reachable, requiring low initial privileges, requiring no user interaction, and having an additional attack condition. The request parameters, API method, input field, or exact authorization comparison that fails are not disclosed, so a specific payload or exploit chain cannot be established from the available evidence.

The vulnerability is remotely reachable over the network by an authenticated user with low initial privileges. The supplied assessment records no user interaction, low attack complexity, and an additional attack condition.

The normalized record does not identify a public exploit, but the actual exploitation status is not established. The absence of that information should not be interpreted as proof that exploitation has not occurred. The available public detail does not identify an exploit, campaign, victim, or specific exploitation indicator.

The primary technical outcome is privilege escalation and service account impersonation within the Google Cloud project. The supplied assessment indicates high confidentiality impact to the service and the possibility of impact extending to resources outside the original component through the service account's permissions.

The actual access available to an attacker depends on the service account's IAM bindings, which are not specified in the record. The record does not confirm a direct impact to the vulnerable component's integrity or availability, and it does not identify a specific action performed in a customer environment.

An authenticated user could operate under a service account identity instead of being limited to the user's original permissions. The practical impact depends on the permissions assigned to that service account, the resources it can access, and the systems that trust the identity.

The supplied assessment indicates that impact can extend from the vulnerable service to subsequent resources reachable through the service account. This could expose data or permit actions on behalf of the project, but the record does not identify specific data, APIs, tenants, or operations that were accessed. The available evidence does not establish that a customer data incident or service outage occurred.

1. No customer action is required for the vulnerability patch. Google Cloud states that the service was patched on August 27, 2026.
2. Because the affected boundary is expressed as a managed-service date rather than a package release, do not attempt to verify remediation using an unsupported local version. If compliance evidence is required, retain Google's security bulletin and confirm service status through the appropriate support channel.
3. Review current authorization configuration for integrations. Google documentation states that publishing and testing integrations using a run-as service account requires iam.serviceAccounts.actAs on that account. This supports the current authorization model and is not a substitute for the service-side patch.
4. Review integrations using AuthConfig, run-as service accounts, and principals that publish, test, or approve integrations for overly broad configuration or unusual activity during the period before the patch.

Use the following checks:

1. Inventory Google Cloud Application Integration deployments that use AuthConfig, service accounts, or execution under a separate identity.
2. Identify integrations and execution paths that existed or were active before Google completed the patch on August 27, 2026.
3. Review current bindings and workflows involving iam.serviceAccounts.actAs, especially for principals that publish, test, or approve integrations and for run-as service accounts.
4. Review available administrative and execution records for unexpected service account use or authorization changes during the period under investigation. This is precautionary monitoring, not a Google-confirmed IOC.
5. The supplied sources do not define a specific log signature, endpoint telemetry pattern, or IOC. A clean log review does not prove that the environment was not exposed.