CVE-2026-2264 is not a typical API gateway bug. It is a design-contract violation dressed as a vulnerability.
The flaw lives in Google Cloud Apigee’s SetIntegrationRequest policy. An attacker who can reach the policy can trigger Server-Side Request Forgery (SSRF) and exfiltrate the service account access token attached to the API proxy. The National Vulnerability Database entry notes that exploitation requires an administrator to first establish “an insecure configuration of the API proxy.” That qualifier is doing a lot of work.
Let’s be precise. The SetIntegrationRequest policy is a feature. It lets an API proxy make outbound HTTP calls to backend services, passing through request data. The vulnerability arises when that feature trusts user-supplied input for the target URL without sufficient validation. An attacker sends a crafted request. The proxy forwards it to an attacker-controlled server. The token follows.
Google patched the issue. The fix likely adds URL allow-listing or strips the token from outbound calls. The details matter less than the pattern.
This is the third major SSRF disclosure in a managed API gateway in the last 18 months. Each time, the root cause is the same: the gateway’s outbound-call feature was designed to be flexible, and flexibility is the enemy of a trust boundary. The SetIntegrationRequest policy assumes the administrator will configure it safely. The vulnerability is what happens when that assumption meets a production environment where “safe configuration” is not the default.
For builders, the lesson is not “patch quickly.” The lesson is that API gateways are not security boundaries. They are policy-enforcement points that inherit the trust model of the surrounding infrastructure. If a gateway can make outbound calls with a service account token, the gateway is itself a privileged actor. Treat it like one.
Google fixed the code. The industry should fix the assumption.