Google Agent Studio — SSRF in the auto-generated /api-proxy backend of web apps built before 2026-07-01; the fix is regenerate-and-redeploy, so deployed apps stay vulnerable until you act (vendor release note, single-source)

View raw markdownEdit on GitHub ↗

TL;DR

Google's Agent Studio — the Gemini Enterprise Agent Platform workspace where you refine a prompt and "deploy your prompt as a web application" — generated a backend with an /api-proxy endpoint that would forward requests to any destination the caller named. Google's release note of 2026-07-20 describes it as a Server-Side Request Forgery affecting web apps "created before July 1, 2026." The corrected generator now validates that the proxy's destination hostname "ends with allowed Google Cloud domains." The fix does not reach apps already deployed: you must regenerate the application from Agent Studio and redeploy it. If you clicked "deploy as web app" before July, the build that is live today is the vulnerable one unless you have rebuilt it since.

What happened

The only public record is the platform's own release notes, retrieved from Google Cloud's release-notes feed (the HTML page renders as navigation only to automated fetchers). The 2026-07-20 entry reads:

"This release fixes a Server-Side Request Forgery (SSRF) vulnerability in the auto-generated /api-proxy backend endpoint for web applications created before July 1, 2026, using Agent Studio."

and states that the fix requires regenerating applications from Agent Studio and deploying the updated versions, because the corrected backend code "now includes strict domain allowlist validation, ensuring that destination hostnames for the /api-proxy endpoint end with allowed Google Cloud domains."

Read that as a generator bug, not a service bug: the vulnerable code is in each customer's deployed artifact. A proxy endpoint that will fetch any hostname on the server's behalf is the standard SSRF shape — the request originates from wherever the app runs, with whatever network position and metadata access that runtime has, and the response typically flows back to the caller. Google does not say what the proxy could reach from a default deployment, whether responses were returned, or whether anyone exploited it; this write-up does not speculate beyond the vendor's text.

Why it belongs here. Agent Studio is a prompt-to-web-app product — a vibe-coding platform in all but name — and this is the generated-backend failure mode this repo tracks for Lovable, Bolt and Base44: the platform fixed its template, and every app already shipped from the old template is the customer's problem. The patch model ("regenerate and redeploy") is the same one that left Lovable-built apps exposed months after the platform's fix. No CVE, no GHSA, no blog post; a release note is the whole disclosure.

Status here is mitigated, not patched: the vendor's fix exists but is not applied to deployed instances without user action. Single-source (vendor's own release note); no independent confirmation was located as of 2026-09-15.

Am I affected?

  • Did you deploy a web application from Agent Studio before 2026-07-01, and have you not regenerated and redeployed it since 2026-07-20? If yes, the live app carries the unvalidated proxy.
  • In the deployed app's backend source, look for the /api-proxy route handler and check whether it validates the destination hostname against an allowlist before forwarding. A handler that forwards to whatever hostname the request supplies is the vulnerable generation.
  • If the app is reachable from the internet, review its request logs for /api-proxy calls whose destination is not one of your intended Google Cloud endpoints.

If you are affected

  1. Regenerate the application from Agent Studio and redeploy — this is the only fix Google offers; there is no in-place patch.
  2. Until redeployed, restrict the app's network egress and remove any credentials or metadata-server reachability the runtime does not need.
  3. If logs show the proxy was driven at unexpected destinations, treat anything reachable from the app's network position as potentially read. → playbooks/if-your-webapp-was-compromised.md and, for any service credentials the runtime held, playbooks/rotating-cloud-credentials.md

Prevention

  • → playbooks/auditing-a-vibe-coded-repo.md — generated backends need the same review as written ones; "proxy this request for the frontend" is a pattern to grep for in any AI-generated server code.
  • → prevention/credential-hygiene.md — assume a generated app can be made to issue outbound requests; keep the credentials reachable from its runtime minimal.
  • Track the platform's release notes, not just its blog: for Google Cloud products the machine-readable feed is docs.cloud.google.com/feeds/<product>-release-notes.xml, and security fixes that require customer action appear only there.

Sources