Drupal Quick Tabs: CVE-2026-73477 gibt unveröffentlichte Inhalte preis

Veröffentlicht am 16.08.2026

Ein unveröffentlichter Entwurf, ein noch nicht freigegebener Bewerber-Datensatz, ein interner Block mit Vertragsdetails – Inhalte, die eigentlich niemand außerhalb der Redaktion sehen soll. Genau solche Inhalte konnten auf Drupal-Websites unter bestimmten Bedingungen sichtbar werden, ohne dass sich der Besucher anmelden musste. Grund ist eine Sicherheitslücke im beliebten Drupal-Modul Quick Tabs, die das Drupal-Sicherheitsteam am 12. August 2026 im Advisory SA-CONTRIB-2026-099 unter der Kennung CVE-2026-73477 veröffentlicht hat. Betroffen sind alle Versionen vor 4.3.1. Ein Update steht bereits bereit – und Sie sollten es zeitnah einspielen.

Die gute Nachricht vorweg: Es handelt sich nicht um eine Lücke, mit der Angreifer Ihre Website übernehmen, Daten verändern oder Schadcode einschleusen könnten. Die schlechte Nachricht: Vertrauliche Inhalte, die Sie bewusst zurückgehalten haben, konnten öffentlich sichtbar geworden sein. Und wenn darin personenbezogene Daten stecken, kann das schnell zu einem DSGVO-Thema werden.

Was ist passiert?

Quick Tabs ist ein weit verbreitetes Drupal-Zusatzmodul, das tabellarische Inhaltsbereiche erzeugt – also die bekannten „Reiter“, zwischen denen Besucher auf einer Seite hin- und herklicken. In jedem einzelnen Tab lassen sich unterschiedliche Inhalte anzeigen: sogenannte Nodes (die typischen Drupal-Inhaltselemente wie Artikel oder Seiten), Blocks (wiederverwendbare Inhaltsbausteine), Views oder weitere Quick-Tabs-Instanzen.

Das Problem lag in der Zugriffskontrolle beim Anzeigen von Node- und Block-Tabs. Vereinfacht gesagt: Das Modul prüfte nicht korrekt, ob der aufrufende Besucher einen Inhalt überhaupt sehen darf. Statt eine ausdrückliche Freigabe zu verlangen, behandelte der fehlerhafte Code eine unentschiedene („neutrale“) Zugriffsentscheidung wie eine Erlaubnis. Bei wiederverwendbaren Custom Blocks fehlte laut Advisory sogar jede Zugriffsprüfung.

Das Drupal-Sicherheitsteam beschreibt das im Advisory so:

„The module did not correctly enforce access when rendering node and block tabs. It treated a neutral access result as a grant for node tabs and block plugins, and performed no access check for reusable custom blocks.“ (Drupal Security Team, SA-CONTRIB-2026-099)

Die Folge: Inhalte, die die normale Drupal-Zugriffslogik eigentlich verweigern würde – etwa unveröffentlichte Nodes oder unveröffentlichte wiederverwendbare Blocks – konnten in der Tab-Ausgabe erscheinen.

Der technische Hintergrund – verständlich erklärt

Drupal kennt für seine Zugriffsentscheidungen (technisch: AccessResult, also das Ergebnis einer Berechtigungsprüfung) drei mögliche Zustände: ausdrücklich erlaubt, ausdrücklich verboten und neutral (also weder das eine noch das andere). Das ist wichtig, denn „nicht verboten“ bedeutet in Drupal nicht automatisch „erlaubt“.

Genau hier lag der Fehler. Vor Version 4.3.1 prüfte Quick Tabs bei Nodes und Block-Plugins lediglich, ob ein Zugriff ausdrücklich verboten war. War er das nicht – also im neutralen Zustand –, wurde der Inhalt trotzdem angezeigt. Die offizielle Drupal-Core-Dokumentation warnt ausdrücklich vor genau diesem Denkfehler und schreibt für die Ja/Nein-Entscheidung die Methode isAllowed() vor:

„Always use isAllowed() for this.“ (Drupal Core API-Dokumentation, AccessResultInterface)

Die neue Version 4.3.1 stellt die Logik auf eine positive Freigabeprüfung um: Nur ein ausdrücklich erlaubtes Ergebnis wird gerendert. Zusätzlich prüft sie nun auch den Zugriff auf wiederverwendbare Block-Inhalte und ergänzt Cache-Informationen der Zugriffsentscheidung, damit nicht versehentlich eine für andere Nutzer gedachte Darstellung wiederverwendet wird.

Wichtig für die Einordnung: Ein Angreifer kann sich nicht aussuchen, welche Inhalte offengelegt werden. Sichtbar wird nur, was zuvor ein Redakteur mit der Berechtigung administer quicktabs in einen Tab eingehängt hat. Das Drupal-Team formuliert diese Entwarnung im Advisory selbst:

„The access bypass is mitigated by the fact that affected content is selected by a user with the ‘administer quicktabs’ permission when the tab is configured, so an attacker cannot choose which content is exposed.“ (Drupal Security Team, SA-CONTRIB-2026-099)

Wer ist betroffen?

Betroffen sind grundsätzlich alle Drupal-Websites, die das Modul Quick Tabs in einer Version kleiner als 4.3.1 einsetzen. Laut Drupal.org melden aktuell 26.178 Websites die Nutzung des Moduls. Diese Zahl sagt allerdings nichts über Versionsstände oder konkrete Tab-Konfigurationen aus – sie ist also keineswegs die Zahl bestätigt verwundbarer oder kompromittierter Installationen.

Tatsächlich exponierbar ist ein Fall nur, wenn alle drei folgenden Bedingungen zusammentreffen:

• Eine Quick-Tabs-Instanz enthält einen Node- oder Block-Tab (reine View- oder Untertab-Konfigurationen sind laut Advisory nicht betroffen).
• Ein Nutzer mit der Berechtigung administer quicktabs hat dort einen zugriffsbeschränkten oder unveröffentlichten Inhalt ausgewählt.
• Die betreffende Seite ist für Besucher erreichbar, die diesen Inhalt eigentlich nicht sehen dürften.

Besonders kritisch wird es, wenn in diesen unveröffentlichten Inhalten Kunden-, Bewerber-, Mitarbeiter- oder Vertragsdaten stecken.

Wird aktiv ausgenutzt? Zum Recherchezeitpunkt (15. August 2026) gibt es keine öffentlichen Hinweise auf aktive Ausnutzung und keinen veröffentlichten Proof-of-Concept. Drupal stuft die Exploit-Verfügbarkeit ausdrücklich als „theoretisch/White-Hat“ ein. Der maschinenlesbare CISA-KEV-Katalog (Version 2026.08.14) – ein US-Verzeichnis bekannter aktiv ausgenutzter Schwachstellen – enthält die CVE-ID nicht. Das ist ein zusätzlicher Indikator, aber kein Beweis für die weltweite Abwesenheit von Ausnutzung.

Ein kleiner Statushinweis am Rande: Die Seite CVE.org führt CVE-2026-73477 aktuell noch als „RESERVED“, während Drupal und die Schwachstellendatenbank OSV die Kennung bereits vollständig referenzieren. Das ist lediglich ein Unterschied im Aktualisierungsstand der Datenbanken – keine Entwarnung.

So prüfen Sie, ob Sie betroffen sind

