ModSecurity 3.0.17 und 2.9.15 beheben mehrere schwerwiegende WAF-Bypässe

Das ModSecurity Sicherheitsupdate auf libmodsecurity3 3.0.17 und mod_security2 2.9.15 behebt acht Sicherheitsprobleme in der weit verbreiteten Web Application Firewall. Mehrere Schwachstellen ermöglichen eine Umgehung von Sicherheitsregeln. Ein weiteres Problem in libmodsecurity3 kann unter bestimmten Konfigurationen Speicherfehler verursachen und möglicherweise den Ausführungsfluss eines Prozesses beeinflussen.

ModSecurity wird auf Hosting-Servern häufig als zusätzliche Sicherheitsschicht vor WordPress, Joomla, Magento, Adobe Commerce und anderen Webanwendungen eingesetzt. In Kombination mit Regelwerken wie dem OWASP Core Rule Set werden HTTP-Requests und Responses analysiert, bevor sie die eigentliche Anwendung erreichen beziehungsweise an den Besucher ausgeliefert werden.

Die neuen Schwachstellen bedeuten deshalb nicht zwangsläufig, dass ModSecurity selbst unmittelbar zur Übernahme einer Website führt. Mehrere der Probleme schwächen vielmehr die Schutzwirkung der Web Application Firewall. Angriffe, die normalerweise erkannt oder blockiert werden sollten, können dadurch unter bestimmten Bedingungen die dahinterliegende Webanwendung erreichen.

Welche Probleme behebt das ModSecurity Sicherheitsupdate?

Das ModSecurity Project hat insgesamt acht Security Advisories veröffentlicht. Nicht alle Probleme betreffen exakt dieselben Versionen und Konfigurationen.

Für Administratoren gelten praktisch folgende Upstream-Versionen als relevant:

• libmodsecurity3 3.0.16 und älter – von mehreren Schwachstellen betroffen
• libmodsecurity3 3.0.17 – Sicherheitskorrekturen enthalten
• mod_security2 2.9.14 und älter – von sechs der acht Probleme betroffen
• mod_security2 2.9.15 – Sicherheitskorrekturen enthalten

CVE-2026-73857 hat einen engeren betroffenen Versionsbereich und betrifft speziell libmodsecurity3 3.0.15 und 3.0.16.

Acht Sicherheitsprobleme in ModSecurity

Die veröffentlichten Advisories betreffen unterschiedliche Bereiche der Request- und Response-Verarbeitung, Parser sowie Transformationen, die ModSecurity vor der eigentlichen Prüfung durch Sicherheitsregeln verwendet.

Zu den wichtigsten Problemen gehören:

• CVE-2026-73856 – CVSS 8.6 High: Umgehung der Response-Body-Inspektion durch nicht kanonische Groß- und Kleinschreibung des Content-Type-Headers;
• CVE-2026-73857 – CVSS 7.5 High: Memory-Safety-Problem im XML-Request-Body-Parser mit möglichen Auswirkungen von Denial of Service und Memory Disclosure bis zur Beeinflussung des Execution Flow;
• GHSA-5pww-8rfg-9crf – CVSS 8.6 High: Umgehung von Dateinamenkontrollen bei Multipart-Uploads über den RFC-2231-Parameter filename*;
• CVE-2026-61812 – CVSS 5.3: unvollständiges HTML-Entity-Decoding, wodurch WAF-Regeln umgangen werden können;
• CVE-2026-61813 – CVSS 3.7: unzureichende TLS-Hostname-Prüfung bei bestimmten HTTPS-Downloads;
• fehlerhafte Error-Behandlung beim Operator @rxGlobal;
• ein Bypass in der Transformation t:removeComments;
• fehlerhafte Verarbeitung von URL-safe Base64 durch t:base64DecodeExt.

CVE-2026-73856 umgeht die Response-Body-Inspektion

CVE-2026-73856 hat einen CVSS-Score von 8.6 und betrifft libmodsecurity3 bis einschließlich Version 3.0.16.

