A Free-Trial Search Feature Leaks Production Cloud Credentials

The Vulnerability

The product's search feature lets a user define a custom data-source provider that points at a storage endpoint. The address field of that provider had no allowlist and no blocklist, so it accepted any host the attacker named. When a search ran against a dataset on that provider, a worker running inside the company's production cloud account connected to the attacker's address.

Crucially, every such outbound request was signed and carried the worker's own cloud credential headers: a temporary access-key identifier plus the full session token. So pointing the provider at an attacker server exfiltrated live credential material from the production infrastructure to an attacker-controlled listener. Because this is a shared multi-tenant control plane, those credentials and the internal reach belong to the company's own production environment, not the tenant's.

The Attack

Browser-only reproduction

The whole flow ran in the product interface plus the browser console, with no terminal:

1. Sign up for a free trial and open the search app. No payment or special privilege is needed.
2. Paste a small console helper that reads the existing session token from local storage and calls the search API as the user, so no token is copied by hand.
3. Create a custom data-source provider whose endpoint points at the attacker server. The endpoint field has no allowlist, so it saves unchanged.
4. Create a dataset on that provider and run an ordinary search. This is the trigger.
5. View the attacker listener. Within seconds, the worker's requests arrive, each carrying the live signed credential headers, and the listener decodes the owning production cloud account identifier from the token.

Reading internal content

The attacker also controls the worker's follow-up request through a crafted storage listing, and any content the worker fetches is returned to the attacker as searchable results. That is a full read of any storage-protocol store the worker can reach. Timing tests indicated the worker reaches internal and link-local hosts: a job pointed at an internal metadata address or a private-range address hung waiting on the target rather than failing fast like a closed port, which is consistent with the worker accepting the connection and waiting on an internal response. The platform's own job logs corroborated each step independently of the attacker server.

The Impact

The confirmed impact is server-side request forgery from a free-trial account, a live credential-header leak from production infrastructure, a response-based pivot that returns internal content as search results, and a full read of storage-protocol content the worker can reach. The worker reaching internal and link-local addresses means the forced requests are not limited to the public internet.

The impact was tested honestly and is bounded, which is why this is High rather than Critical. The leaked access-key identifier and session token are not directly reusable on their own, because the signing scheme never transmits the secret portion of the key, and the storage client ignored a redirect that would otherwise have recovered a full reusable credential set, and could not read the non-storage body of an internal metadata service. The impact is therefore the confirmed forgery, the live credential-header leak, the response pivot, and the storage-content read, not a directly replayable full credential.

Related observations

The forgery surface was broader than the one provider type: several other provider types also saved with no allowlist and returned fetched content as results, though those enforced an egress filter that blocked internal and private targets. The job logs also disclosed worker internals, the internal hostname and private address plus the exact build version, which combined with the recovered production account identifier hands an attacker the internal addressing and version fingerprint of the workers.

Remediation

• Do not allow user-defined endpoint addresses on data-source providers. Restrict to the expected cloud storage endpoints, validated server-side before save, and reject link-local, loopback, and private-range targets.
• A save-time hostname allowlist alone is insufficient. The worker re-resolves the name independently for each request hop, so an attacker can pass validation with a benign-resolving host and rebind it to an internal address before the data hop. Pin the resolved address for the whole job and recheck it against the deny-list at connect time.
• Use a credential provider that does not attach the worker's signed credential headers when the endpoint host is not a trusted storage endpoint.
• Isolate per-tenant workers or use scoped, short-lived credentials so a leaked token has minimal blast radius, and audit existing providers for non-standard endpoint values.