Summary
- Two of the three newly disclosed Application Integration vulnerabilities are rated critical.
- One flaw allowed a standard authenticated user to execute arbitrary code on shared production servers.
- Google says all three issues were patched in June and require no customer action.
Google Cloud has disclosed three security vulnerabilities in its Application Integration service, including two critical flaws that could have allowed authenticated users to execute arbitrary code or privileged internal requests from production infrastructure.
The vulnerabilities were published in Google Cloud security bulletins on 28 September, although the company says all three were fixed in June and no customer action is required.
The most direct code-execution issue, CVE-2026-81867, affected the JavaScript Task component. Google says a user with ordinary authenticated permissions could submit a specially crafted script and run arbitrary code on shared production servers. The company classifies the flaw as critical and says it was patched on 28 June.
A second critical vulnerability, CVE-2026-19759, involved incorrect authorisation in task configuration. An authenticated user could use an internal-only task type to execute arbitrary remote procedure calls from Google’s internal production network under a privileged identity. Google says that flaw was patched on 17 June.
The third disclosure, CVE-2026-81375, is rated high severity. It affected the Email Task component and allowed an authenticated attacker to read and exfiltrate arbitrary Google-internal files using a crafted attachment path. It was patched on 30 June.
None of the bulletins says that the vulnerabilities were exploited in the wild, and Google’s disclosure does not establish customer compromise. The risk instead lies in what the flaws reveal about the security boundaries inside highly integrated cloud services, where authenticated users can trigger workflows that ultimately execute against infrastructure far more privileged than the user account itself.
Application Integration is designed to connect applications and services through managed workflows. That model necessarily involves execution engines, service identities, internal APIs, and connectors operating across trust boundaries. A permission check that fails inside such a service can therefore have consequences beyond a single tenant-facing interface.
The vulnerabilities also demonstrate why cloud security cannot be reduced to customers applying patches to conventional servers. In this case, Google owns and operates the underlying service and remediated the flaws centrally before public disclosure. Customers do not need to deploy fixes, but they remain dependent on the provider’s ability to find, contain, and communicate vulnerabilities in the control plane and shared execution environment.
That division of responsibility can improve patch speed because a single provider can update the service for all users at once. It also concentrates technical and operational dependency: customers may have little direct visibility into the internal architecture affected by a vulnerability and must rely on provider disclosure to understand the exposure after remediation.
Google’s September bulletins therefore describe already-fixed issues rather than an active emergency. Their significance is architectural. Two authenticated attack paths reached either shared production code execution or privileged internal RPC capability — precisely the sort of boundary failure that becomes important when enterprise workflows increasingly depend on managed integration platforms rather than software operated entirely inside an organisation’s own environment.