Das Problem befindet sich in der Entscheidung, ob ModSecurity den Inhalt einer HTTP-Response untersuchen muss.

ModSecurity verglich den Content-Type einer Response case-sensitive mit den MIME-Typen, die über SecResponseBodyMimeType konfiguriert waren.

HTTP-Medientypen sind jedoch nicht von Groß- und Kleinschreibung abhängig. Ein Backend konnte deshalb beispielsweise:

Text/Html

anstelle von:

text/html

zurückgeben.

In einer betroffenen Konfiguration konnte dies dazu führen, dass der Response Body nicht von ModSecurity untersucht wurde. Regeln, die auf RESPONSE_BODY angewiesen sind, wurden dann nicht ausgeführt.

Das ModSecurity Project nennt als mögliche Folgen unter anderem die Offenlegung vollständiger SQL-Fehlermeldungen, Stack Traces oder Debug-Informationen, die eine WAF-Regel eigentlich erkennen oder blockieren sollte.

CVE-2026-73857: Memory-Safety-Problem im XML-Parser

CVE-2026-73857 betrifft libmodsecurity3 3.0.15 und 3.0.16 und hat einen CVSS-Score von 7.5.

Ein nicht authentifizierter Angreifer kann mit einem speziell präparierten HTTP-Request einen nicht initialisierten Pointer im XML-Request-Body-Parser dereferenzieren lassen.

Das ModSecurity Project beschreibt mögliche Auswirkungen von:

• Denial of Service;
• Memory Disclosure;
• Speicherbeschädigung;
• Beeinflussung des Execution Flow.

Unter bestimmten Bedingungen könnte eine Beeinflussung des Ausführungsflusses möglicherweise weiter in Richtung Code Execution ausgebaut werden.

Vservs bezeichnet CVE-2026-73857 jedoch bewusst nicht als einfache oder garantierte unauthenticated Remote-Code-Execution-Schwachstelle. Das Upstream-Advisory bestätigt keine zuverlässig reproduzierbare direkte RCE für jede betroffene Konfiguration.

Bestimmte Konfiguration für CVE-2026-73857 erforderlich

Der verwundbare XML-Codepfad wird nur erreicht, wenn eine der folgenden Einstellungen aktiv ist:

SecParseXmlIntoArgs On

oder:

SecParseXmlIntoArgs OnlyArgs

Diese Funktion ist standardmäßig deaktiviert.

Server, auf denen SecParseXmlIntoArgs nicht aktiviert ist, sind deshalb nicht über diesen spezifischen XML-Parser-Angriffsweg verwundbar.

Sie können jedoch weiterhin von anderen Problemen betroffen sein, die mit demselben ModSecurity Sicherheitsupdate behoben wurden.

Datei-Upload-Regeln können über filename* umgangen werden

Ein weiteres High-Severity-Problem wird als GHSA-5pww-8rfg-9crf geführt und hat ebenfalls einen CVSS-Score von 8.6.

Die Schwachstelle betrifft Multipart-Datei-Uploads.

Ein HTTP-Multipart-Request kann einen Dateinamen über den klassischen Parameter filename angeben. RFC 2231 definiert zusätzlich den erweiterten Parameter filename*.

Verwundbare ModSecurity-Versionen verarbeiteten diesen erweiterten Parameter nicht korrekt, während verschiedene Backend-Frameworks ihn standardkonform interpretieren.

Ein Angreifer kann dadurch ModSecurity einen unauffälligen Dateinamen über filename präsentieren, während die dahinterliegende Anwendung einen anderen Wert aus filename* verarbeitet.

Regeln, die Upload-Dateinamen über Variablen wie MULTIPART_FILENAME oder FILES prüfen, können dadurch den falschen Wert untersuchen.

Bei Webanwendungen mit Datei-Uploads kann dies WAF-Regeln schwächen, die gefährliche Dateiendungen oder verdächtige Dateinamen blockieren sollen.

Transformationen können SQL-Injection-Regeln beeinflussen

Mehrere weitere Korrekturen betreffen Transformationen, die ModSecurity auf Eingaben anwendet, bevor diese gegen Sicherheitsregeln geprüft werden.

