Kritische Sicherheitslücke in Drupal: Handlungsbedarf für Unternehmen mit PostgreSQL-Backend

Veröffentlicht: 26. Mai 2026 | Lesedauer: ca. 7 Minuten | Kategorie: Schwachstellenmanagement, NIS2-Compliance

Einleitung: Aktive Angriffe auf Drupal-Installationen – Ihr Unternehmen betroffen?

Seit dem 26. Mai 2026 warnen Sicherheitsforscher und das Bundesamt für Sicherheit in der Informationstechnik (BSI) vor aktiv ausgenutzten Angriffen auf Websites, die mit dem Content-Management-System Drupal in Kombination mit einer PostgreSQL-Datenbank betrieben werden. Angreifer haben eine kritische Schadcode-Lücke identifiziert und nutzen sie gezielt aus – mit potenziell schwerwiegenden Folgen für betroffene Organisationen.

Für IT-Verantwortliche und Geschäftsführer in deutschen Unternehmen ist diese Meldung aus zwei Gründen besonders relevant: Erstens betreiben zahlreiche mittelständische und große Unternehmen, Behörden sowie öffentliche Einrichtungen Drupal-basierte Webauftritte, Intranet-Lösungen oder Kundenportale. Zweitens stellt ein erfolgreicher Angriff auf kritische Systeme unter der seit Oktober 2024 verbindlich geltenden NIS2-Richtlinie einen meldepflichtigen Sicherheitsvorfall dar – mit entsprechenden Konsequenzen bei Versäumnissen.

Kurz gesagt: Wer Drupal mit PostgreSQL betreibt und noch nicht gepatcht hat, handelt fahrlässig – technisch wie rechtlich.

Technischer Hintergrund: Was steckt hinter der Schwachstelle?

Die Lücke im Überblick

Die aktuelle Schwachstelle betrifft die Kombination aus Drupal CMS und dem Datenbankbackend PostgreSQL. Während Drupal-Installationen mit MySQL oder MariaDB nach aktuellem Erkenntnisstand nicht betroffen sind, ermöglicht die Lücke bei PostgreSQL-Nutzern die Remote Code Execution (RCE) – also die Ausführung von beliebigem Schadcode aus der Ferne, ohne dass ein Angreifer physischen Zugang zum System benötigt.

Was bedeutet Remote Code Execution in der Praxis?
Ein Angreifer kann über das Internet Befehle auf dem betroffenen Server ausführen – ohne Authentifizierung. Das ermöglicht das Auslesen sensibler Daten, die Installation von Malware, Ransomware oder Backdoors sowie die vollständige Übernahme des Systems.

Technischer Ablauf (vereinfacht)

1. Eingabe präparierter Anfragen: Der Angreifer sendet speziell formulierte HTTP-Anfragen an die Drupal-Installation.
2. Unsichere Datenbankabfrage: Durch eine fehlerhafte Verarbeitung bestimmter Parameter in Verbindung mit PostgreSQL-spezifischen Funktionen wird ungeprüfter Code in die Datenbankabfrage eingeschleust (SQL-Injection-Variante mit RCE-Potenzial).
3. Schadcode-Ausführung: PostgreSQL-Funktionen wie COPY TO/FROM PROGRAM ermöglichen unter bestimmten Konfigurationen die direkte Ausführung von Betriebssystembefehlen.
4. Systemkompromittierung: Der Angreifer erlangt Kontrolle über den Webserver – mit den Rechten des Datenbanknutzers.

Betroffene Versionen

Zum Zeitpunkt der Veröffentlichung sind Drupal-Versionen betroffen, die nicht auf den aktuellen Sicherheitspatch aktualisiert wurden. Drupal hat entsprechende Sicherheitsupdates bereitgestellt. IT-Teams sollten die offizielle Drupal Security Advisory-Seite (drupal.org/security) als primäre Quelle nutzen.

Auswirkungen für deutsche Unternehmen und NIS2-Relevanz

Wer ist betroffen?