1. Installierte Version ermitteln: Im Projektverzeichnis mit composer show drupal/quicktabs die tatsächliche Version prüfen. Bei Lock-Dateien zusätzlich composer show --locked drupal/quicktabs. Ist die Version kleiner als 4.3.1, sind Sie laut Advisory betroffen.
2. Modulstatus prüfen: Feststellen, ob das Modul auf der produktiven Website aktiviert ist, etwa mit drush pm:list --type=module --status=enabled --format=list | grep -x quicktabs. Ein installiertes, aber deaktiviertes Modul erzeugt die beschriebene Exposition nicht.
3. Quick-Tabs-Instanzen sichten: Als berechtigter Administrator die Route /admin/structure/quicktabs öffnen. Jede Instanz auf die Tab-Typen Node und Block prüfen.
4. Ausgewählte Inhalte erfassen: Für jeden Node- oder Block-Tab dokumentieren, welche konkrete Node bzw. welcher Block ausgewählt ist und ob dieser unveröffentlicht, zugriffsbeschränkt oder sensibel war. Besonders wichtig: Konnten anonyme oder niedrig privilegierte Nutzer die Seite erreichen?
5. Sichtbarkeit real testen: Die betreffenden Seiten in einer sauberen anonymen Sitzung und – falls vorhanden – mit einer niedrig privilegierten Testrolle aufrufen. Unerwartet sichtbare Entwürfe oder Blöcke als Befund sichern. Verbreiten Sie dabei keine echten personenbezogenen Inhalte weiter; bewahren Sie nur die minimal notwendigen Belege auf.
6. Logs prüfen: Webserver-, CDN- und Drupal-Logs für den verwundbaren Zeitraum auf Zugriffe auf betroffene Seiten und ggf. Quick-Tabs-AJAX-Pfade sichten. Achtung: Es gibt keine veröffentlichten Indicators of Compromise – Logtreffer allein beweisen daher noch keine Kenntnisnahme eines Inhalts.

Das müssen Sie jetzt tun

1. Sofort auf Quick Tabs 4.3.1 aktualisieren. Das ist die offizielle Behebung, veröffentlicht am 12. August 2026. Vor dem Produktiv-Rollout ein Backup anlegen und im Staging testen. Bei Composer-Installationen – vorbehaltlich Ihrer eigenen Dependency-Policy – etwa mit composer update drupal/quicktabs --with-all-dependencies, danach die üblichen Schritte drush updatedb und drush cache:rebuild ausführen. Die Release-Seite nennt als Paketkanal composer require 'drupal/quicktabs:^4.3'. Unterstützte Core-Versionen sind Drupal ^10.3, ^11 und ^12.
2. Wenn Patchen nicht sofort möglich ist: Alle Quick-Tabs-Instanzen mit Node- oder Block-Tabs temporär deaktivieren, aus dem Layout entfernen oder die ausgewählten Inhalte so ändern, dass keine unveröffentlichten oder zugriffsbeschränkten Daten gerendert werden. Das ist nur eine Übergangslösung, kein Ersatz für das Update.
3. Nach dem Update erneut testen: Jede zuvor identifizierte Seite anonym und mit relevanten Rollen erneut aufrufen, anschließend Caches leeren. Ziel: Zugriff nur bei einem ausdrücklich erlaubten Ergebnis.
4. Berechtigungen aufräumen: Die Berechtigung administer quicktabs nach dem Least-Privilege-Prinzip (nur so viele Rechte wie nötig) überprüfen und ausschließlich vertrauenswürdigen Redakteuren geben.
5. Bei möglicherweise personenbezogenem Inhalt: Exposition sofort stoppen, Umfang und Zeitraum ermitteln, Zugriffslogs sichern, Datenschutzbeauftragte oder Fachberatung einbeziehen und die Risiko- und Meldepflichtprüfung dokumentieren.
6. Patch-Management verbessern: Drupal-Security-Advisories abonnieren, Composer-Lockdateien inventarisieren und nach jedem Update eine rollenbasierte Sichtbarkeitsprüfung für nichtöffentliche Inhalte durchführen.

Der Hersteller ist bei der Dringlichkeit übrigens eindeutig:

„This is a security release of Quick Tabs. Sites using Quick Tabs are urged to upgrade to 4.3.1 immediately after reviewing the associated security advisories.“ (Quick Tabs Release Notes 4.3.1)