Ein Problem befindet sich beispielsweise in t:removeComments. Bestimmte Folgen direkt aufeinanderfolgender Kommentare wurden falsch normalisiert.

Dadurch konnte ModSecurity einen Payload anders interpretieren als die dahinterliegende Webanwendung.

Dies ist insbesondere für WAF-Regeln relevant, die verschleierte SQL-Injection-Payloads vor der eigentlichen Erkennung normalisieren.

Wenn Web Application Firewall und Anwendung dieselben Daten unterschiedlich interpretieren, kann ein Angreifer möglicherweise einen Payload konstruieren, der für die WAF unauffällig erscheint, von der Anwendung jedoch als gefährlicher Befehl verarbeitet wird.

URL-safe Base64 wird jetzt korrekt verarbeitet

Auch die Transformation t:base64DecodeExt enthielt einen Fehler.

Die URL-safe Base64-Zeichen - und _ wurden nicht korrekt dekodiert. Dadurch konnten Sicherheitsregeln, die den dekodierten Inhalt prüfen, einen anderen Wert sehen als die dahinterliegende Anwendung.

URL-safe Base64 wird unter anderem häufig in modernen APIs und JSON Web Tokens verwendet.

Ein Security-Rule-Set, das beispielsweise einen JWT-Bestandteil dekodiert, konnte dadurch bestimmte Payloads übersehen.

Die gepatchten Versionen korrigieren dieses Verhalten.

Werden die ModSecurity-Schwachstellen aktiv ausgenutzt?

Zum Zeitpunkt dieser Veröffentlichung hat Vservs keine zuverlässige Bestätigung aus primären Quellen gefunden, dass diese neu veröffentlichten ModSecurity-Schwachstellen derzeit in größerem Umfang aktiv in freier Wildbahn ausgenutzt werden.

Wir bezeichnen die Schwachstellen deshalb derzeit nicht als bestätigt aktiv ausgenutzt.

Mehrere Probleme ermöglichen jedoch ausdrücklich die Umgehung von Web-Application-Firewall-Kontrollen. Technische Details sind öffentlich verfügbar und korrigierte Upstream-Versionen wurden veröffentlicht.

Das ModSecurity Project empfiehlt für mehrere Advisories ausdrücklich ein sofortiges Upgrade.

Wichtig für Debian 12 und Debian 13

Administratoren, die ModSecurity über eine Linux-Distribution installieren, sollten nicht einfach die installierte Versionsnummer mit der Upstream-Version vergleichen.

Linux-Distributionen übernehmen Sicherheitskorrekturen häufig als Backports, ohne auf dieselbe Upstream-Versionsnummer zu wechseln.

Zum Zeitpunkt dieser Veröffentlichung führt der Debian Security Tracker die ModSecurity-Pakete für Debian 12 Bookworm und Debian 13 Trixie weiterhin als verwundbar für mehrere der neu veröffentlichten Probleme.

Für CVE-2026-73857 werden aktuell unter anderem folgende Pakete als verwundbar geführt:

• Debian 12 Bookworm: modsecurity 3.0.9-1+deb12u2
• Debian 13 Trixie: modsecurity 3.0.14-1+deb13u1

Auch die Debian-Pakete für das Multipart-filename*-Problem werden derzeit noch als verwundbar geführt.

Administratoren sollten deshalb den aktuellen Debian Security Tracker und die Paket-Repositories kontrollieren, bevor Änderungen vorgenommen werden.

Eine selbst kompilierte Upstream-Version über ein von Debian, einem Hosting-Control-Panel oder einem anderen Repository verwaltetes Paket zu installieren, ist nicht automatisch die richtige Lösung. Dadurch können Paketverwaltung, Webserver-Integration oder zukünftige Sicherheitsupdates beeinträchtigt werden.

Temporäre Mitigation für CVE-2026-73857

Ist libmodsecurity3 3.0.17 über den unterstützten Updatekanal noch nicht verfügbar und wird XML-to-ARGS nicht benötigt, kann SecParseXmlIntoArgs deaktiviert werden.

