Google Cloud Application Integration critical RCE explained

Google has published a bulletin for critical vulnerability CVE-2026-93327 in Application Integration. An untrusted-data deserialisation flaw in the SubWorkflow task could allow an authenticated user to execute arbitrary code with a specially crafted serialised object.

The vendor fixed the issue on 11 September 2026 and says customers do not need to install an update. Bulletin GCP-2026-074 was published on 28 October. The distinction matters: no customer action required to remove the vulnerable platform code does not mean that a customer has nothing to review. Organisations should still establish who could create or modify integrations and whether logs contain unusual activity from before the fix.

The priority action: confirm the use of Application Integration, review IAM roles and integration change history, preserve evidence of the review and remove unnecessary permissions. Do not try to patch a managed service yourself; Google confirms that the platform-side fix has already been deployed.

What happened in Google Cloud Application Integration

Application Integration connects applications, data and services through workflows running in Google Cloud. A SubWorkflow task lets one flow invoke another piece of logic. According to Google, service versions before 11 September 2026 contained an untrusted-data deserialisation weakness.

Deserialisation converts a stored object back into a structure used by an application. If a platform reconstructs a user-controlled object without sufficiently restricting its type and contents, it may trigger unsafe behaviour embedded in that data. Google confirms that, in this case, an authenticated user could use a malicious serialised object to execute arbitrary code.

The bulletin rates CVE-2026-93327 Critical. It does not report active exploitation or say that every service user could carry out the attack. Authentication is a confirmed prerequisite, so an organisation’s assessment should consider the actual roles and permissions assigned in each project.

Why “no customer action required” is not the end

In a managed service, the provider owns the platform code and can deploy a fix without customer involvement. The customer still owns configuration, identities, roles, data flows and the response to potential misuse.

In practical terms, the organisation should answer four questions:

1. Was Application Integration in use before 11 September 2026?
2. Which users and service accounts could create or modify integrations?
3. Were those permissions limited to the necessary projects and environments?
4. Are change and execution logs available for the full period that matters?

If the answers are unknown, the issue is broader than one CVE. The organisation may lack control of an integration layer that connects CRM, finance, customer data and operational automation.

What a Google Cloud team should review

1. Service scope and ownership

Identify projects using Application Integration, their regions and environments, and the business owner of each flow. Include disabled and test integrations; they may still contain active credentials or document former access paths.

2. IAM roles and technical identities

Review users, groups and service accounts that can edit or execute integrations. Remove unnecessary inherited roles, broad project access and dormant accounts. Where the business process allows it, separate integration development, change approval and production-data access.

3. Change and execution history

Look for unusual SubWorkflow modifications, new integrations, permission changes, timing anomalies and executions by unexpected identities. Correlate Application Integration records with Cloud Audit Logs, IAM and Security Command Center alerts. A single event rarely provides enough context on its own.

4. Secrets and connected systems

Map the credentials used by flows. If the review finds a suspicious change or execution, consider rotating secrets and tokens for connected systems. Do not rotate everything without a plan; doing so can interrupt business processes and make evidence preservation harder.

5. Evidence that the review happened

Record the review date, covered projects, authorised identities, log period and assessment outcome. For audit purposes, “Google patched it” is not the full answer. The organisation should also show that it reviewed its side of the shared-responsibility model.

Reducing similar managed-service risk

The best control is not an attempt to predict every platform defect. It is limiting the effect when one appears. Least privilege, environment separation, short-lived credentials, centralised logging and recurring automation reviews all contribute.

Vendor bulletins should also feed into the vulnerability management process. SaaS and PaaS issues may not appear in a conventional server scanner, so they still need an owner, an information source and an assessment procedure even when the vendor performs the update.

Source facts and Breachroad conclusions

Google confirms a critical deserialisation vulnerability in the SubWorkflow task, code execution by an authenticated user, the 11 September fix date and the lack of a required customer-side update.

Reviewing IAM roles, logs, connections and control evidence is Breachroad’s recommendation based on shared responsibility. Organisations can prepare service owners for these assessments through cybersecurity training for businesses. If integration scope and permissions are unclear, a cloud security assessment can provide the baseline.

CVE-2026-93327 FAQ

Does a Google Cloud customer need to install a patch?

No. Google says the issue was fixed on the platform on 11 September 2026 and requires no customer update.

Could the flaw be exploited without signing in?

Not according to the bulletin. Its description specifies an authenticated user supplying a maliciously crafted object.

Should every secret be rotated?

Not automatically. Review access and logs first. Rotation is appropriate where there is evidence of misuse, the activity history cannot be reconstructed or business risk justifies a precautionary change.

What matters most after an automatic fix?

Confirm who had access to the service, review changes and executions from before the fix, and remove unnecessary IAM permissions.

Primary source: Google Cloud Security Bulletin GCP-2026-074.