Einordnung und DSGVO

Drupal stuft die Lücke mit 13 von 25 Punkten als „moderately critical“ ein – Authentifizierung „None“ (keine Anmeldung nötig), Vertraulichkeitsauswirkung „Some“, Integritätsauswirkung „None“, Exploit-Status „Theoretical“. Technisch also eine Schwachstelle mittlerer Schwere. Für ein einzelnes KMU kann das Risiko jedoch höher ausfallen, wenn Quick Tabs unveröffentlichte oder zugriffsbeschränkte personenbezogene Inhalte darstellt.

Und damit sind wir beim Datenschutz. Ein unveröffentlichter Inhalt ist nicht automatisch personenbezogen – ein rein redaktioneller Entwurf ohne Personendaten ist keine Datenpanne. Aber: Nach Art. 4 Nr. 12 DSGVO umfasst eine „Verletzung des Schutzes personenbezogener Daten“ auch die unbefugte Offenlegung oder den unbefugten Zugang. Wurde also über einen fehlerhaften Quick-Tabs-Tab ein unveröffentlichter Kunden-, Kontakt-, Bewerber-, Mitarbeiter- oder Vertragsinhalt sichtbar, kann das eine meldepflichtige Datenpanne sein.

Für Verantwortliche gilt dann:

• Jede personenbezogene Datenpanne ist zu dokumentieren.
• Eine Meldung an die zuständige Aufsichtsbehörde ist unverzüglich und möglichst binnen 72 Stunden ab Kenntnis erforderlich – es sei denn, die Verletzung führt voraussichtlich zu keinem Risiko für die Rechte und Freiheiten betroffener Personen.
• Bei voraussichtlich hohem Risiko sind grundsätzlich auch die betroffenen Personen unverzüglich zu benachrichtigen.

Die Entscheidung ist ein einzelfallbezogener Risikobefund – keine automatische Folge der CVE. Die EDPB (Europäischer Datenschutzausschuss) empfiehlt KMU ausdrücklich, vorab Verfahren für Eindämmung, Risikobewertung, Dokumentation und Meldung einzurichten.

Zu Bußgeldern: Diese fallen nicht automatisch an. Art. 83 DSGVO verlangt eine einzelfallbezogene, wirksame, verhältnismäßige und abschreckende Sanktion. Verstöße gegen technisch-organisatorische Pflichten (etwa Art. 32) können bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes erreichen, schwerere Fälle bis zu 20 Mio. Euro oder 4 %. Für diesen konkreten Fall sind jedoch keine öffentlichen Bußgelder, Meldungen oder Schäden bekannt.

Fazit

CVE-2026-73477 ist keine Katastrophe, aber auch nicht zu vernachlässigen. Die Lücke erlaubt weder Datenmanipulation noch Serverübernahme – sie verletzt „nur“ die Vertraulichkeit und kann zuvor vom Administrator ausgewählte, nicht öffentliche Inhalte preisgeben. Genau diese Inhalte sind aber oft die heiklen: Entwürfe, interne Blöcke, personenbezogene Daten.

Da ein Fix bereitsteht und aktuell keine öffentliche aktive Ausnutzung dokumentiert ist, lautet die richtige Priorität klar: kurzfristig auf 4.3.1 aktualisieren und gezielt prüfen, ob in der Vergangenheit etwas offengelegt wurde – statt abzuwarten. Prüfen Sie Ihre Quick-Tabs-Instanzen auf Node- und Block-Tabs, testen Sie die Sichtbarkeit als anonymer Besucher, und klären Sie im Zweifel gemeinsam mit Ihrer Datenschutzberatung, ob personenbezogene Daten betroffen waren. Wer sein Patch-Management jetzt sauber aufsetzt und Berechtigungen konsequent nach dem Least-Privilege-Prinzip vergibt, ist beim nächsten Advisory deutlich schneller handlungsfähig.