F5 BIG-IP APM: Kritische Lücke wird aktiv ausgenutzt

Bei dieser Schwachstelle ist nicht die Komplexität das Problem. Sondern ihre Lage.

F5 BIG-IP APM sitzt in vielen Umgebungen dort, wo Zugriffe geregelt, Sitzungen bewertet und Authentifizierungsflüsse gesteuert werden. Wenn ausgerechnet in der OAuth-Komponente eine kritische Lücke steckt, verschiebt sich das Risiko sofort vom einzelnen Dienst zur Zugangsschicht. CERT.at warnt nun vor CVE-2026-94127, einer Schwachstelle in F5 BIG-IP APM, die unauthentifizierte Codeausführung aus der Ferne ermöglichen kann. Laut Originalmeldung von CERT.at gibt es Hinweise darauf, dass die Lücke bereits aktiv ausgenutzt wird.

Das ist der entscheidende Punkt für Betreiber: Dies ist kein Eintrag für die nächste reguläre Wartungsrunde. Wer BIG-IP APM in den betroffenen Versionen als Authorisierungsserver über OAuth-Funktionalität nutzt, muss die eigenen Instanzen prüfen, Hotfixes einspielen oder zumindest eine temporäre Gegenmaßnahme umsetzen.

Ein Header als Angriffsfläche

Die technische Beschreibung ist knapp, aber unangenehm klar. Die Lücke befindet sich in der OAuth-Komponente von F5 BIG-IP APM. Angreifer können sie laut CERT.at durch das Setzen eines zu langen Authorization-Headers ausnutzen. Eine speziell präparierte Anfrage kann demnach dazu führen, dass Befehle ohne vorherige Authentifizierung ausgeführt werden.

Das macht die Schwachstelle operativ heikel. Der Authorization-Header ist kein exotischer Randbereich eines Systems. Er gehört zu den normalen Bestandteilen von Authentifizierungs- und Autorisierungsprozessen. Wenn eine solche Stelle anfällig ist, hilft es wenig, sich darauf zu verlassen, dass ein Angriff auffällig kompliziert wäre. CERT.at bewertet die Schwachstelle mit einem CVSS-v4.0-Base-Score von 9.3. Der Schweregrad ist damit nicht nur theoretisch hoch; die gemeldete aktive Ausnutzung macht daraus ein laufendes Betriebsproblem.

Betroffen ist eine klar umrissene Nutzung

Nicht jede F5-Installation ist nach den vorliegenden Angaben automatisch betroffen. CERT.at nennt Systeme, die BIG-IP APM als Authorisierungsserver über die OAuth-Funktionalität einsetzen. Genau diese Einschränkung ist wichtig. Sie entlastet nicht, sie präzisiert die Arbeit: Betreiber müssen nicht raten, sondern ihre APM-Nutzung und die eingesetzten Versionen abgleichen.

Als betroffen nennt CERT.at BIG-IP APM 21.1.0, die Versionen 17.5.0 bis 17.5.1 sowie 17.1.0 bis 17.1.3. Für diese Systeme stellt F5 Hotfixes bereit. Wo ein kurzfristiges Update nicht möglich ist, verweist CERT.at auf eine von F5 empfohlene iRule als Zwischenmaßnahme, die über den Support bezogen werden kann.

Das ist kein Ersatz für das Schließen der Lücke. Eine Mitigation ist eine Brücke, keine Reparatur. In produktiven Umgebungen kann diese Brücke trotzdem entscheidend sein, weil Zugangsinfrastruktur oft nicht ohne Vorbereitung neu gestartet, verändert oder ausgetauscht wird. Genau dort entsteht das bekannte Sicherheitsfenster: Die Schwachstelle ist bekannt, die Ausnutzung läuft, aber die technische Änderung muss noch durch Change-Prozesse, Tests und Betriebsfreigaben.

Patchen reicht hier nicht als Antwort

Bei aktiver Ausnutzung verschiebt sich die Reihenfolge der Fragen. Es geht nicht nur darum, ob ein System verwundbar war. Es geht darum, ob es bereits berührt wurde. CERT.at empfiehlt ausdrücklich, die eigenen Instanzen auf Indicators of Compromise zu überprüfen, die im veröffentlichten Advisory enthalten sind.

Für Sicherheitsteams bedeutet das: Versionen erfassen, OAuth-Nutzung verifizieren, Hotfix-Status prüfen, temporäre iRule nur dort einsetzen, wo Updates nicht zeitnah möglich sind, und anschließend nach Spuren einer möglichen Kompromittierung suchen. Die Untersuchung darf nicht hinter dem Patch verschwinden. Ein geschlossenes Einfallstor sagt nichts darüber aus, ob vorher Befehle ausgeführt wurden.

Gerade bei Zugangssystemen ist diese Unterscheidung zentral. Sie stehen häufig zwischen externen Anfragen und internen Anwendungen. Wenn dort Codeausführung ohne Authentifizierung möglich ist, betrifft das nicht nur die einzelne Appliance oder Instanz, sondern die Vertrauensannahmen darum herum. Welche Systeme hängen dahinter? Welche Rollen erfüllt die APM-Instanz? Welche Protokolle und Logs sind für den Zeitraum vor dem Update auswertbar? Solche Fragen entscheiden darüber, ob eine Organisation nur eine Schwachstelle geschlossen oder einen Vorfall sauber eingegrenzt hat.

Die operative Lehre ist nüchtern

Die Meldung zeigt einmal mehr, wie eng Identitäts- und Zugriffsinfrastruktur inzwischen mit Angriffsfläche verbunden ist. OAuth-Komponenten, Header-Verarbeitung und Gateway-Funktionen sind keine Nebentechnik. Sie sind Teil der Kontrollschicht, über die Zugänge verteilt und begrenzt werden. Wenn dort ein Fehler unauthentifizierte Befehlsausführung erlaubt, ist die Reaktionszeit kurz.

CERT.at empfiehlt generell, Software aktuell zu halten, automatische Updates zu nutzen und Systeme regelmäßig neu zu starten, damit Aktualisierungen auch wirksam werden. Für F5-Betreiber mit den genannten APM-Versionen ist die Lage konkreter: Hotfix einspielen, falls nötig temporär mitigieren, und die eigenen Systeme anhand der bereitgestellten Hinweise auf mögliche Kompromittierung prüfen.

Der riskante Teil dieser Meldung ist nicht, dass ein weiteres Produkt eine kritische Lücke hat. Der riskante Teil ist, dass sie an einer Stelle sitzt, die Anfragen bewertet, bevor Nutzer überhaupt als vertrauenswürdig gelten. Genau dort bleibt wenig Raum für Abwarten.