CVE-2026-2031 "StubZero": Remote Code Execution in Google Cloud Application Integration via Exposed Proto Descriptors, GenericStubbyTypedTaskV2 and ACL Bypass — Threadlinqs Intelligence
As of 2026-06-23, CVE-2026-2031 "StubZero": Remote Code Execution in Google Cloud Application Integration via Exposed Proto Descriptors, GenericStubbyTypedTaskV2 and ACL Bypass is a critical-severity vulnerability threat, tracked by Threadlinqs Intelligence with 9 detection rules (Splunk SPL, Microsoft KQL, Sigma) and 20 indicators of compromise.
Threat ID: TL-2026-0915 · Severity: CRITICAL · CVSS: 10 · Status: PATCHED · Category: VULNERABILITY
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
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
Weaknesses (CWE)
CWE-284, CWE-639, CWE-862, CWE-200, CWE-863
Target sectors: technology, cloud-service-providers, saas
Target regions: Global
Detections & IOCs
As of 2026-08-18, this threat has 9 detection rule(s) across Splunk SPL, Microsoft KQL and Sigma, and 20 indicator(s) of compromise. Detection query text and full IOC values are available to authenticated users and programmatically via the Threadlinqs MCP server (Purple tier). View plans.
VULNERABILITY, CRITICAL, threat intelligence, cybersecurity, CVE-2026-2031, T1595, T1590, T1526, T1580, T1213, T1190, T1552, T1078, T1548, T1098
