Angreifer versuchen derzeit, eine kritische Authentifizierungslücke in mehreren WSO2-Produkten auszunutzen. Über CVE-2026-5430 lassen sich speziell präparierte JSON Web Tokens einschleusen, die bereits Administratorrechte enthalten. Das Honeypot-Netzwerk des Sicherheitsunternehmens watchTowr registrierte entsprechende Tokens am 13. September 2026.
Die Schwachstelle ist aus der Ferne und ohne vorhandenes Benutzerkonto ausnutzbar; eine Interaktion durch Beschäftigte ist nicht erforderlich. WSO2 hatte bereits im Frühjahr reagiert: Der Hersteller stellte im April eine Korrektur bereit und veröffentlichte im Mai das Advisory WSO2-2026-5328. Gefährdet sind damit vor allem Installationen, in denen die bereitgestellten Updates bis heute fehlen.
Die Beobachtung von watchTowr belegt aktive Ausnutzungsversuche, aber noch nicht automatisch eine erfolgreiche Kompromittierung jedes angegriffenen Systems. Für Betreiber ist diese Unterscheidung wichtig, ändert jedoch nichts an der Priorität: Eine ungepatchte und aus dem Netzwerk erreichbare Instanz sollte unverzüglich aktualisiert und anschließend auf verdächtige Zugriffe untersucht werden.
Die Signaturprüfung akzeptiert das Unerwartete
CVE-2026-5430 betrifft die Prüfung kryptografischer Signaturen bei der JWT-Authentifizierung. Der Dienst kann Tokens akzeptieren, die mit einem nicht unterstützten Algorithmus signiert wurden, anstatt sie konsequent zurückzuweisen. Dadurch lässt sich die Authentifizierung umgehen. Die Schwäche wird als CWE-347, Improper Verification of Cryptographic Signature, eingeordnet.
Angriffsweg bei CVE-2026-5430
Die Grafik zeigt den beobachteten Ausgangspunkt mit einem gefälschten Admin-JWT, die fehlerhafte Signaturprüfung und die möglichen Folgen eines erfolgreichen Zugriffs.
Ein Angreifer benötigt nach den vorliegenden Angaben weder vorherige Rechte noch die Mitwirkung eines Nutzers. Er kann einen manipulierten JWT erzeugen, darin administrative Berechtigungen hinterlegen und ihn an eine betroffene WSO2-Installation senden. WSO2 nennt unbefugten Zugriff auf geschützte Ressourcen, die Übernahme administrativer Konten und eine vollständige Kontoübernahme als mögliche Folgen.
Der offizielle CVSS-Wert beträgt 9,8 von 10. watchTowr bewertet die Schwachstelle mit 10,0. Die Abweichung ändert die operative Einschätzung kaum: Es handelt sich um eine aus der Ferne erreichbare Authentifizierungsumgehung ohne notwendige Vorrechte oder Benutzerinteraktion.
Diese Produkte und Versionen sind betroffen
Die Lücke steckt nicht nur im eigenständigen API Manager. WSO2 führt folgende Produkte und Versionsstände auf:
WSO2 API Manager: 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 und 4.6.0. WSO2 API Control Plane: 4.5.0 und 4.6.0. WSO2 Traffic Manager: 4.5.0 und 4.6.0. WSO2 Universal Gateway: 4.5.0 und 4.6.0.
Für Inhaber eines WSO2-Supportvertrags stehen korrigierte Update-Level bereit. Beim API Manager sind dies Level 257 für Version 4.1.0, 197 für 4.2.0, 108 für 4.3.0, 72 für 4.4.0, 57 für 4.5.0 und 21 für 4.6.0. Für die API Control Plane gelten Level 58 bei Version 4.5.0 und 22 bei 4.6.0.
Beim Traffic Manager sind die Update-Level 56 für 4.5.0 und 21 für 4.6.0 vorgesehen. Beim Universal Gateway lauten sie 57 beziehungsweise 21. Community-Nutzer erhalten die Änderungen über die WSO2-Pull-Requests carbon-apimgt #13752 und product-apim #14167.
Ein API-Manager bündelt besonders wertvolle Zugriffe
Die praktische Tragweite ergibt sich nicht allein aus einem übernommenen Administratorkonto. Ein API-Manager steht zwischen aufrufenden Anwendungen und den dahinterliegenden Diensten. Er verwaltet Endpunkte, Zugriffsregeln und Zugangsdaten für angebundene APIs. Ein erfolgreicher Angriff trifft deshalb eine Komponente, in der viele technische Vertrauensbeziehungen zusammenlaufen.
watchTowr vermutet, dass die beobachteten Admin-Tokens dazu dienen sollten, auf API-Backend-Endpunkte sowie auf Anmeldedaten, Consumer Keys und Secrets registrierter Anwendungen zuzugreifen. Darüber hinaus könnte eine kompromittierte Instanz Einblicke in sensible Daten liefern, die auf dem Weg zu internen Systemen verarbeitet werden, oder den Zugriff auf interne Dienste erleichtern. Das sind mögliche Folgen des Zugriffswegs; die Honeypot-Beobachtung allein weist noch keinen konkreten Datendiebstahl in einer Kundenumgebung nach.
Patchen schließt die Lücke, beantwortet aber nicht die Rückschau
Betreiber sollten zunächst sämtliche WSO2-Instanzen und ihren tatsächlichen Update-Stand erfassen. Entscheidend ist nicht nur der API Manager: Auch getrennt betriebene Control-Plane-, Traffic-Manager- und Universal-Gateway-Komponenten müssen geprüft werden. Danach sind die von WSO2 genannten Update-Level beziehungsweise die Community-Korrekturen einzuspielen.
Weil Angriffsversuche bereits beobachtet wurden, reicht die Installation des Patches als alleinige Reaktion nicht in jedem Fall aus. Sie verhindert weitere Ausnutzung über diese Schwachstelle, klärt aber nicht, ob zuvor ein gefälschtes Token akzeptiert wurde. Betreiber ungepatchter und erreichbarer Systeme sollten deshalb Authentifizierungs- und Administrationszugriffe untersuchen, ungewöhnliche Token-Nutzung prüfen und die Verwendung beziehungsweise Offenlegung von Backend-Zugangsdaten, Consumer Keys und Secrets nachvollziehen. Bei einem begründeten Verdacht sollten betroffene Zugangsdaten erneuert werden.
Der zeitliche Abstand ist dabei der entscheidende operative Punkt: Zwischen der Bereitstellung der Korrektur im April, dem Advisory im Mai und den beobachteten Angriffen im September lagen mehrere Monate. CVE-2026-5430 ist daher nicht primär ein Fall fehlender Verfügbarkeit eines Patches. Das verbleibende Risiko hängt daran, ob Betreiber ihn über alle betroffenen WSO2-Komponenten hinweg tatsächlich ausgerollt haben.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
