SSRF in Google Cloud Apigee-X kann Dienstkontotoken auslösen (CVE-2026-2264)
Ein Fehler in der Policy SetIntegrationRequest von Apigee erhielt 9,2 im CVSS und ermöglicht die Exfiltration von Dienstkontotoken, hängt jedoch von einer vorher unsicheren Konfiguration im API-Proxy ab.
Google Cloud hat eine Schwachstelle in Form von Server-Side Request Forgery (SSRF) in Apigee-X, seiner API-Management-Plattform, behoben, die in der Lage ist, Zugangstoken von Dienstkonten zu exfiltrieren. Die am 26. Mai im Sicherheitsbulletin gcp-2026-034 bekanntgegebene CVE-2026-2264 erhielt eine Bewertung von 9,2 im CVSS 4.0, mit einem wichtigen Vorbehalt, der im Hinweis selbst enthalten ist.
Die Schwachstelle und ihre Eintrittsbedingungen
Das Problem liegt in der Policy SetIntegrationRequest von Apigee. Laut Google Cloud kann ein entfernter Angreifer diese nutzen, um eine SSRF (CWE-918) auszuführen und Zugangstoken von Dienstkonten zu exfiltrieren, die Anmeldeinformationen, die der API-Proxy verwendet, um mit anderen Google Cloud-Diensten zu kommunizieren. Mit diesen Tokens erbt der Angreifer die Berechtigungen des Dienstkontos, was in der Regel den Zugriff auf Ressourcen weit über das Gateway hinaus bedeutet.
Der Vorbehalt ist im Hinweis verankert und sollte nicht in der Eile ignoriert werden: Damit die Ausnutzung funktioniert, muss ein Administrator zunächst eine unsichere Konfiguration im API-Proxy eingerichtet haben. Der CVSS 4.0 Vektor spiegelt dies wider, indem er vorhandene Angriffsvoraussetzungen markiert (AT:P). Mit anderen Worten, die Schwachstelle tritt nicht von selbst in jeder Standardinstallation auf; sie hängt von einem offenen Tor in der Konfiguration ab. Das macht sie nicht harmlos, denn unsichere Proxy-Konfigurationen sind dort häufig, wo der Druck, die Integration bereitzustellen, die Sicherheitsüberprüfung überwindet, stellt jedoch die Erwartung richtig: Die 9,2 misst den möglichen Schaden, nicht die universelle Einfachheit.
Die betroffenen Versionen des Apigee-X-Runtimes sind vor 1.14.4, 1.15.2 und 1.16.1. Da es sich um einen verwalteten Dienst handelt, wird die grundlegende Korrektur vom Google selbst im Runtime angewendet, was die Natur der Reaktion des Kunden im Vergleich zu einem lokal installierten Produkt verändert.
Was der Kunde noch tun muss
Ein verwalteter Dienst bedeutet nicht null Verantwortung. Selbst mit dem von Google korrigierten Runtime liegt es am Kunden, die Proxys zu identifizieren, die die Policy SetIntegrationRequest verwenden, und zu überprüfen, ob einer von ihnen die unsichere Konfiguration aufweist, die den Bereich öffnet. Es ist auch wichtig, den Umfang der mit Apigee verbundenen Dienstkonten zu bewerten: Je breiter die Privilegien dieser Konten, desto wertvoller ist ein ausgegebenes Token. Das Prinzip des minimalen Privilegs ist hier der Unterschied zwischen einem eingegrenzten Vorfall und einem Pivot zu dem restlichen Projekt in der Cloud. Das Release-Note bietet den Prüfungsleitfaden: Runtimes vor 1.14.4, 1.15.2 und 1.16.1 haben den Fehler, und zu bestätigen, welcher von ihnen in jeder Umgebung läuft, ist der erste Punkt der Überprüfung.
Was sich für Brasilien ändert
Apigee nimmt im brasilianischen Markt eine spezifische Position ein: Es ist eine der Schichten des API-Managements, die von Banken und Fintechs verwendet wird, um die regulierten Schnittstellen des Open Finance Brasil zu veröffentlichen. Über solche Gateways werden Einwilligungen, Kontodaten und Zahlungsinitiierungen zwischen Institutionen übertragen. Eine SSRF, die Anmeldeinformationen von Dienstkonten genau in dieser Schicht offenbart, ist definitionsgemäß sensibel, da das Gateway genau über dem Datenfluss sitzt, den die Regulierung zu schützen befiehlt.
Die Lesart für den CISO einer brasilianischen Finanzinstitution hat zwei Seiten. Die erste ist die gute Nachricht: Da es sich um einen verwalteten Dienst handelt, erfordert Apigee-X keine Patch-Rennerei mitten in der Nacht, wie es ein lokal installierter Server tun würde. Die zweite ist die Arbeit, die übrig bleibt: die Konfiguration der Proxys, die regulierte APIs exponieren, zu prüfen und zu bestätigen, dass kein Dienstkonto mehr Berechtigungen angesammelt hat als notwendig. Die unsichere Konfiguration, die der Fehler fordert, entsteht nicht aus böser Absicht; sie entsteht aus Proxys, die hastig eingerichtet wurden, um regulatorische Fristen einzuhalten, und genau hier muss die Überprüfung eingreifen.
Die Lehre, die sich aus dem Fall zieht, betrifft weniger diese CVE und mehr den blinden Fleck des verwalteten Modells. Die Infrastruktur zu einem vom Anbieter betriebenen Dienst zu bewegen, überträgt den Patch, nicht die Verantwortung für die Konfiguration. Der Teil, der weiterhin in der Hand des Kunden liegt, wie der Proxy konfiguriert wurde und wie viel Privileg das Dienstkonto hat, ist genau der Teil, den dieser Fehler einfordert.