// Google Genkit / case study

Provider endpoint trust-boundary failure

SSRF, API-key exposure, and response forgery were validated in an AI SDK integration that accepted a caller-influenced provider endpoint.

Google Cloud VRP recognitionDisclosure-safe summary
Trust-boundary path
01Request endpoint override
02Authenticated provider client
03Attacker-controlled origin

Project and affected component

Google Genkit provider transport and per-request model configuration.

Security boundary

Application input selected a provider endpoint while the SDK supplied authentication and accepted the remote response as model output.

Vulnerability class

Server-side request forgery, credential exposure, and response-integrity failure at an AI provider boundary.

Root cause

A request-scoped endpoint override reached the provider client without a trusted-origin check, so the client attached provider credentials, called the supplied origin, and parsed the response as if it came from the intended model service.

Validation method

A local production-shaped harness sent requests to a controlled callback; within the same run, the callback recorded redacted credential evidence, returned a harmless model-shaped response, and confirmed that the application accepted it, while matched controls kept the trusted provider path unchanged.

Practical impact

An untrusted endpoint could receive provider credentials and influence model output returned to the application, crossing confidentiality and response-integrity boundaries in one path.

Disclosure status

The work received Google Cloud VRP recognition. Private tracker details and reproduction material are not published here.

Remediation

Remove request-level control over provider origins, or bind it to an explicit allowlist, keep provider credentials away from caller-selected endpoints, and reject responses that do not come through the configured provider transport.

Public references