NIS2-Richtlinie: Ihre Pflichten im Ernstfall

Die EU-Richtlinie NIS2 (umgesetzt in Deutschland durch das BSIG – BSI-Gesetz, Novelle 2024) verpflichtet sogenannte „wesentliche" und „wichtige" Einrichtungen zu einem strukturierten Umgang mit Sicherheitsvorfällen. Konkret bedeutet das:

Meldepflichten (§ 30 BSIG n.F.):

• Innerhalb von 24 Stunden: Erstmeldung an das BSI bei erheblichen Sicherheitsvorfällen (Frühwarnung)
• Innerhalb von 72 Stunden: Detaillierter Zwischenbericht
• Innerhalb von 1 Monat: Abschlussbericht mit Ursachenanalyse und Gegenmaßnahmen

Ein erfolgreicher RCE-Angriff auf produktive Systeme erfüllt in aller Regel das Kriterium eines erheblichen Sicherheitsvorfalls – insbesondere wenn personenbezogene Daten betroffen sind (parallele Meldepflicht nach DSGVO Art. 33 gegenüber der zuständigen Datenschutzbehörde, ebenfalls innerhalb von 72 Stunden).

Technische und organisatorische Maßnahmen (§ 30 Abs. 2 BSIG):

NIS2 verlangt ausdrücklich ein aktives Schwachstellenmanagement sowie die zeitnahe Anwendung von Sicherheitsupdates. Wer bekannte, aktiv ausgenutzte Schwachstellen nicht patcht, riskiert nicht nur einen Sicherheitsvorfall, sondern auch Bußgelder von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes (wesentliche Einrichtungen).

Praxis-Hinweis: Das BSI stellt über sein CERT-Bund tagesaktuelle Warnmeldungen bereit. Abonnieren Sie den BSI-Newsletter oder nutzen Sie den RSS-Feed unter bsi.bund.de/cert, um zukünftig schneller informiert zu sein.

Praktische Schutzmaßnahmen: 7 konkrete Schritte für IT-Teams

1. 🔍 Sofort-Inventur: Welche Drupal-Installationen nutzen PostgreSQL?

Bevor Sie patchen können, müssen Sie wissen, was Sie haben. Erstellen Sie unmittelbar ein vollständiges Inventar aller Drupal-Instanzen in Ihrer Organisation – intern, extern, Staging-Systeme eingeschlossen. Prüfen Sie für jede Installation den verwendeten Datenbanktyp.

# Datenbanktyp in Drupal-Konfiguration prüfen (settings.php):
grep -i "driver" /var/www/html/sites/default/settings.php

2. 🚨 Sofortiger Patch – keine Ausnahmen

Spielen Sie das von Drupal bereitgestellte Sicherheitsupdate unverzüglich auf allen betroffenen Systemen ein. Nutzen Sie den offiziellen Drupal-Updatepfad:

# Mit Drush (empfohlenes CLI-Tool für Drupal):
drush pm:update drupal
drush cache:rebuild

Testen Sie den Patch zunächst in einer Staging-Umgebung, aber setzen Sie die Produktivumgebung bei aktiver Ausnutzung priorisiert um – der Risikobeschleuniger „aktive Angriffe" wiegt schwerer als mögliche Kompatibilitätsprobleme.

3. 🛡️ Web Application Firewall (WAF) als temporäre Schutzschicht

Sofern ein sofortiger Patch nicht möglich ist (z. B. aufgrund von Change-Management-Prozessen), aktivieren Sie umgehend eine WAF-Regel, die die bekannten Angriffsmuster blockiert. Viele CDN-Anbieter (Cloudflare, Akamai, AWS WAF) stellen kurzfristig virtuelle Patches bereit. Dies ist jedoch kein dauerhafter Ersatz für das eigentliche Update.

4. 🔒 PostgreSQL-Härtung: Berechtigungen minimieren

Überprüfen Sie die Berechtigungen des Drupal-Datenbanknutzers in PostgreSQL. Der Datenbankbenutzer sollte niemals Superuser-Rechte oder die Berechtigung zur Programmausführung (EXECUTE) auf Systemfunktionen besitzen:

-- Gefährliche Rechte entziehen:
REVOKE EXECUTE ON FUNCTION pg_read_file(text) FROM drupal_user;
-- Nur notwendige Rechte gewähren (Prinzip der minimalen Rechtevergabe)

5. 📋 Logging und Monitoring aktivieren/erweitern

Aktivieren Sie erweiterte Zugriffsprotokolle für Ihren Webserver und die Drupal-Applikation. Suchen Sie in bestehenden Logs nach Anzeichen einer Kompromittierung – ungewöhnliche POST-Anfragen, Datenbankfehler oder auffällige Zugriffe auf /admin-Pfade können Hinweise sein. SIEM-Systeme sollten entsprechende Alarmierungsregeln erhalten.

6. 📣 Vorfallsmanagement vorbereiten – Meldewege dokumentieren

Stellen Sie sicher, dass Ihr Incident-Response-Prozess aktiviert und dokumentiert ist. Halten Sie die BSI-Meldestelle (cert@bsi.bund.de / +49 228 9582-222) und Ihre zuständige Datenschutzbehörde griffbereit. Im Ernstfall zählt jede Stunde – insbesondere wegen der 24-Stunden-Frist nach NIS2.

7. 🔄 Regelmäßiges Patch-Management als Daueraufgabe

Dieser Vorfall verdeutlicht, dass reaktives Patchen zu langsam ist. Implementieren Sie einen strukturierten Patch-Management-Prozess, der:
- Kritische Patches innerhalb von 24–48 Stunden einspielt
- Regelmäßige Schwachstellen-Scans (z. B. mit OpenVAS, Tenable oder Qualys) durchführt
- Einen definierten Eskalationsprozess für Zero-Day-Schwachstellen vorsieht

Fazit: Patchen ist Pflicht – organisatorisch wie rechtlich

Die aktuelle Drupal-Schwachstelle ist ein Paradebeispiel dafür, warum proaktives Schwachstellenmanagement keine Kür, sondern Pflicht ist – sowohl aus technischer Sicht als auch vor dem Hintergrund der NIS2-Anforderungen. Aktiv ausgenutzte RCE-Lücken lassen keine Zeit für langwierige Genehmigungsprozesse. Wer jetzt nicht handelt, riskiert nicht nur die Kompromittierung unternehmenskritischer Systeme, sondern auch empfindliche Bußgelder und Reputationsschäden.

Das Wichtigste in Kürze:
- ✅ Alle Drupal + PostgreSQL-Instanzen sofort identifizieren
- ✅ Sicherheitspatch umgehend einspielen
- ✅ WAF als temporären Schutz aktivieren
- ✅ Logs auf Kompromittierungshinweise prüfen
- ✅ Meldewege (BSI, Datenschutzbehörde) bereithalten

Call-to-Action: NIS2-Compliance strukturiert angehen

Vorfälle wie dieser zeigen, wie eng technisches Schwachstellenmanagement und regulatorische Compliance miteinander verknüpft sind. Die manuelle Koordination von Patch-Prozessen, Dokumentationspflichten, Meldefristen und Risikoanalysen ist in der Praxis kaum noch ohne digitale Unterstützung zu leisten.

Tipp für IT-Verantwortliche: Spezialisierte NIS2-Compliance-Software hilft Ihnen dabei, Schwachstellen zentral zu erfassen, Meldepflichten fristgerecht zu verwalten, Nachweise für Audits automatisch zu generieren und Ihren Reifegrad gegenüber dem BSI-Grundschutz transparent zu dokumentieren. Informieren Sie sich über entsprechende Lösungen – der nächste Vorfall kommt bestimmt, und dann entscheidet die Reaktionsgeschwindigkeit.

Quellen: Heise Security (26.05.2026), BSI-CERT, Drupal Security Advisories (drupal.org/security), BSIG (Novelle 2024), ENISA Threat Landscape 2025, DSGVO Art. 33