StubZero: $148,337 RCE in Google Cloud Production

by

Author: Arvin Shivram (brutecat)
Published: May 22, 2026
Source: https://brutecat.com/articles/google-cloud-rce/

Summary

Security researcher brutecat (Arvin Shivram) documents two separate vulnerability chains, three months apart, that each reached remote code execution inside Google Cloud’s production environment via the Application Integration platform. Both escalated from information disclosure and cross-tenant access to the ability to run RPCs as an internal production service identity. The work was reported through Google’s VRP, triaged as Cloud production compromise, and remediated; the chain was assigned CVE-2026-2031. Google paid a combined $148,337 ($60,000 for the first RCE, $75,000 for the second, and $13,337 for a related IDOR). The findings are described as verified with working proof-of-concept demonstrations, and the author states he stopped testing once Google’s security team confirmed exploitability.

Technical Details

First chain (reported Dec 2025). A public debugging endpoint on the Application Integration frontend (cloudcrmipfrontend-pa.googleapis.com, via /v1/integrationPlatform:getProtoDefinition) exposed internal proto definitions, which the author used to reverse-engineer internal APIs. An internal workflow-execution queue endpoint then leaked valid client_id values. Combining those leaked identifiers with a legitimate workflow-configuration feature, the researcher created workflows containing GenericStubbyTypedTaskV2 tasks configured to issue arbitrary Stubby (internal Google RPC) calls — executed as the integration platform’s production service identity. A contributing factor was an incomplete fix rollout: the authorization check was not consistently applied across load-balanced backends.

Second chain (reported Mar 2026). A “test cases” feature exposed cross-tenant data through an IDOR. Missing field validation on filter parameters let the author use comparison operators on sensitive fields and, via a binary-search oracle, extract victim integration UUIDs — enabling access to arbitrary victim integrations and their configurations. From there, internal task types such as PythonTask could be configured inside user-controlled public integrations, and executing a test case reached backend code paths capable of RPC execution — again yielding code execution with production privileges.

Root causes, as described: debugging/proto endpoints exposed without adequate access control; missing client_id validation plus an incomplete security-fix rollout across backends; cross-tenant IDOR on test cases and integrations via UUID manipulation; filter-parameter validation that failed to prevent comparative operators on sensitive fields (enabling a search oracle); and a privilege-escalation gap allowing internal task types to be configured in user-controlled workflows. No affected version numbers apply — these are server-side Google Cloud services. This summary intentionally omits exact request payloads.

Impact

Under Google’s VRP framework the outcome is classified as compromise of the Google Cloud production environment: an external, effectively unauthenticated attacker could execute arbitrary internal RPC calls using production service identities, reaching sensitive backend services. Cross-tenant access to other customers’ integrations and their configuration data was also demonstrated. The author frames this as full production RCE rather than a limited disclosure, consistent with the P0/S0 triage and the size of the awards.

Mitigation

All issues were reported to Google and fixed through the VRP process; there is no customer-side patch, and the chain is tracked publicly as CVE-2026-2031. The disclosure timeline: first report Dec 1, 2025 (P0/S0), RCE escalation Jan 12, 2026, $60,000 awarded Jan 16, 2026; second report Mar 21, 2026 (P1/S1), escalated to P0/S0 on Mar 23 after an RCE demo, $75,000 awarded Apr 28, and an additional $13,337 for the related IDOR in early May 2026. Transferable defensive lessons: do not expose proto/debugging endpoints without access control; ensure security fixes roll out uniformly across every load-balanced backend (a partial rollout leaves an exploitable window); enforce tenant-scoped authorization on every object reference to prevent IDOR; validate filter parameters so comparison operators cannot be turned into a data-extraction oracle; and prevent internal/privileged task types from being configured in user-controlled workflows.

References

Leave a Comment