# CVE-2026-2031 "StubZero": Remote Code Execution in Google Cloud Application Integration via Exposed Proto Descriptors, GenericStubbyTypedTaskV2 and ACL Bypass

> StubZero (CVE-2026-2031) is a critical access-control flaw chain in Google Cloud Application Integration that allowed a researcher to achieve remote code execution inside Google's production environment as a privileged service identity. Exposed internal debugging endpoints leaked arbitrary google3 protobuf descriptors and a 'default' clientId, the GenericStubbyTypedTaskV2 task type enabled arbitrary internal Stubby RPC calls, and an ACL endpoint bypassed the two-person workflow-publishing approval. Google has patched the issue; a detailed proof-of-concept was published by BruteCat.

- **Published:** 2026-06-23T00:00:00Z
- **Last reviewed:** 2026-06-23T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-0915
- **ID:** TL-2026-0915
- **Severity:** CRITICAL (CVSS 10)
- **Category:** VULNERABILITY
- **Status:** PATCHED
- **Detections:** 9 · **IOCs:** 20 (full data via the Threadlinqs MCP server — Purple tier)
- **CVEs:** CVE-2026-2031

## Description

StubZero is a multi-stage access-control and remote-code-execution chain in Google Cloud Application Integration disclosed by security researcher Arvin Shivram (BruteCat) and tracked as CVE-2026-2031 (CVSS 10.0). The bug bounty payouts totalled $148,337 across two related chains. Google has fully remediated the issues; this record documents the disclosed mechanics for defensive and detection-engineering purposes.

First chain (production RCE). Automated fuzzing surfaced the internal-facing host cloudcrmipfrontend-pa.googleapis.com responding HTTP 200 to debugging endpoints. The endpoint /v1/integrationPlatform:getProtoDefinition behaved as 'req2proto as a Service' — returning the protobuf definition of any message or service in google3 (Google's internal monorepo), including unrelated stacks such as YouTube InnerTube and Google's internal CRM. Requests were authenticated with Google first-party SAPISID cookies plus a calculated Authorization: SAPISIDHASH header, scoped to origin https://console.cloud.google.com. A second endpoint, /v1/integrationPlatform:listQuotaQueue, queried with a filter such as client_id>"123", ?alt=proto and the header X-Goog-Encode-Response-If-Executable: base64, leaked an internal workflow execution queue (Spanner-to-Salesforce sync data, account IDs, due-diligence status) and crucially revealed client_id 'default'. Using that clientId, /v1/integrationPlatform:createDraftWorkflow created a draft workflow, and the discovery document exposed GenericStubbyTypedTaskV2 — a generic wrapper around Google's internal Stubby RPC framework (referenced in Application Integration JavaScript on gstatic.com with the stubby_48px_blue.svg icon). The task accepts serverSpec, serviceName and serviceMethod parameters, enabling arbitrary Stubby RPC calls from the production environment using the integration platform's privileged service identity. To publish, the two-person approval / single-publisher restriction was bypassed via /v1/integrationPlatform/auth:setAcl, adding attacker-controlled obfuscated Gaia IDs with role 105, followed by toggleRequestToPublishWorkflow and publishWorkflow. A demonstration RPC to serverSpec gslb:alkali-base, serviceName ServerStatus, serviceMethod GetServices returned an rpc.ServiceList exposing internal services such as AlkaliBaseAccountService. The createDraftWorkflow fix propagated across load-balanced backends roughly one hour after the PoC completed, and collaborator 'shrugged' found Google's initial mitigation was only partially deployed, allowing repeated requests to hit still-vulnerable backends during the race window.

Second chain (cross-tenant IDOR, ~3 months later). The public Application Integration API exposed an IDOR: requesting GET /v1/projects/<your-project>/locations/us-central1/integrations/x/versions/<victim-uuid> returned victim resources because authorization only validated the caller's project ID, not ownership of the target UUID. Because UUIDs span ~10^36, direct brute force was infeasible. The TestCases service was abused instead: POST /$rpc/google.cloud.integrations.v1alpha.TestCases/ListTestCases with the workflow_id filter (proto field 2) omitted returned test cases across every GCP project, exposing creator emails (many @google.com). Using filter operators (>, <=) on the workflow_id field, a binary search (~128 requests) reconstructed full victim integration UUIDs, enabling theft of complete victim integration definitions (triggers, GenericRestV2Task configs, parameter bindings, lastModifierEmail). Creating integrations with internal tasks such as PythonTask succeeded, and test-case execution stack traces revealed the backend ExecuteStubbyCallRequest code path consuming serverSpec, serviceName and serviceMethod directly — confirming the same Stubby execution surface.

Impact context: in Google's Borg/production model, Stubby RPC is governed by per-method allowlists in RpcSecurityPolicy, with frontends calling downstream services under their own production service identity while carrying end-user context via security tickets. Compromising the integration frontend's Stubby access therefore dramatically expanded reachable internal attack surface — RCE here means arbitrary internal RPC calls as a production identity rather than a traditional OS shell.

## MITRE ATT&CK

- T1595 Active Scanning
- T1590 Gather Victim Network Information
- T1526 Cloud Service Discovery
- T1580 Cloud Infrastructure Discovery
- T1213 Data from Information Repositories
- T1190 Exploit Public-Facing Application
- T1552 Unsecured Credentials
- T1078 Valid Accounts
- T1548 Abuse Elevation Control Mechanism
- T1098 Account Manipulation
- T1059 Command and Scripting Interpreter
- T1210 Exploitation of Remote Services
- T1119 Automated Collection
- T1530 Data from Cloud Storage

## Sources

- [StubZero: $148,337 RCE in Google Cloud Production](https://brutecat.com/articles/google-cloud-rce/)
- [Google Cloud Production RCE Vulnerability (CVE-2026-2031)](https://cybersecuritynews.com/google-cloud-production-rce-vulnerability/)
- [Episode 177: 2x Google RCE with VRP Legend Brutecat](https://www.criticalthinkingpodcast.io/2x-google-rce-with-vrp-legend-brutecat/)
- [HackerNotes Ep. 177 — Double Google RCE with VRP Legend Brutecat](https://blog.criticalthinkingpodcast.io/p/hackernotes-ep-177-double-google-rce-with-vrp-legend-brutecat)
- [Seclog #179 — Google Cloud RCE Earns Big Bounty](https://rosecurify.com/seclog-179/)
- [Intigriti Bug Bytes #236 (May 2026)](https://www.intigriti.com/researchers/blog/bug-bytes/intigriti-bug-bytes-236-may-2026)
- [Brutecat Security (research index)](https://brutecat.com/)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-0915