Veröffentlicht am 07.07.2026
Wenn Sie sich auf ModSecurity als Schutzschild für Ihre Website verlassen, sollten Sie in den nächsten Tagen genau hinschauen: Eine neu veröffentlichte Schwachstelle im weltweit meistgenutzten Open-Source-Web-Application-Firewall (WAF) ermöglicht es Angreifern, genau diesen Schutz zu umgehen – und zwar unbemerkt. Die Firewall meldet keinen Fehler, die Logs bleiben unauffällig, und trotzdem erreicht ein schädlicher Payload das Backend. Betroffen sind Standardinstallationen in ihrer Werkskonfiguration.
Die als CVE-2026-52747 geführte Lücke wurde mit einem CVSS-Wert von 8.6 (High) bewertet und am 29. Juni 2026 vom OWASP ModSecurity-Team veröffentlicht. Eine zweite, weniger kritische Schwachstelle (CVE-2026-52761, CVSS 5.8) betrifft ausschließlich ältere 32-Bit-Systeme. Beide Probleme sind mit ModSecurity 3.0.16 behoben.
ModSecurity ist eine sogenannte Web Application Firewall – eine Sicherheitsschicht, die eingehende Anfragen an Ihre Website prüft und schädliche Muster (etwa Angriffsversuche wie SQL-Injection oder Cross-Site-Scripting) blockiert, bevor sie Ihre eigentliche Anwendung erreichen. Die Firewall sitzt sozusagen als Türsteher vor Ihrer Website.
Genau dieser Türsteher lässt sich mit einem simplen Trick austricksen. Das Problem liegt im sogenannten Multipart-Parser – dem Bauteil, das Formulardaten auseinandernimmt, wie sie beim Absenden eines Kontaktformulars oder eines Datei-Uploads übertragen werden (technisch: multipart/form-data).
Der Parser entfernt eingebettete Zeilenumbrüche aus Formularfeldern, bevor er die Werte an die Regelprüfung übergibt. Ein Feldwert wie A[Zeilenumbruch]B wird von ModSecurity also nur als AB gesehen und geprüft. Das dahinterliegende System (das Backend) erhält jedoch den ursprünglichen Wert mit Zeilenumbruch. Es entsteht also eine gefährliche Diskrepanz: Die Firewall sieht etwas anderes als die Anwendung, die sie schützen soll.
Ervin Hegedus (airween), Maintainer des OWASP ModSecurity-Projekts, beschreibt das Problem so:
„Der Multipart/form-data-Parser in libmodsecurity entfernt stillschweigend eingebettete Zeilenumbrüche aus Nicht-Datei-Formularfeldern, bevor er sie an ARGS und ARGS_POST übergibt. Ein gültiges Multipart-Feld mit A\r\nB oder A\nB wird den ModSecurity-Regeln als AB präsentiert, und die eingebauten Strict-Validierungsvariablen bleiben unauffällig. […] Um vor Angriffen durch die beschriebenen Probleme sicher zu sein, sollten Sie Ihre WAF auf Version 3.0.16 aktualisieren.“ (Quelle: modsecurity.org)
Normalerweise verfügt ModSecurity über eingebaute Prüfmechanismen für Multipart-Anfragen (die Variablen MULTIPART_STRICT_ERROR, MULTIPART_LF_LINE und MULTIPART_CRLF_LF_LINES). Diese sollen genau solche Manipulationen erkennen. Das Fatale: Bei diesem Angriff bleiben sie auf null – sie schlagen also keinen Alarm, selbst wenn der Angriff erfolgreich ist.
Lucas Martin, Cybersecurity-Journalist bei CyberPress, ordnet das ein:
„Was das besonders gefährlich macht, ist, dass die eingebauten Strict-Multipart-Validierungsvariablen die Anomalie nicht kennzeichnen und selbst dann bei null bleiben, wenn der Exploit gelingt. Da die empfohlene Standardkonfiguration SecRequestBodyAccess On aktiviert und multipart/form-data-Inhalte automatisch durch diesen verwundbaren Parser leitet, sind die meisten Standardinstallationen betroffen.“ (Quelle: cyberpress.org)
Undercode News bringt den Kern des Problems auf den Punkt:
„Obwohl keine der beiden Schwachstellen direkte Remote Code Execution ermöglicht, untergraben beide eine der grundlegendsten Annahmen moderner WAF-Technologie: dass die Firewall genau dieselbe Anfrage sieht wie die geschützte Anwendung. Sobald diese Annahme bricht, erhalten Angreifer die Möglichkeit, schädliche Payloads unentdeckt durchzuschmuggeln.“ (Quelle: undercodenews.com)
Im Code (Datei src/request_body_processor/multipart.cc) werden beim Zusammensetzen der Formulardaten zwei aufeinanderfolgende Befehle (d.assign()) verwendet, wobei der zweite den Inhalt des ersten überschreibt, statt ihn anzuhängen. Dabei gehen die Bytes mit den Zeilenumbrüchen verloren. Der Fix in Version 3.0.16 ersetzt den zweiten Befehl durch d.append() – so wird angehängt statt überschrieben.
Wichtig zu wissen: Datei-Upload-Felder sind nicht betroffen. Es geht ausschließlich um normale Textformularfelder.
Die zweite Schwachstelle betrifft die Transformation t:utf8toUnicode und tritt ausschließlich auf i386-Architekturen (32-Bit-Systeme) auf. Durch einen Programmierfehler (die falsche Messung einer Puffergröße) wird die Ausgabe auf 4 statt 8 Bytes begrenzt, was ebenfalls zu Regelumgehungen führen kann. Auf modernen 64-Bit-Systemen tritt dieser Fehler nicht auf. Für die allermeisten aktuellen Hosting-Umgebungen ist diese Lücke daher irrelevant.
Betroffen sind alle Installationen von OWASP ModSecurity v3 (libmodsecurity3) in Version 3.0.15 und früher. Die Firewall kommt zum Einsatz bei:
Besonders relevant für kleine und mittlere Unternehmen: ModSecurity ist standardmäßig in vielen Hosting-Panels wie cPanel und Plesk integriert. Wenn Sie Managed Hosting nutzen, betreiben Sie ModSecurity möglicherweise, ohne es zu wissen. Do Son von SecurityOnline.info fasst die Tragweite zusammen:
„ModSecurity schützt unzählige Web-Anwendungen auf Apache, Nginx und IIS. Es zählt zu den meistgenutzten WAF-Engines überhaupt. […] Die höher bewertete Lücke betrifft das standardmäßige, empfohlene Setup. Folglich könnten viele Deployments die falschen Anfragedaten inspizieren.“ (Quelle: securityonline.info)
Wichtige Einordnung: Eine aktive Ausnutzung in der freien Wildbahn ist bislang nicht bestätigt, und öffentliche Proof-of-Concept-Exploits sind aktuell nicht bekannt. Das Risikofenster besteht jedoch so lange, wie ungepatchte Versionen im Einsatz sind – und die Lücke ist ohne Authentifizierung und mit geringem Aufwand ausnutzbar. Handeln Sie also zeitnah.
dpkg -l | grep modsecurity oder apt show libmodsecurity3 aus. Ist die Version kleiner als 3.0.16, sind Sie betroffen.rpm -qa | grep modsecurity aus. Versionen unter 3.0.16 sind verwundbar.grep -i modsecurity /var/log/apache2/error.log | head -5 oder nginx -V 2>&1 | grep ModSecurity.strings /usr/lib/x86_64-linux-gnu/libmodsecurity.so.3 | grep -i "version\|3\.0".grep SecRequestBodyAccess /etc/modsecurity/modsecurity.conf. Steht der Wert auf On (Standard), ist die Schwachstelle aktiv ausnutzbar.uname -m oder arch. Lautet die Ausgabe i386 oder i686, sind Sie auch von der zweiten Lücke betroffen.apt update && apt upgrade libmodsecurity3 bzw. yum update mod_security) oder kompilieren Sie die neue Version aus dem Quellcode. Download: github.com/owasp-modsecurity/ModSecurity/releases/tag/v3.0.16systemctl restart apache2 bzw. systemctl restart nginx, damit die aktualisierte Bibliothek geladen wird.dpkg -l | grep modsecurity oder strings /usr/lib/x86_64-linux-gnu/libmodsecurity.so.3 | grep 3.0.16 prüfen.t:utf8toUnicode-Transformation nutzen.grep MULTIPART /var/log/modsec_audit.log und grep ARGS_POST /var/log/modsec_audit.log.Hinweis für Nutzer des Legacy-Zweigs: ModSecurity 2.9.14 (v2) wurde am 2. Juli 2026 veröffentlicht, enthält jedoch keinen Backport der CVE-2026-52747-Fixes. Wer auf dem alten v2-Zweig unterwegs ist, sollte einen Umstieg auf v3.0.16 planen.
Auch wenn CVE-2026-52747 selbst keine direkte Datenpanne verursacht, ist die datenschutzrechtliche Relevanz erheblich. Denn die Lücke öffnet die Tür für Angriffe wie SQL-Injection, XSS oder CRLF-Injection, die das Backend erreichen können. Werden dabei personenbezogene Daten kompromittiert, entsteht eine meldepflichtige Datenschutzverletzung nach Art. 33 DSGVO: Die zuständige Aufsichtsbehörde muss unverzüglich, möglichst binnen 72 Stunden nach Bekanntwerden, informiert werden. Bei hohem Risiko für Betroffene ist zusätzlich eine Benachrichtigung nach Art. 34 DSGVO erforderlich.
Entscheidend: Bereits unzureichende technische Schutzmaßnahmen können als Verstoß gegen Art. 32 DSGVO gewertet werden – auch ohne nachgewiesene Ausnutzung. Bußgelder reichen bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes (bei Art.-32-Verstößen) bzw. bis zu 20 Mio. Euro oder 4 % bei schwerwiegenderen Verstößen. Zur Einordnung: In Deutschland verhängte der BfDI im Juni 2025 ein Bußgeld von rund 45 Mio. Euro gegen Vodafone wegen Sicherheitsmängeln.
Das bedeutet konkret: Das Update auf ModSecurity 3.0.16 ist als technische und organisatorische Maßnahme (TOM) nach Art. 32 DSGVO einzustufen – und sollte nicht nur umgesetzt, sondern auch dokumentiert werden.
Die Zahlen unterstreichen den Ernst der Lage. Laut dem DLA Piper GDPR Fines and Data Breach Survey (Januar 2026) stiegen die Datenpannenmeldungen in Europa 2025 um 22 % auf durchschnittlich 443 Meldungen pro Tag – erstmals seit 2018 über 400 täglich. Europäische Aufsichtsbehörden verhängten 2025 Bußgelder von insgesamt rund 1,2 Milliarden Euro.
Ross McKean von DLA Piper kommentiert die Entwicklung:
„Am deutlichsten wird in diesem Jahresbericht die Bestätigung, dass die Cybersicherheits-Bedrohungslage ein beispielloses Niveau erreicht hat. In einem Jahr, in dem geopolitische Spannungen und mehrere hochkarätige Cyberangriffe die globalen Schlagzeilen dominierten, zeigt der 22-prozentige Anstieg der Datenpannenmeldungen die ernsten und unmittelbaren Konsequenzen dieser unsicheren Zeiten für Organisationen.“ (Quelle: DLA Piper)
Da laut OWASP über 70 % aller Cyberangriffe auf der Ebene der Web-Anwendung erfolgen, ist eine funktionierende WAF eine der wichtigsten Verteidigungslinien. Umso gravierender, wenn genau diese Linie leise umgangen werden kann.
CVE-2026-52747 ist keine hypothetische Schwachstelle: Sie betrifft die Standardkonfiguration der weltweit meistgenutzten Open-Source-WAF und ist ohne Authentifizierung sowie mit geringem Aufwand ausnutzbar. Dass sie keine sofortige Übernahme des Servers ermöglicht und bislang keine aktive Ausnutzung bekannt ist, sind die guten Nachrichten. Die schlechte: Ein Angriff hinterlässt keine Spuren in den üblichen WAF-Prüfvariablen.
Unsere klare Empfehlung: Prüfen Sie umgehend, ob Sie eine ModSecurity-Version unter 3.0.16 einsetzen, und aktualisieren Sie zeitnah – oder lassen Sie Ihren Hosting-Anbieter das Update bestätigen. Wer ModSecurity als tragende Sicherheitsschicht nutzt, sollte diese Aufgabe nicht auf die lange Bank schieben. Und wie immer gilt: Eine WAF ist ein wichtiger Baustein, aber niemals die einzige Verteidigungslinie.