SSRF in Google Cloud Apigee-X Can Leak Service Account Tokens (CVE-2026-2264)
Vulnerability in the SetIntegrationRequest policy of Apigee received a 9.2 on the CVSS and allows for the exfiltration of service account tokens, but relies on an insecure prior configuration in the API proxy.
Google Cloud has patched a server-side request forgery vulnerability in Apigee-X, its API management platform, capable of leaking access tokens from service accounts. CVE-2026-2264, disclosed on May 26 in the security bulletin gcp-2026-034, received a score of 9.2 on CVSS 4.0, with an important caveat embedded in the notification itself.
The Vulnerability and Its Entry Condition
The issue lies in the SetIntegrationRequest policy of Apigee. According to Google Cloud's record, a remote attacker can utilize it to execute a SSRF (CWE-918) and exfiltrate access tokens from service accounts, the credentials that the API proxy uses to communicate with other Google Cloud services. With these tokens, the attacker inherits the permissions of the service account, which often means access to resources well beyond the gateway.
The caveat is noted in the advisory and should not be overlooked in haste: for the exploitation to work, an administrator must first have established an insecure configuration in the API proxy. The CVSS 4.0 vector reflects this by marking existing attack requirements (AT:P). In other words, the vulnerability does not trigger in any standard installation; it depends on a port being left open in the configuration. This does not render it harmless, as insecure proxy configurations are common where the urgency to deliver integration has outpaced security review, but it adjusts expectations: the 9.2 measures the potential damage, not the universal ease of exploitation.
The affected versions of the Apigee-X runtime are prior to 1.14.4, 1.15.2, and 1.16.1. As it is a managed service, the underlying fix is applied by Google itself to the runtime, which changes the nature of the client's response compared to an on-premises installed product.
What the Client Still Needs to Do
Managed service does not mean zero responsibility. Even with the runtime patched by Google, it is the client's duty to hunt down the proxies that use the SetIntegrationRequest policy and review if any of them carry the insecure configuration that exposes the flank. It is also necessary to assess the scope of the service accounts linked to Apigee: the broader the privilege of these accounts, the greater the prize that a leaked token represents. The principle of least privilege, here, is the difference between a contained incident and a pivot point for the remainder of the project in the cloud. The release note itself provides the audit roadmap: runtimes prior to 1.14.4, 1.15.2, and 1.16.1 carry the defect, and confirming which of them each environment runs is the first item of the checklist.
What Changes for Brazil
Apigee occupies a specific place in the Brazilian market: it is one of the API management layers used by banks and fintechs to expose the regulated interfaces of Open Finance Brazil. It is through such gateways that consents, account data, and payment initiations flow between institutions. An SSRF that leaks service account credentials precisely at this layer is sensitive by definition, as the gateway sits directly over the data flow that regulation mandates to protect.
The reading for the CISO of a Brazilian financial institution has two sides. The first is the good news: as a managed service, Apigee-X does not require a patching rush in the middle of the night as an internally installed server would. The second is the leftover work: auditing the configuration of the proxies that expose regulated APIs and confirming that no service account has accumulated permissions beyond what is necessary. The insecure configuration that the vulnerability demands does not arise from malice; it stems from proxies hastily assembled to meet regulatory deadlines, and this is where the review needs to come in.
The lesson that runs through the case is less about this CVE and more about the blind spot of the managed model. Moving infrastructure to a vendor-operated service transfers the patch, not the responsibility for configuration. The part that remains in the client's hands, how the proxy has been set up and how much privilege the service account carries, is precisely what this vulnerability demands.