In dieser Ausgabe dreht sich alles um Firewalls, Unternehmenssoftware und Server. Cisco bestätigt, dass Angreifer ASA- und FTD-Firewalls über das SSL-VPN zum Neustart bringen, Angreifer kundschaften eine kritische Lücke in Oracle E-Business Suite aus, ein Kernelfehler im TCP-Stack von Linux wartet bei Ubuntu und Red Hat noch auf einen Patch und die GitLab-Lücke mit CVSS 10,0 steht nun im CISA-Katalog, nachdem Alpine Linux angegriffen wurde.
- Cisco ASA und FTD: Angreifer bringen Firewalls über das SSL-VPN zum Neustart
- Oracle E-Business Suite: Kritische SQL-Injection-Lücke wird ausgekundschaftet, Horizon3 veröffentlicht Indikatoren
- Linux-Kernel: TCP-Fehler ermöglicht womöglich Root-Rechte, Ubuntu und Red Hat haben noch keinen Patch
- GitLab-Lücke mit CVSS 10,0: Jetzt aktiv ausgenutzt und in den CISA-Katalog aufgenommen
Cisco ASA und FTD: Angreifer bringen Firewalls über das SSL-VPN zum Neustart
| Schwachstelle | Logikfehler in Cisco Secure Firewall ASA Software und Secure Firewall Threat Defense (FTD) Software beim Remote Access SSL VPN, wenn für eine Tunnelgruppe eine sekundäre Authentifizierung eingerichtet ist. Ein Angreifer ohne Zugangsdaten kann das Gerät zum Neustart bringen (Denial of Service) |
| CVE-Nummer | CVE-2026-76418 |
| CVSS-Score | 8,6 (hoch) |
| Aktiv ausgenutzt | Ja, Cisco PSIRT erfuhr im Oktober 2026 von der Ausnutzung. CISA nahm die Lücke am 29. Oktober 2026 in den KEV-Katalog auf |
| Patch verfügbar | Ja. ASA: 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, 9.24.1.27 und 9.24.10.1. FTD: 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 und 10.1.1 |
Wie kann die Schwachstelle ausgenutzt werden?
Laut dem Cisco-Advisory vom 28. Oktober genügt eine speziell präparierte Anfrage beim Verbindungsaufbau mit dem SSL Remote Access VPN. Ein erfolgreicher VPN-Login ist dafür nicht erforderlich. Verwundbar ist eine Firewall, auf der der VPN-Login-Dienst erreichbar ist und für eine Tunnelgruppe eine sekundäre Authentifizierung eingerichtet ist. Das gilt auch für die Standardgruppe DefaultWEBVPNGroup. The Hacker News berichtet, dass Cisco keine Details zum Beginn der Angriffe, zu den Tätern oder zum Ausmaß nennt. Es ist bereits das zweite Mal seit August, dass Cisco eine ausgenutzte Zero-Day-Lücke im VPN-Dienst dieser Firewalls behebt.
Was können die Folgen sein?
Soweit bekannt, führt dies weder zu Datendiebstahl noch zur Ausführung von Code. Der Angreifer kann die Firewall jedoch wiederholt neu starten lassen, wodurch der Remote-Zugang aller Nutzer hinter diesem Gerät ausfällt. Für einen MSP, der für viele KMU-Kunden das VPN verwaltet, bedeutet das Ausfälle an mehreren Standorten gleichzeitig.
Was sollten IT-Administratoren jetzt tun?
Aktualisieren Sie auf eine der korrigierten Versionen. Ist das nicht sofort möglich, prüfen Sie in der Konfiguration, ob für eine Tunnelgruppe eine sekundäre Authentifizierung eingerichtet ist. Ist das der Fall, können Sie diese vorübergehend deaktivieren. Cisco betrachtet dies als Notlösung, die die Sicherheit des VPN verringert, und für die Standardgruppe gilt, dass das Deaktivieren der Tunnelgruppenliste nur hilft, wenn diese Gruppe selbst keine sekundäre Authentifizierung verwendet. Suchen Sie zudem in den Logs nach unerwarteten Neustarts von ASA- und FTD-Geräten seit Anfang Oktober.
Oracle E-Business Suite: Kritische SQL-Injection-Lücke wird ausgekundschaftet, Horizon3 veröffentlicht Indikatoren
| Schwachstelle | SQL-Injection ohne Authentifizierung im Thin-Client-Framework-Servlet der Application Object Library in Oracle E-Business Suite 12.2.3 bis einschließlich 12.2.15, verkettbar bis zur Codeausführung auf dem Applikationshost |
| CVE-Nummer | CVE-2026-101767 |
| CVSS-Score | 9,8 (kritisch) |
| Aktiv ausgenutzt | Ja, zumindest Erkundungsversuche: Defused beobachtete sie am 27. Oktober 2026 in seinem EBS-Honeypot. Oracle meldet, dass Angreifer bei Kunden erfolgreich waren, die den Patch nicht installiert hatten |
| Patch verfügbar | Ja, im Critical Patch Update vom Oktober 2026 (20. Oktober). Vorübergehende Abhilfe: das Servlet /OA_HTML/AppsTCFServer aus der URL-Allowlist der Firewall entfernen und den Webtier auf vertrauenswürdige Netzwerke beschränken |
Wie kann die Schwachstelle ausgenutzt werden?
Laut Help Net Security entdeckten die Horizon3.ai-Forscher Brandon Peterson, Jimi Sebree und Noah King den Fehler und meldeten ihn am 24. Juli an Oracle. Oracle bezeichnet die Lücke als leicht ausnutzbar und über HTTP erreichbar. Ein Angreifer, der das Servlet erreicht, führt SQL als Datenbankbenutzer APPS aus. Horizon3.ai veröffentlichte Indicators of Compromise, und Censys zählte 2.246 Webpräsenzen mit E-Business Suite. Dabei handelt es sich um Hostnamen und Ports, die Zahl der eindeutigen Systeme liegt also niedriger.
Was können die Folgen sein?
Je nach Installation liegen Finanzdaten, Gehaltsabrechnung, HR und Einkauf offen und können gelesen und verändert werden. Anschließend kann der Angreifer Befehle auf dem Applikationshost ausführen. Das Critical Patch Update ist bereits seit elf Tagen verfügbar, daher sind Umgebungen, die es noch nicht eingespielt haben, jetzt das Ziel.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie bei Kunden mit Oracle E-Business Suite, ob das Oktober-Update installiert ist. Entfernen Sie bis dahin das AppsTCFServer-Servlet aus der Allowlist und schotten Sie den Webtier vom Internet ab. Gleichen Sie die Indikatoren von Horizon3.ai mit den Logs von Webtier und Datenbank ab, insbesondere auf verdächtige Aufrufe von /OA_HTML/AppsTCFServer seit dem 27. Oktober.
Linux-Kernel: TCP-Fehler ermöglicht womöglich Root-Rechte, Ubuntu und Red Hat haben noch keinen Patch
| Schwachstelle | Race Condition beim Aufbau von IPv4-TCP-Verbindungen im Linux-Kernel, die zu einem Use-after-free führt. Der Fehler steckt seit Version 4.4 im Kernel. IPv6 ist nicht betroffen |
| CVE-Nummer | CVE-2026-98432 |
| CVSS-Score | 9,8 laut dem Kernel-CVE-Team. Red Hat, Oracle und SUSE kommen auf 5,9 bis 8,1 und Amazon auf 7,0, weil die Race Condition schwer zu gewinnen ist |
| Aktiv ausgenutzt | Nein, keine Ausnutzung gemeldet und nicht im CISA-Katalog (Stand 29. Oktober). Allerdings hat Anthropic einen funktionierenden Exploit beschrieben, der nicht öffentlich ist |
| Patch verfügbar | Teilweise. Kernel 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3 enthalten den Fix. Debian, Oracle Linux (UEK) und Amazon Linux 2023 haben gepatcht. Ubuntu und Red Hat noch nicht |
Wie kann die Schwachstelle ausgenutzt werden?
Beim Abschluss eines Verbindungsaufbaus übergibt der Kernel die IP-Optionen der wartenden Anfrage an den neuen Socket, ohne sie zu kopieren. Wird dieser Socket zerstört, während ein anderer Prozessorkern die Optionen noch verwendet, liest der Kernel bereits freigegebenen Speicher. Laut The Hacker News meldete Xinyang Ge von Anthropic den Fehler. Anthropic schreibt, sein KI-Modell Claude habe einen Exploit erstellt, der in zwei Phasen zunächst die Kerneladressen (KASLR) umgeht und anschließend einen Befehl als Root ausführt, im Test nach etwa 48 Minuten plus 5 Minuten. Ziel war ein Server mit einem MPTCP-Listener. Ob das Deaktivieren von MPTCP hilft, ist nicht bestätigt, denn die CVE-Beschreibung und der Kernel-Fix erwähnen MPTCP nicht.
Was können die Folgen sein?
Nahezu jeder Linux-Server mit IPv4 fällt unter die betroffenen Versionsreihen. Red Hat erwartet vor allem einen Kernel-Absturz, Speicherkorruption und damit Root-Rechte sind theoretisch jedoch möglich. Stand 29. Oktober sind Ubuntu 22.04 bis einschließlich 26.10 in Bearbeitung, für Ubuntu 16.04, 18.04 und 20.04 gibt es keinen Fix. Bei RHEL 8, 9 und 10 sowie OpenShift 4 ist der Fix zurückgestellt. RHEL 7 ist nicht betroffen. Red Hat nennt keine Abhilfemaßnahme, die den eigenen Anforderungen genügt.
Was sollten IT-Administratoren jetzt tun?
Installieren Sie, wo möglich, den korrigierten Kernel und starten Sie das System neu. Erstellen Sie eine Liste der Server mit Ubuntu, RHEL und Amazon Linux 2, denn dort gibt es noch keinen Patch, und verfolgen Sie die CVE-Seiten von Ubuntu und Red Hat. Blockieren Sie bis dahin, wo möglich, eingehenden Datenverkehr aus nicht vertrauenswürdigen Netzwerken zu nicht öffentlichen Diensten und setzen Sie Server mit MPTCP ganz oben auf die Liste.
GitLab-Lücke mit CVSS 10,0: Jetzt aktiv ausgenutzt und in den CISA-Katalog aufgenommen
| Schwachstelle | Integer Overflow in der Regex-Engine Onigmo (Ruby) in GitLab Community und Enterprise Edition. Ein manipulierter regulärer Ausdruck in einer CI/CD-Konfiguration ermöglicht einem Angreifer ohne Zugangsdaten die Codeausführung auf dem GitLab-Server |
| CVE-Nummer | CVE-2026-97229 |
| CVSS-Score | 10,0 (kritisch) |
| Aktiv ausgenutzt | Ja. CISA nahm die Lücke am 29. Oktober 2026 in den KEV-Katalog auf. Alpine Linux registrierte am 20. und 21. Oktober Angriffsversuche auf seinen eigenen GitLab-Server |
| Patch verfügbar | Ja, GitLab-Patch vom 12. Oktober und Patch-Release 19.4.2. Bei einer eigenen Ruby-Installation ist zusätzlich Ruby 3.3.13, 3.4.12 oder 4.0.9 (oder neuer) erforderlich |
Im Patchwork vom Montag, 26. Oktober ging es um eine andere GitLab-Lücke mit CVSS 10,0 in derselben Regex-Engine. Neu ist heute, dass die frühere Lücke vom 12. Oktober nun in freier Wildbahn ausgenutzt wird und dass das GitLab-Update allein nicht immer ausreicht.
Wie wurde die Lücke ausgenutzt?
Laut dem Incident-Bericht von Alpine Linux installierte das Projekt am 13. Oktober versehentlich GitLab 19.3.4 statt 19.3.5, das den Fix enthielt. Am 20. und 21. Oktober schickte ein neu registriertes Konto manipulierte CI-Konfigurationen an den Server. Die GitLab-Worker-Prozesse stürzten achtmal ab, in vier Fällen kam der Angreifer einen Schritt weiter, doch der nächste Schritt scheiterte. Der Angreifer lud außerdem das GitLab-Container-Image herunter, vermutlich um den Exploit auf den exakten Build abzustimmen. Alpine fand keine Belege für eine Codeausführung, kann diese aber nicht ausschließen und hat den Server daher neu aufgesetzt, mit neuen Passwörtern und neuen geheimen Schlüsseln. Ein erfolgreicher Angriff hinterlässt laut Alpine weder einen Absturz noch Spuren in den Weblogs. Das niederländische Portal Security.nl beschreibt den Vorfall ebenfalls.
Was können die Folgen sein?
Mit einem erfolgreichen Angriff gelangt ein Angreifer an Passwort-Hashes, 2FA-Secrets, CI/CD-Variablen, Runner-Tokens, persönliche Zugriffstokens und private Repositorys. Für einen MSP oder ein Entwicklerteam sind gerade diese CI/CD-Secrets wertvoll, denn sie verschaffen Zugang zu Kundenumgebungen. Im KEV-Hinweis heißt es, dass auch andere Produkte denselben zugrunde liegenden Ruby-Fehler aufweisen können.
Was sollten IT-Administratoren jetzt tun?
Prüfen Sie bei selbst gehostetem GitLab sowohl die GitLab-Version als auch die Ruby-Version. Offizielle GitLab-Pakete und -Images enthalten den Ruby-Fix bereits, bei einer selbst kompilierten Installation oder einem Image mit eigener Ruby-Version ist er jedoch erforderlich, wie in der Ruby-Ankündigung beschrieben. Ist der Server von außen erreichbar und lief er in den Tagen nach dem 12. Oktober noch auf einer verwundbaren Version, behandeln Sie ihn als möglicherweise kompromittiert: Ersetzen Sie Tokens, Secrets und Passwörter und suchen Sie in den Logs nach Worker-Abstürzen und neuen Konten.
Dieser Artikel ist ursprünglich auf Niederländisch bei MSP Business erschienen. Zum Originalartikel →
