Zum Inhalt springen

Angriffe auf Oracle HTTP Server und WebLogic beobachtet: kritische Lücke wird aktiv ausgenutzt

Die US-Sicherheitsbehörde CISA hat eine kritische Schwachstelle in Oracle HTTP Server und dem Oracle WebLogic Server Proxy Plug-in in ihren Katalog der aktiv ausgenutzten Schwachstellen (Known Exploited Vulnerabilities, KEV) aufgenommen. Der Eintrag ist die offizielle Bestätigung, dass Angreifer die Lücke bereits in echten Angriffen verwenden. Sie trägt die Kennung CVE-2026-21962 und erreicht den maximalen CVSS-Wert von 10.0.

Worum es geht

Betroffen ist nicht der WebLogic-Anwendungsserver selbst, sondern die Komponente, die HTTP-Anfragen an WebLogic weiterreicht: das WebLogic Server Proxy Plug-in, das unter anderem im Oracle HTTP Server steckt und als Brücke zwischen Webserver und WebLogic dient. Die Sicherheitsforscher, die die Lücke gemeldet haben, beschreiben sie als Path-Traversal-Schwachstelle in der Normalisierung von URIs. Über sorgfältig manipulierte URIs lassen sich Sicherheitsmechanismen umgehen, was zu einer Rechteausweitung und zur Ausführung eingeschleusten Codes führt. CISA fasst die Auswirkung als unzureichende Zugriffskontrolle zusammen: Angreifer können kritische Daten unbefugt lesen, erstellen, verändern oder löschen und im Extremfall auf sämtliche über die Komponente erreichbaren Daten zugreifen.

Das Gefährliche an dieser Lücke ist die Kombination aus einfacher Ausnutzbarkeit und maximaler Wirkung. Ein Angreifer braucht weder Zugangsdaten noch eine Interaktion des Opfers. Es genügt, dass das verwundbare System über HTTP aus dem Netz erreichbar ist. Passenden Proof-of-Concept-Code haben die Melder in einem öffentlichen GitHub-Repository bereitgestellt, was die Einstiegshürde für Angreifer weiter senkt.

Betroffene Versionen

Verwundbar sind die von Oracle unterstützten Versionen 12.2.1.4.0, 14.1.1.0.0 und 14.1.2.0.0. Wichtig zur Einordnung: Der bloße Umstand, dass irgendwo WebLogic läuft, bedeutet nicht automatisch, dass ein System betroffen ist. Ausschlaggebend ist, ob das Proxy Plug-in beziehungsweise der Oracle HTTP Server im Einsatz und erreichbar ist. Reine Privatanwender sind von dieser Schwachstelle nicht betroffen, sie richtet sich an Betreiber von Oracle-Serverinfrastruktur.

Warum das jetzt relevant ist

Oracle hat die Lücke bereits mit dem Critical Patch Update vom Januar 2026 geschlossen. Trotzdem wird sie seit Monaten angegriffen. Das Sicherheitsunternehmen CloudSEK meldete, dass seine Honeypots seit dem 22. Januar 2026 Ausnutzungsversuche gegen Oracle WebLogic sahen, also praktisch unmittelbar nachdem ein PoC-Exploit öffentlich geworden war. Neben CVE-2026-21962 fingen die Honeypots dabei auch Angriffe auf ältere, weiterhin beliebte WebLogic-Lücken ab, darunter CVE-2020-14882/CVE-2020-14883 (Console RCE), CVE-2020-2551 (IIOP RCE) und CVE-2017-10271 (WLS-WSAT RCE). Das Muster ist typisch: Angreifer setzen auf eine kleine Zahl einfach ausnutzbarer Schwachstellen, um WebLogic-Umgebungen zu kompromittieren.

Im Februar 2026 fiel laut Berichten eine einzelne IP-Adresse (193.24.123.42) auf, die mehrere bekannte Schwachstellen in Oracle WebLogic, Ivanti Endpoint Manager Mobile, GNU InetUtils und GLPI durchprobierte. FalconFeeds erwähnte die Lücke im Juni im Zusammenhang mit der Lieferkette der Cyberkriminalität, und SOCRadar berichtete im Juli, dass CVE-2026-21962 zu den Schwachstellen gehörte, die ein mutmaßlich China-naher Akteur bei Angriffen auf Regierungsinfrastruktur nutzte. Zur genauen Angriffswelle, die den aktuellen CISA-Alarm auslöste, liegen keine Details vor.

US-Bundesbehörden müssen die Lücke gemäß der verbindlichen Vorgabe der CISA bis zum 27. August 2026 schließen. Der KEV-Katalog richtet sich zwar formal an Behörden, taugt aber für jede Organisation als klares Signal, welche Schwachstellen mit Priorität zu behandeln sind.

Handlungsempfehlungen
  • Prüfen, ob Oracle HTTP Server oder das WebLogic Server Proxy Plug-in im Einsatz sind, insbesondere in den Versionen 12.2.1.4.0, 14.1.1.0.0 und 14.1.2.0.0.
  • Das Oracle Critical Patch Update vom Januar 2026 einspielen, falls das noch nicht geschehen ist. Das ist die eigentliche Behebung.
  • HTTP- und Anwendungs-Logs sichern, bevor sie rotieren, um im Fall der Fälle einen Kompromittierungsverdacht prüfen zu können.