F5 hat eine kritische, bereits aktiv ausgenutzte Schwachstelle im BIG-IP Access Policy Manager geschlossen. Über CVE-2026-94127 können Angreifer ohne vorherige Anmeldung Code auf einem betroffenen BIG-IP-System ausführen. F5 veröffentlichte am 22. September Engineering-Hotfixes; die US-Sicherheitsbehörde CISA nahm die Lücke am selben Tag in ihren Katalog bekanntermaßen ausgenutzter Schwachstellen auf.
Die Reichweite ist enger, als die Produktbezeichnung zunächst vermuten lässt: Betroffen sind nur Systeme, auf denen APM als OAuth-Autorisierungsserver arbeitet. Genau diese Konfigurationsbedingung entscheidet darüber, welche Installationen sofort behandelt werden müssen. Eine Beschränkung der BIG-IP-Verwaltungsoberfläche schützt nicht, weil der Angriff gegen den für OAuth-Verkehr erreichbaren virtuellen Server gerichtet ist.
Betroffenheit hängt an Rolle und Konfiguration
Für einen verwundbaren Aufbau müssen eine APM-Zugriffsrichtlinie und ein OAuth-Autorisierungsserver-Profil auf demselben virtuellen Server zusammenkommen. Dieser virtuelle Server stellt die Adresse bereit, an der das BIG-IP-System den OAuth-Verkehr entgegennimmt. Speziell präparierter Datenverkehr kann dort einen Heap-basierten Pufferüberlauf auslösen und zur Ausführung von Code führen.
Wann CVE-2026-94127 zur unauthentifizierten RCE führt
Die Grafik zeigt den verwundbaren Pfad vom präparierten OAuth-Verkehr über einen passend konfigurierten BIG-IP-Virtual-Server bis zur Codeausführung.
Eine Authentifizierung ist dafür nicht erforderlich. F5 bewertet die Schwachstelle mit 9,8 von 10 Punkten nach CVSS 3.1 und mit 9,3 nach CVSS 4.0. Auch BIG-IP-Systeme im Appliance-Modus bleiben verwundbar. Installationen, die APM ausschließlich als OAuth-Client oder Resource Server verwenden und kein Profil für einen OAuth-Autorisierungsserver besitzen, sind nach der aktualisierten F5-Beschreibung nicht betroffen.
F5 präzisierte diese Einschränkung am 23. September um 00:45 Uhr UTC. Zuvor veröffentlichte Hinweise von CISA und CERT-EU beschrieben die Bedingung noch allgemeiner als Kombination aus Zugriffsrichtlinie und OAuth-Profil. Betreiber sollten sich deshalb nicht allein auf frühe Kurzfassungen verlassen, sondern die tatsächlich konfigurierte OAuth-Rolle prüfen.
Für drei Versionszweige gibt es eigene Hotfixes
Im Zweig 21.1 ist BIG-IP 21.1.0 vor Installation von Hotfix-BIGIP-21.1.0.2.0.30.22-ENG betroffen. Für die Versionen 17.5.0 bis 17.5.1 ist Hotfix-BIGIP-17.5.1.9.0.160.12-ENG vorgesehen. Im Zweig 17.1 betrifft die Lücke die Versionen 17.1.0 bis 17.1.3; hier lautet der Fix Hotfix-BIGIP-17.1.3.5.0.41.14-ENG.
Versionen außerhalb des technischen Supports hat F5 nicht bewertet. Ihr Status ist daher unbekannt und darf nicht als nicht betroffen interpretiert werden. Zusätzlich kann ein bereits gegen eine ältere APM-Schwachstelle aktualisiertes System weiterhin verwundbar sein: Die für CVE-2025-53521 veröffentlichten Stände 17.1.3 und 17.5.1.3 liegen innerhalb der nun betroffenen Bereiche. Nutzt ein solches System APM als OAuth-Autorisierungsserver, benötigt es auch den neuen Hotfix.
Der Schutz der Management-Schnittstelle greift hier nicht
Bei Netzwerk-Appliances konzentrieren sich Schutzmaßnahmen häufig auf die Administrationsoberfläche. In diesem Fall liegt der verwundbare Pfad jedoch im produktiven OAuth-Endpunkt. Der schädliche Verkehr erreicht den virtuellen Server, nicht zwingend das Management-Interface. IP-Beschränkungen oder eine anderweitig abgeschottete Verwaltung beseitigen den Angriffsweg deshalb nicht.
Das operative Problem liegt damit weniger in der Suche nach einem bestimmten Gerät als in der Zuordnung seiner Funktionen. Teams müssen feststellen, welche virtuellen Server ein APM-Zugriffsprofil tragen, ob darin ein OAuth-Autorisierungsserver-Profil ausgewählt ist und welcher Softwarestand tatsächlich läuft. Ein Inventar, das nur Produkt und Hauptversion erfasst, reicht für diese Entscheidung nicht aus.
Mitigation, Beweissicherung und Hotfix gehören zusammen
Wenn sich der Engineering-Hotfix nicht sofort installieren lässt, stellt F5 über den Support eine iRule als vorläufige Mitigation für den betroffenen virtuellen Server bereit. CISA wies US-Bundesbehörden an, zunächst diese iRule einzusetzen, um eine proaktive forensische Prüfung zu ermöglichen, und anschließend den endgültigen Hersteller-Fix so schnell wie möglich zu installieren. Für zivile Bundesbehörden galt dafür eine Frist bis zum 25. September 2026.
CERT-EU empfiehlt, vor den Änderungen forensische Beweise zu sichern, danach den Hotfix einzuspielen und nach Anzeichen einer Kompromittierung zu suchen. Das ist relevant, weil ein Patch zwar den verwundbaren Codepfad schließt, aber keine Aussage darüber erlaubt, ob ein Angreifer das System zuvor bereits übernommen oder weiteren Zugang eingerichtet hat. Die veröffentlichten Hinweise bestätigen nicht, dass eine Installation des Hotfixes bestehenden Angreiferzugriff entfernt.
Diese Spuren rechtfertigen eine manuelle Untersuchung
F5 nennt wiederholte fehlgeschlagene UserInfo-Anfragen in /var/log/apm als mögliches Signal. Dabei erscheint die Fehlerbeschreibung „The access token is invalid.“ Besondere Aufmerksamkeit verdienen zehn oder mehr solcher Anfragen von einer einzelnen IP-Adresse innerhalb kurzer Zeit. Ergänzend lässt sich mit tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed prüfen, ob der Wert für fehlgeschlagene OAuth-Vorgänge unerklärlich gestiegen ist.
Verdächtige Befehle in /var/log/audit rund um diese Zeitpunkte sind ein stärkeres Indiz. Auch TMM-Core-Dateien sollten untersucht werden: F5 hat beobachtet, dass der Traffic Management Microkernel in eine Schleife geraten kann, woraufhin der SOD-Daemon ein SIGABRT auslöst. Ein solcher Absturz ist allein noch kein Beleg für einen Angriff. Die Kombination aus OAuth-Fehlern, verdächtigen Befehlen und einem kurz darauf auftretenden TMM-SIGABRT sollte jedoch eine menschliche Prüfung auslösen.
Wie viele Systeme angegriffen wurden, wer hinter den Angriffen steht und welche Organisationen betroffen sind, ist bislang nicht veröffentlicht. Fest steht nur die aktive Ausnutzung. Für Betreiber folgt daraus eine klare Reihenfolge: Konfiguration statt Produktname prüfen, exponierte virtuelle Server vorläufig absichern, Beweise erhalten, den passenden Hotfix installieren und anschließend klären, ob der Angriff dem Patch bereits vorausgegangen ist.
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?
