Jedes Unternehmen hat eine Maschine, die entscheidet, wer du bist. Du meldest dich einmal an, sie prüft die Sitzung, stellt ein Token aus und sagt jeder Anwendung dahinter, dass sie dir vertrauen soll. In vielen Organisationen ist diese Maschine F5 BIG-IP Access Policy Manager (APM) in der Rolle eines OAuth-Autorisierungsservers.
Am 22. September hat F5 bestätigt, dass Angreifer dort bereits eigenen Code ausführen. Ohne Anmeldung. Die Lücke läuft als CVE-2026-94127, ist mit 9.8 (CVSS v3.1) bewertet, und der Hotfix gehört heute in deinen Kalender, nicht ins nächste Quartal.
Die Kurzfassung
- CVE-2026-94127 ist ein Heap-Buffer-Overflow (CWE-122) in BIG-IP APM, bewertet mit 9.8 nach CVSS v3.1 und 9.3 nach v4.0.
- Sie existiert nur dort, wo APM als OAuth-Autorisierungsserver konfiguriert ist, also eine Access Policy zusammen mit einem OAuth-Profil auf demselben virtuellen Server.
- Speziell präparierter bösartiger Traffic an diesen virtuellen Server führt zur Remote-Code-Ausführung durch einen nicht authentifizierten Angreifer.
- F5 hat die Lücke am 22. September veröffentlicht und Engineering-Hotfixes bereitgestellt. CISA nahm sie am selben Tag in den KEV-Katalog auf und gab US-Bundesbehörden Zeit bis zum 25. September.
- F5 formuliert es so: „We have learned that this vulnerability has been exploited.“
Drei Tage von der Meldung bis zur Frist für Bundesbehörden. Das ist die neue Patch-Arithmetik, und es ist kein Tippfehler.
Was die Lücke konkret ist
BIG-IP APM ist das Modul, das den Zugriff auf deine Anwendungen vermittelt: Es führt die Access Policy aus, prüft den Gerätezustand und stellt die Tokens aus, die nachgelagerte Anwendungen als Identitätsnachweis akzeptieren.
Die verwundbare Konfiguration ist eng, aber verbreitet: eine APM-Access-Policy und ein OAuth-Autorisierungsserver-Profil auf demselben virtuellen Server. Ist ein System so konfiguriert, kann fehlerhafter Traffic an den virtuellen Server einen Heap-Puffer überlaufen lassen und dem Angreifer die Ausführung übergeben.
Betroffene Branches und ihre Fixes:
- 21.1 — 21.1.0 vor dem Hotfix →
Hotfix-BIGIP-21.1.0.2.0.30.22-ENG - 17.5 — 17.5.0 bis 17.5.1 →
Hotfix-BIGIP-17.5.1.9.0.160.12-ENG - 17.1 — 17.1.0 bis 17.1.3 →
Hotfix-BIGIP-17.1.3.5.0.41.14-ENG
Eine gute Nachricht gibt es. Wenn APM ausschließlich als OAuth-Client oder Resource Server läuft, ohne konfigurierte Autorisierungsserver-Profile, bist du nicht betroffen. F5 hat den CVE-Eintrag am 23. September um 00:45 UTC aktualisiert und die Bedingung speziell auf die Rolle des Autorisierungsservers eingegrenzt. Die frühesten Formulierungen von CERT-EU und im KEV-Katalog waren also weiter gefasst als der endgültige Geltungsbereich. Prüfe die Rolle, nicht nur die Version.
Warum das Absichern des Management-Interface nichts rettet
Der Instinkt nach jedem Zero-Day auf einer Edge-Appliance ist, die Admin-Oberfläche hinter einen Jump Host zu legen und das Thema abzuhaken. Hier hilft das nichts.
Das ist ein Problem der Datenebene. Der bösartige Traffic geht an den virtuellen Server, der die OAuth-Flows bedient, also an genau die Adresse, die deine Nutzer und die Nutzer deiner Partner erreichen sollen. F5 stellt klar, dass es keine Exposition der Steuerungsebene gibt, und, entscheidend, dass BIG-IP-Systeme im Appliance-Modus ebenfalls verwundbar sind. Der Appliance-Modus ist genau die Härtung, die man einsetzt, damit diese Geräte schwerer missbraucht werden können.
Die Exposition lautet also nicht „wer erreicht den Management-Port“. Sie lautet „wer erreicht den Identitätsendpunkt“. In den meisten Architekturen ist das das Internet.
Und diese Appliances sind nicht selten. Shadowserver verfolgt aktuell mehr als 14.700 IP-Adressen mit BIG-IP-APM-Fingerprint. Die Zahl sagt nicht, wie viele davon ungepatcht oder falsch konfiguriert sind, aber sie sagt, wie attraktiv diese Zielklasse ist.
Wie du erkennst, ob du schon getroffen wurdest
Hier wird die Geschichte unangenehm. F5 hat die Lücke als Zero-Day veröffentlicht, das heißt, die ausnutzbaren Details existierten bereits, bevor du einen Patch installieren konntest. Alles, was als Zero-Day ankommt, hat unbekannt viel Vorlaufzeit verbrannt.
F5 hat Indikatoren veröffentlicht, nach denen Defender suchen können. Das Muster, das einen Alarm verdient, ist eine Abfolge, kein Einzelereignis:
- Wiederholte OAuth-Authentifizierungsfehler gegen den BIG-IP-APM-virtuellen-Server.
- Verdächtige Befehle, die kurz danach auftauchen.
- Ein TMM-SIGABRT-Ereignis unmittelbar anschließend.
Wenn du diese Kette in einem Fenster siehst, behandle sie als bestätigte Kompromittierung, nicht als Theorie. Die späteren Schritte des Musters, die Post-Exploitation-Befehle, existieren nur, wenn vorher etwas hineingekommen ist.
Wenn du den Hotfix nicht sofort installieren kannst, hat F5 über seine Support-Kanäle eine iRule veröffentlicht, die als temporäre Mitigation an den betroffenen virtuellen Server gebunden werden kann. Temporär heißt genau das: Sie kauft dir die Stunden, um den echten Fix einzuplanen, sie ersetzt ihn nicht.
Was wir diese Woche tun würden
- Prüfe die Konfiguration, nicht das Versionsbanner. Ein Remote-Scan kann nicht sagen, ob OAuth-Autorisierungsserver-Profile konfiguriert sind. Zieh die Konfiguration und listet jeden virtuellen Server auf, der eine Access Policy und ein OAuth-Profil hat.
- Spiele die benannten Hotfixes für die betroffenen Branches ein, beginnend mit allem, was aus dem Internet erreichbar ist. Wenn ein Wartungsfenster unvermeidbar ist, setz zuerst die iRule und dokumentiere die Ausnahme.
- Suche die IOC-Kette weiter zurück als bis zum 22. September. Angreifer kannten die Lücke vor der Meldung; beginne die Log-Prüfung vor dem Veröffentlichungsdatum.
- Rotiere bei Verdacht, nicht bei Gewissheit. Taucht die Kette auf, geh davon aus, dass die von dieser Appliance ausgestellten Tokens und Client-Secrets kompromittiert sein können. Rotiere OAuth-Client-Secrets, prüfe den Umgang mit Signaturschlüsseln und invalidiere offene Sitzungen.
- Kartiere den Wirkungsradius. Jede Anwendung, die diesen Autorisierungsserver als Identity Provider vertraut, liegt hinter dieser Lücke. Diejenigen, die Tokens blind akzeptieren, ohne Claims erneut zu prüfen, schaust du zuerst an.
- Teste die Wiederherstellung der Identitätsebene. Dein Access Manager steht vor fast allem. Wenn er ausfällt, wie kommst du wieder hinein? Die meisten Teams, mit denen wir sprechen, haben das nie geübt.
Das Fazit
Identitätsinfrastruktur ist heute das Kronjuwel, und die Angreifer sehen das genauso. Vor zwei Tagen haben wir über Check-Point-VPN-Appliances geschrieben, heute ist es F5s Access Manager. Das Muster ist konstant: Die Geräte, die entscheiden, wer hineinkommt, sind die Geräte, die es zu brechen lohnt, und ihre Lücken interessieren sich nicht für deine Einschränkungen am Management-Interface.
Patch das schnell, aber hört nicht beim Patchen auf. Die Drei-Tage-Frist ist ein Signal dafür, wie schnell die Ausnutzung der Veröffentlichung folgt. Erkennung, Konfigurationsprüfung und ein geübter Wiederherstellungspfad tragen dich durch die Tage, an denen du keinen Fix hast.
Wenn du nicht sicher bist, ob dein BIG-IP-APM-Deployment als OAuth-Autorisierungsserver läuft, dann ist genau diese Unsicherheit das Risiko. Schließen wir sie.