Der Kern der Schwachstelle liegt in der Prüfung von JWT-Token. WSO2 beschreibt das Problem so: „Die JWT-Authentifizierung kann umgangen werden, wenn ein Token mit einem nicht unterstützten Algorithmus signiert ist, wodurch unbefugter Zugriff möglich wird.“ Eine erfolgreiche Ausnutzung könne laut Hersteller zu unbefugtem Zugriff führen, einschließlich der möglichen Kompromittierung administrativer Konten und einer vollständigen Kontoübernahme.
Yordan Ganchev, Principal Threat Intelligence Specialist bei WatchTowr, sagte SecurityWeek, der erste beobachtete Angriffsversuch sei am 13. September in den Honeypots des Unternehmens aufgeschlagen. Der Angreifer habe ein gefälschtes JWT-Token eingesetzt – ein Umstand, der es den Forschern erlaubte, das Ziel des Angriffs zu rekonstruieren.
„Das gefälschte Token verschafft Zugriff auf jeden API-Backend-Endpunkt und dessen Zugangsdaten sowie auf Consumer Keys und Secrets jeder registrierten Anwendung“, erklärte Ganchev. Der Dienst sei zudem per Definition darauf ausgelegt, API-Anfragen auf ihrem Weg zu internen Systemen abzufangen. Das biete eine gute Gelegenheit, sensible Daten während der Übertragung abzugreifen und mit internen Diensten zu interagieren – Ganchev spricht von einem Produkt nach dem Muster „Lateral Movement as a Service“.
Im konkret beobachteten Fall hatte der Angreifer offenbar das falsche Produkt anvisiert. „Wir haben einen einzelnen Angreifer beobachtet, der das falsche Produkt ins Visier nahm; als wir seine Payload jedoch gegen das tatsächliche Produkt wiederholten, funktionierte sie“, so Ganchev. Die Honeypots hätten Glück gehabt, verwechselt worden zu sein – dasselbe lasse sich für reale Opfersysteme nicht garantieren.
Auffällig ist die Zeitschiene: Der Patch stammt vom April, das Herstelleradvisory vom Mai, der CVE-Eintrag zu CVE-2026-5430 wurde nach Angaben von WatchTowr erst Anfang August veröffentlicht. Technische Details scheinen bis heute nicht öffentlich zu sein. WatchTowr konnte die Schwachstelle dennoch ohne größeren Aufwand allein anhand des Herstellerpatches nachstellen. „Das einzige Rätsel hier ist, warum alle anderen so lange gebraucht haben“, kommentierte Ganchev.
Für Betreiber der betroffenen Produkte – API Manager, API Control Plane, Traffic Manager und Universal Gateway – ist damit der von WSO2 bereitgestellte Patch die entscheidende Maßnahme. Angesichts der Position dieser Komponenten als zentrale Vermittlungsschicht zwischen externen Anfragen und internen Systemen wiegt eine Authentifizierungsumgehung besonders schwer: Wer die Token-Prüfung aushebelt, erhält nicht nur Zugang zu einem einzelnen Dienst, sondern potenziell zu den hinterlegten Zugangsdaten sämtlicher angebundener Anwendungen.