Dadurch wird der spezifische verwundbare Codepfad von CVE-2026-73857 nicht erreicht.

Diese Mitigation schützt jedoch nicht vor den anderen WAF-Bypässen, die mit derselben Security-Version behoben wurden.

Das Update auf ein gepatchtes ModSecurity-Paket bleibt deshalb die strukturelle Lösung.

Was sollten Serveradministratoren jetzt tun?

1. Prüfen, welche ModSecurity-Engine eingesetzt wird: libmodsecurity3 oder mod_security2.
2. Die installierte Paketversion kontrollieren.
3. Feststellen, ob ModSecurity vom Betriebssystem, Hosting-Control-Panel oder über eine eigene Installation verwaltet wird.
4. libmodsecurity3 3.0.17 beziehungsweise mod_security2 2.9.15 installieren, sobald eine korrigierte Version über den unterstützten Updatekanal verfügbar ist.
5. Prüfen, ob SecParseXmlIntoArgs aktiviert ist.
6. Nach dem Update den betreffenden Webserver beziehungsweise die WAF-Komponenten bei Bedarf reloaden oder neu starten.
7. Kontrollieren, ob ModSecurity und die verwendeten Rule Sets ohne Fehler geladen werden.
8. Wichtige Websites und Webanwendungen nach dem Update funktional testen.
9. Eigene ModSecurity-Regeln auf Kompatibilität mit dem korrigierten Parser- und Transformationsverhalten prüfen.

Logs auf mögliche WAF-Bypass-Versuche prüfen

Mehrere der Sicherheitsprobleme sind WAF-Bypässe. Eine erfolgreiche Umgehung kann deshalb gerade dazu führen, dass ein Angriff nicht als normaler ModSecurity-Block im Audit Log erscheint.

ModSecurity-Audit-Logs sollten deshalb zusammen mit Webserver- und Application-Logs ausgewertet werden.

Achten Sie insbesondere auf:

• Multipart-Datei-Uploads mit filename*;
• Requests mit ungewöhnlichen oder mehrfach aufeinanderfolgenden Inline-Kommentaren;
• kodierte Angriffspayloads;
• URL-safe Base64 in unerwarteten Request-Feldern;
• ungewöhnliche XML-Requests, wenn XML-to-ARGS aktiviert ist;
• unerwartete Worker-Abstürze oder Segmentation Faults;
• SQL-Injection-, XSS- oder File-Upload-Payloads, die von der Anwendung empfangen, aber nicht von ModSecurity blockiert wurden;
• unerwartete Upload-Dateien, die nach verdächtigen HTTP-Requests entstanden sind.

Das Auftreten eines solchen Musters beweist nicht automatisch eine erfolgreiche Ausnutzung. Auffälligkeiten sollten mit der betroffenen Anwendung, HTTP-Responsecodes, Quell-IP-Adressen und nachfolgenden Serveraktivitäten korreliert werden.

Eine Web Application Firewall ist eine zusätzliche Schutzschicht

Die Schwachstellen zeigen erneut, warum eine Web Application Firewall niemals die einzige Schutzmaßnahme einer Website oder eines Onlineshops sein sollte.

ModSecurity und Regelwerke wie das OWASP Core Rule Set bilden eine wichtige zusätzliche Sicherheitsschicht, ersetzen jedoch keine sichere und aktuelle Webanwendung.

WordPress Core, Plugins, Themes, Joomla-Erweiterungen, Magento- oder Adobe-Commerce-Komponenten und andere Webanwendungen müssen weiterhin mit ihren eigenen Sicherheitsupdates versorgt werden.

Server-Hardening, Least-Privilege-Berechtigungen, Monitoring und zuverlässige Backups bleiben ebenfalls notwendig.

Managed VPS bei Vservs

Eine sichere Hosting-Umgebung erfordert die kontinuierliche Pflege des Betriebssystems, Webservers, der Web Application Firewall und der gehosteten Anwendungen.