Researcher Earns $148,337 for Google Cloud Production RCE Vulnerability

Security researcher Arvin Shivram earned $148,337 from Google after reporting two remote code execution chains and a follow-up privilege escalation issue in Google Cloud’s internal Integration Platform APIs.

The main issue is tracked as CVE-2026-2031. The vulnerability involved improper access control in internal endpoints connected to Google Cloud Application Integration and could allow sensitive internal information disclosure and arbitrary code execution.

Shivram published the technical account under the title StubZero: $148,337 RCE in Google Cloud Production. Google has since restricted access to the exposed endpoints, and its release notes say no action is required from external customers.

What was the Google Cloud vulnerability?

The vulnerability started with an exposed internal API surface that returned successful responses to suspicious debugging endpoints. Further testing showed that one endpoint could return protobuf definitions for internal Google services.

This mattered because Google’s internal systems rely heavily on protobuf definitions. With those definitions, a researcher could better understand internal request and response structures, making further security testing much more effective.

The vulnerability then escalated through Google’s internal Application Integration backend. Application Integration is Google Cloud’s managed integration platform for connecting applications, services, and data through workflows, connectors, and a visual editor.

Detail	Confirmed information
Researcher	Arvin Shivram
Public title	StubZero: $148,337 RCE in Google Cloud Production
CVE	CVE-2026-2031
Affected area	Google Cloud internal Integration Platform APIs tied to Application Integration
Severity	Critical, CVSS 10.0
Total reward	$148,337

How the bug escalated to production RCE

The first chain began when Shivram’s fuzzing tool found that the internal API cloudcrmipfrontend-pa.googleapis.com responded to debugging endpoints. One endpoint, getProtoDefinition, could return protobuf descriptors for arbitrary internal services.

The next important discovery involved a workflow queue leak. By querying another endpoint with the right parameters, the researcher found an internal clientId value that helped him create draft workflows in the internal backend.

The most important task type was GenericStubbyTypedTaskV2. According to the BruteCat write-up, this task acted as a wrapper around Google’s internal Stubby RPC framework and could be configured with fields such as serverSpec, serviceName, and serviceMethod.

Why Stubby access matters

Stubby is Google’s internal RPC framework. In this case, the vulnerable workflow path could let a researcher trigger internal RPC calls from Google’s production environment using the service identity of the integration platform.

Google’s Cloud Vulnerability Reward Program rules include reward categories for compromise of Google Cloud production environments. The final payout reflected the level of production access and the quality of the reports.

The researcher did not keep testing after Google’s security team confirmed the issue. In the first chain, Shivram said Google stopped further testing before actual code execution on Google’s servers, but the chain was treated as exploitable and escalated internally.

• The first report was submitted to Google on December 1, 2025.
• Google triaged the initial report as P0/S0 on the same day.
• The RCE escalation was added on January 12, 2026.
• Google awarded $60,000 for the first RCE chain on January 16, 2026.
• A second RCE chain was reported in March 2026.
• Google later awarded $75,000 and an additional $13,337.

The second RCE chain used public APIs and IDOR bugs

Three months later, Shivram found another attack path in public Application Integration APIs. This second chain involved insecure direct object reference issues, often called IDORs, and the service’s test cases feature.

The researcher found that an API could allow a user to reference their own project in the URL while supplying another user’s integration UUID. That alone was difficult to exploit because UUIDs are not practical to guess at scale.

The breakthrough came from the test cases feature. By using a global listing behavior and filtering technique, the researcher reconstructed victim integration UUIDs and accessed workflow definitions across tenants, including workflows tied to internal Google teams.

Reward item	Amount	Reason reported
First RCE chain	$60,000	Compromise of Google Cloud production environment
Second RCE chain	$75,000	Compromise of Google Cloud production environment
Follow-up privilege escalation	$13,337	Single-service privilege escalation with write impact
Total	$148,337	Combined Google Cloud VRP payout

Google patched the exposed internal endpoints

The official Google Cloud release notes for May 7, 2026, say multiple Integration Platform API endpoints were inadvertently exposed. Google says the issue has been resolved and access has been restricted.

The CVE record describes the issue as improper access control in several internal API endpoints prior to January 23, 2026. It says a remote unauthenticated attacker could disclose sensitive internal information and execute arbitrary code through specially crafted HTTP requests.

Because this was a managed Google Cloud service and the vulnerable access path was inside Google’s own infrastructure, Google says external customers do not need to take action. The fix centered on access restriction, IDOR remediation, and stronger RPC security controls.

What Application Integration does

Google Cloud Application Integration is a managed integration platform used to connect cloud services, SaaS applications, and business data. It supports workflows, triggers, connectors, and a visual editor for building integrations.

That context explains why the issue received a high severity rating. A platform that can run workflows, call services, and handle connectors may have access to sensitive business systems if its internal controls fail.

Google’s Application Integration documentation describes the service as serverless, auto-scaling, and fully managed by Google. Those same managed-service qualities meant Google could deploy the required platform-side fix without asking external customers to patch local software.

Why the payout was so high

Google’s bug bounty programs reserve their highest payouts for severe issues that affect production environments, sensitive data, or privileged access. In this case, the first two reports were both categorized as Google Cloud production environment compromise.

The public Google Cloud VRP rules list reward structures for cloud vulnerabilities, including production-environment compromise. Shivram’s second RCE chain received the larger $75,000 reward because Google assessed it as a higher-impact production access issue.

For cloud providers, bugs like this carry unusual risk because they may cross customer boundaries or internal service boundaries. Even when no customer action is required, the report shows why access control, RPC boundaries, and workflow authorization need strict defense inside managed platforms.

What developers and cloud teams can learn

Most customers do not need to respond directly to this patched Google issue. The broader lesson still matters for cloud teams that build their own integration platforms, workflow engines, and internal APIs.

Internal endpoints should never rely only on obscurity or network assumptions. They need explicit authentication, authorization, logging, and tenant isolation, especially when they can create workflows, call backend services, or access internal descriptors.

The latest Google Cloud security update says access has been restricted, which addresses the immediate exposure. The case also shows why well-run vulnerability reward programs remain valuable for finding high-impact bugs before attackers can exploit them.

FAQ