WSO2 API Manager: Sicherheitslücke bei Admin-Token
Sicherheitsanfälligkeit von 9,8 ermöglicht Fälschung von Admin-Token in WSO2 API Manager Versionen 4.1 bis 4.6; honeypot von watchTowr registrierte bösartigen Verkehr am 13. September.
Die watchTowr gab am 16. September bekannt, dass ihr Netzwerk von Honeypots in der Nacht vom 13. September begann, echte Ausnutzungsversuche der CVE-2026-5430 gegen exponierte Instanzen des WSO2 API Managers zu erfassen. Die beobachteten JWT-Tokens sind bereits mit eingebetteten Administratorprivilegien signiert und bereit, gegen jeden Endpunkt des Gateways zu authentifizieren, als ob der Angreifer der legitime Betreiber wäre. Die Sicherheitsanfälligkeit hat einen CVSS-Score von 9,8, dem praktischen Höchstwert der Skala.
Der Ursprung ist ein Mangel bei der kryptografischen Überprüfung: WSO2 akzeptierte JWTs, die mit Algorithmen signiert waren, die nicht unterstützt werden sollten, und der Parser blockierte den Datenfluss nicht. Ein Angreifer, der von der Schwachstelle wusste, konnte ein Token erstellen, das Benutzerfeld als admin definieren, es mit einem zulässigen Algorithmus signieren und der API vorlegen. Das Gateway gewährte Zugriff. Der Fehler wurde von Forschern des Hacktron-Teams entdeckt und betrifft die Versionen 4.1.0 bis 4.6.0 des API Managers sowie die Module API Control Plane, Traffic Manager und Universal Gateway im gleichen Bereich. WSO2 veröffentlichte die Warnung WSO2-2026-5328 mit Patches in allen unterstützten Branches.
Die Größe des exponierten Parks
WSO2 ist einer der API-Gateway-Betreiber mit der größten Präsenz im Bereich Regierung, Telekommunikation, Banken und Gesundheit. Laut Unternehmensmaterial sind die API Manager in mehr als 90 Ländern im Einsatz, verarbeiten täglich 50 Milliarden Transaktionen und decken einen aggregierten Katalog von 200.000 APIs ab. Es ist die Verkehrsoberfläche, durch die ein erheblicher Teil des Flusses zwischen digitalen Banken, Mobilfunkbetreibern und Regierungsdiensten in verschiedenen Jurisdiktionen verläuft.
Die Liste der Exposition ist aus zwei Gründen problematisch, die selten zusammen auftreten. Erstens wird das Produkt häufig in eigenen Rechenzentren installiert, was bedeutet, dass viele Betreiber keine automatischen Updates erhalten und auf vierteljährliche Wartungsfenster angewiesen sind. Zweitens ermöglicht die Schwachstelle die Fälschung von Tokens, ohne gültige Anmeldeinformationen zu verlangen, was jede soziale Ingenieurkunst oder vorhergehendes Leck überflüssig macht.
Wo das Problem regional ankommt
Im Vereinigten Königreich arbeitet WSO2 innerhalb des technischen Stacks von Challenger-Banken und NHS-Diensten. Ein kompromittiertes Gateway dort exponiert Operationen des Open Banking und Integrationen der elektronischen Krankenakte. In Indien, wo die Aadhaar-API und das UPI auf Integrationsschichten dieses Standards basieren, ist ein Eindringfenster von Tagen zwischen Patch und Anwendung eine direkte Einladung für staatliche Akteure und organisiertes Verbrechen.
Brasilien hat eine eigene Exposition. Große Banken, Versicherungen und Stadtverwaltungen nutzen WSO2 als Zwischenebene zwischen Legacy-Systemen und digitalen Front-Ends. In einer typischen Integration des Open Finance trägt das Gateway Langzeitanmeldeinformationen für Dutzende von Fintechs. Ein gefälschtes Admin-Token ermöglicht es, diese Anmeldeinformationen aufzulisten und den Angriff gegen Partner neu zu ordnen. Laut watchTowr war das in den Honeypots beobachtete Payload genau darauf ausgelegt, Verbraucherschlüssel und Geheimnisse registrierter Anwendungen zu entdecken und zu exfiltrieren.
Die Uhr des Verteidigers
"Das ist die Art von Schwachstelle, die eine Implementierung zu einem Ausgangspunkt für die gesamte Lieferkette dahinter macht", sagte watchTowr in ihrem technischen Bulletin. Das Unternehmen empfahl, vorübergehend nicht verwendete Signaturalgorithmen zu deaktivieren, aktive Tokens zu widerrufen und nach der Patch-Anwendung die Geheimnisse zu drehen. WSO2 forderte ein sofortiges Upgrade auf die korrigierten Versionen oder die Anwendung der Out-of-Band-Patches in 4.1, 4.2, 4.3, 4.4, 4.5 und 4.6.
Die Kosten für Verzögerungen sind selten gerechtfertigt. Die historische Ausnutzungsrate für Bugs in JWT-Signaturen folgt dem gleichen Muster: ein enges Zeitfenster zwischen Entdeckung und Verfügbarkeit automatisierter Scanner, schnelle Ausbreitung durch opportunistische Betreiber, sobald das Exploit bekannt wird. Die watchTowr berichtet, dass der beobachtete Verkehr Merkmale einer koordinierten Kampagne aufweist, nicht eines isolierten Tests.
Eine separate Notiz für die Third-Party-Risiko-Teams: Eine Integration mit einer Versicherungsgesellschaft, einem Zahlungsabwickler oder einem Mobilfunkbetreiber, die von einem WSO2-Gateway abhängt, erbt den Vektor. Eine schriftliche Bestätigung über die installierte Version und den Patch-Status anzufordern, ist diese Woche eine legitime Tätigkeit der Due Diligence, keine Paranoia.
Es gibt auch eine stille Botschaft an Plattformarchitekten. Die CVE-2026-5430 ist nicht komplex. Es ist ein klassischer Validierungsfehler bei der Signatur, derselbe Typ von Bug, der 2015 und 2018 JWT-Bibliotheken betroffen hat und der bereits durch automatisierte Fuzzing-Tests in jedem kritischen Produkt abgedeckt sein sollte. Die Tatsache, dass er bis 2026 im WSO2 überlebt hat, deutet auf eine Deckungslücke in Test-Suites hin, die Funktionalität priorisieren und nicht die degenerierten Pfade, die Angreifer auswendig wissen.
Für Betreiber in Jurisdiktionen mit obligatorischer Vorfallmeldung beginnt die Uhr früher zu ticken. In den USA verlangt die SEC die Offenlegung innerhalb von vier Werktagen für wesentliche Vorfälle in börsennotierten Unternehmen; in der Europäischen Union legt die NIS2 24 Stunden für die erste Meldung fest. Der Nachweis unbefugten Zugriffs durch ein gefälschtes Token wird kaum als nicht wesentlich interpretiert.