Veröffentlicht am 16.08.2026
Ein Redakteur bearbeitet einen Artikel, korrigiert einen internen Ansprechpartner, entfernt eine sensible Notiz – und geht davon aus, dass die alte Fassung nicht mehr zugänglich ist. Genau hier setzt eine neue Schwachstelle im beliebten Drupal-Modul Diff an: In bestimmten Versionen konnte eine Person, die eigentlich nur eine Entität ansehen durfte, unter Umständen frühere Revisionsstände über den Vergleich einsehen. Sichtbar wird dabei möglicherweise Inhalt, der längst nicht mehr für alle bestimmt war.
Das offizielle Drupal-Advisory SA-CONTRIB-2026-096 beschreibt die Lücke unter der Kennung CVE-2026-73478. Drupal stuft sie als moderately critical mit 13 von 25 Punkten ein – also im mittleren Schweregradbereich. Wichtig gleich zu Beginn: Es gibt bereits einen Fix. Die Patch-Versionen wurden am 11. August 2026 veröffentlicht, das Advisory selbst datiert auf den 12. August 2026. Betroffen ist ausdrücklich nicht Drupal Core, sondern das zusätzlich installierbare Contrib-Modul Diff.
Das Modul Diff stellt Unterschiede zwischen Revisionen (Versionsständen) von Inhalten dar. In den anfälligen Versionen prüfte die vom Modul bereitgestellte Diff-Route die Zugriffsrechte nicht ausreichend. Konkret beschreibt das Drupal Security Team das Problem so:
„The module doesn't sufficiently restrict access to non-node entity revision diffs.“ – Drupal Security Team, SA-CONTRIB-2026-096
Übersetzt: Das Modul schränkte den Zugriff auf Revisionsvergleiche von Nicht-Node-Entitäten nicht genug ein. Ein „Node“ ist in Drupal der klassische Inhaltstyp (etwa ein Artikel oder eine Seite). „Nicht-Node-Entitäten“ sind alle übrigen strukturierten Datenobjekte – zum Beispiel bestimmte Standard- oder selbst gebaute (Custom-)Entitäten, sofern diese revisionsfähig sind, also eine Versionshistorie führen.
Das Risiko liegt allein bei der Vertraulichkeit: Nicht öffentliche Inhalte aus früheren Revisionen konnten möglicherweise offengelegt werden. Die Integrität der Daten bleibt laut Advisory unberührt – es können also keine Daten verändert oder gelöscht werden, sondern lediglich eingesehen.
Der Vergleich der offiziellen Modul-Archive zeigt die Ursache klar: In den verwundbaren Ständen 2.0.0 und 2.1.0 verlangte die dynamisch erzeugte Diff-Route lediglich die normale View-Berechtigung der Entität – also das Recht, die Entität überhaupt anzusehen. In den gepatchten Versionen 2.0.1 und 2.1.1 wird stattdessen die strengere Berechtigung geprüft, alle Revisionen anzeigen zu dürfen.
Mit anderen Worten: Vorher genügte das schwächere Anzeigerecht, um über den Revisionsvergleich in die Historie zu schauen. Nach dem Patch reicht das nicht mehr. Bemerkenswert ist der historische Kontext: Erst die Version 2.1.0 (veröffentlicht am 10. Juni 2026) führte ausdrücklich die Unterstützung für alle Entitätstypen ein – also genau jene Erweiterung, in deren Zusammenhang die unzureichende Prüfung auffiel.
Betroffen sind laut Advisory folgende Versionsstände des Moduls Diff:
Eine wichtige Einordnung zur Reichweite: Die offizielle Drupal-Projektseite meldet 74.661 Websites, die Diff verwenden. Das ist jedoch eine reine Nutzungskennzahl – darin enthalten sind bereits gepatchte, nicht exponierte oder womöglich gar nicht mehr aktive Installationen. Es ist keine Zahl bestätigter verwundbarer oder kompromittierter Websites. Drupal veröffentlicht für CVE-2026-73478 weder eine Zahl betroffener Unternehmen noch offengelegter Datensätze oder bestätigter Vorfälle.
Ob die Lücke praktisch ausnutzbar ist, hängt an einer konkreten Voraussetzung. Das Drupal Security Team formuliert es so:
„This vulnerability is mitigated by the fact that an attacker must have a role with the permission to view the entity.“ – Drupal Security Team, SA-CONTRIB-2026-096
Ein Angreifer benötigt also eine Rolle, die die betroffene Entität ansehen darf. Zugleich bewertet das Advisory Authentifizierung als nicht erforderlich – ein Zugriff wäre damit auch über eine anonyme Rolle denkbar, sofern diese die Entität sehen darf. Das ist aber kein pauschaler, voraussetzungsloser Zugriff auf jede beliebige Website. Wo öffentliche oder breit vergebene Rollen keine relevanten Nicht-Node-Entitäten sehen können, ist das reale Risiko entsprechend geringer.
Drupal führt den Exploit-Status als theoretisch beziehungsweise White-Hat. Zum Zeitpunkt des Advisorys lag kein öffentlicher Exploit-Code vor. Auch eine gezielte Recherche ergab bis zum 15. August 2026 keine belastbaren Hinweise auf aktive Ausnutzung oder einen öffentlichen Proof-of-Concept. Diese Aussage ist zeitgebunden und beweist nicht, dass niemals ein Missbrauch stattgefunden hat.
Ein Hinweis: Eine feste, allgemeingültige URL-Struktur zum Testen gibt es nicht, weil sich der Diff-Pfad aus dem revisions-diff-Link-Template des jeweiligen Entitätstyps ergibt. Verlassen Sie sich daher nicht allein auf ein pauschales URL-Muster.
Ganz klar vorab: Eine Schwachstelle allein ist noch keine meldepflichtige Datenpanne. Entscheidend ist, ob tatsächlich personenbezogene Daten unbefugt offengelegt oder zugänglich wurden. Revisionsinhalte können durchaus personenbezogen sein – etwa Namen, Kontaktdaten, interne Freitextnotizen oder frühere Inhaltsstände mit identifizierenden Angaben. Ob das bei Ihrer Website der Fall ist, müssen Sie konkret feststellen.
Rechtlicher Rahmen: Art. 32 DSGVO verlangt ein risikoadäquates Sicherheitsniveau und nennt unbefugte Offenlegung und unbefugten Zugang ausdrücklich als Risiko. Die Bundesbeauftragte für den Datenschutz formuliert die Pflicht so:
„Verantwortliche und Auftragsverarbeiter im Sinne der DSGVO müssen geeignete technische und organisatorische Maßnahmen treffen, um einen Schutz etwa vor unbefugter Kenntnisnahme, unrechtmäßiger Verarbeitung oder dem unbeabsichtigten Verlust der Daten zu gewährleisten.“ – BfDI
Kommt es tatsächlich zu einer Verletzung, greift Art. 33 DSGVO: Meldung an die zuständige Aufsichtsbehörde unverzüglich und möglichst binnen 72 Stunden ab Kenntnis – es sei denn, die Verletzung führt voraussichtlich nicht zu einem Risiko. Jede Verletzung ist zu dokumentieren. Bei voraussichtlich hohem Risiko verlangt Art. 34 zusätzlich die unverzügliche Benachrichtigung der Betroffenen. Der Bußgeldrahmen nach Art. 83 ist einzelfallbezogen und berücksichtigt unter anderem Schwere, Dauer, Fahrlässigkeit, Schadensminderung sowie vorhandene technische und organisatorische Maßnahmen.
Zur Einordnung ein – nicht direkt vergleichbarer – deutscher Art.-32-Fall: 2018 verhängte der LfDI Baden-Württemberg nach einem Hackerangriff mit rund 330.000 betroffenen Nutzerkonten ein Bußgeld von 20.000 Euro, unter anderem wegen im Klartext gespeicherter Passwörter. Die Behörde berücksichtigte Kooperation und Verbesserungen bei der Bemessung. Der damalige Landesbeauftragte Dr. Stefan Brink betonte:
„Wer aus Schaden lernt und transparent an der Verbesserung des Datenschutzes mitwirkt, kann auch als Unternehmen aus einem Hackerangriff gestärkt hervorgehen.“ – Dr. Stefan Brink, LfDI Baden-Württemberg
Das ist ausdrücklich keine Prognose für CVE-2026-73478 und keine Rechtsberatung – sondern zeigt, dass Transparenz und Nachbesserung positiv gewertet werden können.
Dass Datenschutzverstöße ein Dauerthema bleiben, zeigt die hessische Aufsicht: Die Art.-33-Meldungen stiegen 2025 um 28 Prozent auf 2.730 (2024: 2.141), die registrierten Angriffe auf IT-Systeme sogar um 30 Prozent von 482 auf 625. Diese Zahlen sind eine hessische Gesamtsicht und nicht Drupal-spezifisch, unterstreichen aber den Trend.
CVE-2026-73478 ist mit 13/25 Punkten kein Notfall der höchsten Kategorie, aber ein Fall für ein zeitnahes, kontrolliertes Update. Dafür sprechen mehrere Gründe: Der Patch ist bereits verfügbar, die Lücke betrifft die Vertraulichkeit, und frühere Revisionen können nicht veröffentlichte Informationen enthalten. Das reale Risiko steigt, wenn öffentlich oder breit berechtigte Rollen Nicht-Node-Entitäten sehen dürfen, diese Entitäten revisionsfähig sind und ihre Historie personenbezogene oder geschäftlich vertrauliche Inhalte enthält.
Entwarnung gilt dort, wo Diff gar nicht installiert oder inaktiv ist, keine relevanten Nicht-Node-Entitäten existieren oder bereits die Version 2.0.1 beziehungsweise 2.1.1 läuft. Eine bestätigte aktive Ausnutzung oder einen öffentlichen Proof-of-Concept gab es zum Recherchezeitpunkt nicht.
Eine gesonderte Warnung des BSI oder von CERT-Bund zu genau dieser CVE ließ sich bis zum 15. August 2026 nicht ermitteln – das schließt eine spätere Meldung nicht aus. Unser Rat bleibt pragmatisch: Prüfen Sie Ihre Version, klären Sie Ihre Rollenrechte, spielen Sie den Fix ein und dokumentieren Sie Ihr Vorgehen. So schließen Sie die Lücke, bevor jemand sie ausprobiert – und stehen im Zweifel auch datenschutzrechtlich auf sicherem Boden.