One Wildcard Character — $88,337 from Google: How brutecat Broke Cloud Tenant Isolation — A…

Credit: This is a narrative review of a vulnerability originally discovered and responsibly disclosed by brutecat. The original report is publicly available on Google Bug Hunters: https://bughunters.google.com/reports/vrp/dKFDp95wg. All technical credit belongs to brutecat. This article is my personal breakdown and analysis of the finding.

brutecat found a way to read test case data from any company using Google Cloud Application Integration. All it took was a single "-" in an API URL.

Google VRP paid him $88,337 for it.

Read it for free here

The Background

Google Cloud Application Integration is an enterprise platform for building automation workflows. Think of it as a tool companies use to connect their internal systems — databases, APIs, CRMs — all running inside Google Cloud. Each company gets its own isolated GCP project, and the entire security model is built on one promise: your project can only access your data.

That isolation is enforced at the API level through the {project} parameter in the request path. The endpoint for listing test cases looks like this:

GET /v1/projects/{project}/locations/{location}/integrations/{integration}/versions/{version}/testCases

The {project} is supposed to be the hard boundary. Whatever you send, the API should only ever return data from that project.

To understand why this matters, you need to know what test cases actually contain. When an enterprise builds a workflow on this platform — say, something that pulls customer records from Salesforce, transforms them, and loads them into BigQuery — they write test cases to validate that the workflow behaves correctly. These test cases include real input payloads, actual field names from internal data models, sample records that mirror production structures, and sometimes staging credentials.

This isn't a platform for personal projects. The companies using it are enterprises with compliance requirements, security teams, and contracts that guarantee their cloud-hosted data is isolated by design.

The Crack

Google Cloud APIs support "-" as a wildcard in certain path parameters. It's a documented feature — it means "match all." You can use it in the {location} segment to query across all regions, for example.

brutecat noticed it also worked in the {version} segment and asked a simple question: if I use "-" as the version wildcard, does the API still enforce the {project} boundary?

It didn't.

Here's why. When Google Cloud APIs process a request, the authorization check and the data query are two separate operations. Normally, they are tightly coupled — the {project} in the URL scopes both the auth check and the database query. You are authorized against project X, so the query only fetches data from project X.

But when wildcards are used in nested path segments, the wildcard expansion logic runs first and expands the query to cover multiple resources across the platform.

The problem is that this expansion happened after the authorization check had already completed.

The auth layer saw a valid token for the attacker's project, returned OK, and handed off to the query layer. The query layer, now in wildcard expansion mode, had no mechanism to reapply the project scope to its results.

It's a classic gap between two systems that each assume the other is handling scoping. Neither was.

What the Request Looked Like

A normal request from an attacker's own project:

GET /v1/projects/attacker-project/locations/-/integrations/-/versions/-/testCases

The API authenticated the request against the attacker's project — that part worked fine. But the response came back with test cases from other tenants' projects.

The authentication passed. The authorization didn't.

When wildcards were stacked across path segments, the code that handled query expansion ran separately from the code that enforced project-level scoping. The data fetch became unscoped — it pulled from across the entire platform instead of just the authenticated project.

Why It Mattered

Google Cloud Application Integration workflows regularly contain real payloads, credentials in test environments, and proprietary business logic. The test cases brutecat could now enumerate belonged to completely different companies — enterprises running production workflows inside Google Cloud.

And there was no way for those companies to know. The access was silent. No notification, no alert, no audit log visible to the victim.

Think about what that means in practice. A competitor registers a GCP project, authenticates with valid credentials, fires off one request, and gets back structured JSON containing other companies' workflow data.

Integration names that reveal internal product terminology. Trigger configurations that map out backend system connections. Input schemas that expose field names from internal databases. And if someone placed real credentials in a test payload — which happens more often than most companies want to admit — those too.

There was also no rate-limiting concern here. This wasn't a brute-force attack. It was a single, well-formed GET request. One HTTP call with a valid auth token. The only thing that separated it from a normal developer query was three dashes instead of specific values.

Google patched it by ensuring the {project} boundary is enforced consistently, regardless of whether wildcards are used in other path segments. The vulnerability was rated Critical and rewarded $88,337.

The Takeaway

brutecat didn't find an undocumented bug. The "-" wildcard is in Google's own documentation. The bug came from understanding what happens when documented features interact in unexpected ways.

Whenever an API supports wildcards, it's worth asking whether they change how authorization is enforced downstream — not just what data gets returned.

For any API that follows the Google AIP (API Improvement Proposals) standard — which many GCP services do — wildcard support in collection identifiers is a defined pattern. That means there are likely more endpoints across Google Cloud services where this exact question hasn't been asked yet: does wildcard expansion in a child resource bypass project-level scoping in the parent?

brutecat found it on the testCases endpoint. It's worth asking about others.

The broader point is this: in multi-tenant cloud platforms, the highest-severity bugs usually aren't in complex exploit chains. They're in the gaps between systems that each assume the other is handling a security check.

When Google built the wildcard feature, the team responsible for query expansion likely assumed the auth team was scoping results to the project. When the auth team reviewed wildcard cases, they likely assumed the query layer was doing its own filtering.

One assumption, made twice by two different teams, never explicitly tested for the cross-case scenario.

That's $88,337 right there.

The API correctly confirmed brutecat's identity. It just failed to check what brutecat was allowed to see.