Drupal External Authentication: Zugriffsschutz-Bypass durch DB-Kollationen

Veröffentlicht am 16.08.2026

Ein Login-Modul, das eigentlich für mehr Sicherheit sorgen soll, kann unter bestimmten Datenbankeinstellungen genau das Gegenteil bewirken: Es lässt zwei unterschiedliche Identitäten als gleich durchgehen – und öffnet damit die Tür zu einem fremden Benutzerkonto. Genau das beschreibt die Sicherheitsmeldung SA-CONTRIB-2026-098, die das Drupal-Sicherheitsteam am 12. August 2026 für das Modul External Authentication veröffentlicht hat. Die Schwachstelle trägt die Kennung CVE-2026-73476, ist als „moderately critical“ (13 von 25 Punkten) eingestuft und betrifft alle Versionen vor 2.0.13.

Wenn Ihre Website Drupal einsetzt und Nutzer sich über einen externen Dienst anmelden – etwa über LDAP (ein Verzeichnisdienst für Benutzerkonten), CAS oder SAML (Standards für Single Sign-On), SimpleSAMLphp, Zertifikate oder BankID –, dann kann dieses Modul im Hintergrund im Einsatz sein, ohne dass Sie es direkt sehen. Dieser Artikel erklärt, was passiert ist, wie Sie zuverlässig prüfen, ob Sie betroffen sind, und was Sie jetzt konkret tun sollten.

Was ist passiert?

Das Drupal-Modul External Authentication verwaltet die Zuordnung zwischen einer externen Identität – also einer von einem externen Anmeldedienst gelieferten Kennung – und einem Drupal-Konto. Diese Zuordnung wird in einer Datenbanktabelle namens authmap gespeichert. Dort stehen im Wesentlichen drei Dinge: die externe Kennung (authname), der Name des Anmeldedienstes (provider) und die interne Benutzer-ID des Drupal-Kontos.

Das Problem: Vor Version 2.0.13 verglich das Modul die extern übermittelten Identitätswerte nicht bytegenau, also nicht Zeichen für Zeichen exakt. Es verließ sich stattdessen auf den Vergleich, den die Datenbank selbst durchführt. Und dieser Datenbankvergleich hängt von der sogenannten Kollation ab – das sind die Regeln, nach denen eine Datenbank entscheidet, ob zwei Zeichenfolgen als gleich gelten.

Das Drupal-Sicherheitsteam formuliert es so:

„The module does not sufficiently ensure exact matching of externally supplied identity values when storing and looking up authentication mappings under certain database collation configurations.“ (Drupal Security Team, SA-CONTRIB-2026-098)

Auf Deutsch: Unter bestimmten Kollationen stellt das Modul nicht sicher, dass extern gelieferte Werte exakt übereinstimmen. Und – das ist der entscheidende Punkt für die Praxis – das Sicherheitsteam warnt ausdrücklich:

„Affected collations are quite common so all sites are encouraged to upgrade.“ (Drupal Security Team, SA-CONTRIB-2026-098)

Die betroffenen Kollationen sind also „recht verbreitet“, weshalb allen Nutzern des Moduls das Upgrade empfohlen wird – unabhängig davon, ob sie ihre genaue Datenbankkonfiguration kennen.

Der technische Hintergrund – verständlich erklärt

Viele Datenbanken sind standardmäßig so eingestellt, dass sie beim Vergleich von Text tolerant sind. Sie behandeln zum Beispiel Groß- und Kleinschreibung als gleich (case-insensitive) oder ignorieren Akzente und diakritische Zeichen (accent-insensitive). Das ist im Alltag oft praktisch – bei einer Suche etwa. Für Sicherheitsentscheidungen ist es aber gefährlich.

Ein anschauliches Beispiel liefert der offizielle Patch selbst: Er testet die Kennungen user1 und üser1. Unter Kollationen wie utf8mb4_unicode_ci oder utf8mb4_general_ci (das „ci“ steht für „case-insensitive“) kann das „ü“ auf ein „u“ zurückgeführt werden – die Datenbank hält beide Kennungen dann für identisch. Genauso können unterschiedliche Groß- und Kleinschreibungen als gleich durchgehen.

Konkret bedeutet das: Vor 2.0.13 genügte beim Nachschlagen ein Datenbanktreffer, ohne anschließend zu verifizieren, ob die gespeicherten Werte auch tatsächlich Zeichen für Zeichen den übergebenen Werten entsprachen. So kann eine externe Identität auf eine falsche Zuordnung in authmap treffen – und damit auf ein fremdes Drupal-Konto. Gelingt diese Fehlzuordnung, lässt sich der Zugriffsschutz umgehen. Wie groß der Schaden dann ist, hängt davon ab, welche Rechte das fälschlich getroffene Konto besitzt.

Wichtig: Die im Beispiel genannten Kollationsnamen sind eine Erläuterung der Vergleichslogik. Drupal hat keine vollständige Liste der betroffenen Kollationen, keine Angriffsschritte und keine Fälle realer Kompromittierung veröffentlicht.

Wie der Patch das Problem löst

Die Korrektur in 2.0.13 setzt auf zwei Ebenen an. Maintainer Sven Decabooter beschreibt die Datenbankänderung im offiziellen Patch-Commit so:

„Converts both columns from their previous case/accent-insensitive collations to binary-safe equivalents so that byte-distinct authnames and provider values are matched exactly by the database.“ (Sven Decabooter, Fixer und Maintainer)

Erstens werden die Spalten authname und provider auf ein binär-sicheres Format umgestellt – so werden byteunterschiedliche Werte von der Datenbank nicht mehr gleichgesetzt. Bestehende Installationen führen dazu das Update-Hook externalauth_update_8104() aus, das die Spalten migriert und den kombinierten Unique Key neu anlegt. Zweitens vergleicht der Laufzeitcode zusätzlich per PHP (mit dem strikten Operator ===) noch einmal bytegenau, bevor eine Benutzer-ID zurückgegeben wird.

Zur Einordnung: Dies ist kein Fehler im Drupal-Kern und keine Remote-Code-Execution – also keine Lücke, über die Angreifer beliebigen Programmcode ausführen können. Es handelt sich um einen Zugriffsschutz-Bypass in einem Contrib-Hilfsmodul (einem von der Community bereitgestellten Zusatzmodul).

Wer ist betroffen?

Laut Drupal-Projektseite verwenden zum Abrufzeitpunkt am 15. August 2026 100.455 Websites das Modul External Authentication. Das ist eine reine Nutzungszahl – keine Angabe zur Zahl tatsächlich verwundbarer oder gar kompromittierter Installationen.

Für Sie als KMU zählt nicht die Gesamtzahl aller Drupal-Instanzen, sondern Ihre eigene Konfiguration. Erhöhtes Risiko besteht, wenn alle folgenden Punkte zutreffen:

• Das Paket drupal/externalauth ist installiert und aktiv.
• Es werden externe Identitäten verwendet (etwa über LDAP, SAML, CAS, Zertifikate oder BankID).
• Die Website läuft mit MySQL oder MariaDB.
• In der Tabelle authmap sind tatsächlich Zuordnungen vorhanden.
• Es wird eine der verbreiteten, nicht binären Kollationen genutzt.

Zum Prüfzeitpunkt gibt es keinen öffentlichen Exploit-Code (Drupal bewertet die Exploit-Verfügbarkeit als „Theoretical“), und CVE-2026-73476 ist auch nicht im offiziellen CISA-KEV-Katalog (Version 2026.08.14) verzeichnet – dem US-Verzeichnis bekannter aktiv ausgenutzter Schwachstellen. Das beweist keine generelle Nichtausnutzung, es gibt aber derzeit keinen dokumentierten Nachweis aktiver Angriffe. Eine Entwarnung ist das nicht: Die Herstellerempfehlung lautet klar „Upgrade für alle“.

So prüfen Sie, ob Sie betroffen sind

1. Installation feststellen. Im Projektverzeichnis composer outdated "drupal/*" ausführen und in composer.lock nach drupal/externalauth suchen. Ist das Paket nicht installiert, betrifft Sie diese CVE nicht.
2. Aktivierung und Abhängigkeiten prüfen. In Drupal unter Erweiterungen nach „External Authentication“ bzw. externalauth suchen und prüfen, welche SSO-, Verzeichnis- oder Login-Module es als Abhängigkeit nutzen. Achtung: Das Modul selbst bietet keine sichtbare Site-Builder-Oberfläche – ein bloßer Blick auf Login-Formulare reicht daher nicht aus.
3. Mapping-Daten prüfen. Mit autorisiertem Datenbankzugang SELECT COUNT(*) AS authmap_rows FROM authmap; ausführen (bei Tabellenpräfix den tatsächlichen Namen verwenden). Ein Ergebnis größer null belegt vorhandene externe Zuordnungen. Ein Ergebnis von null ersetzt das Upgrade aber nicht.
4. Datenbank und Kollation dokumentieren. SELECT VERSION(); zeigt den Datenbankserver. Die Kollation der sicherheitsrelevanten Spalten ermitteln Sie mit: SELECT COLUMN_NAME, COLLATION_NAME, COLUMN_TYPE FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'authmap' AND COLUMN_NAME IN ('authname','provider'); Da Drupal keine vollständige Namensliste veröffentlicht, ist die Versionsprüfung und das Upgrade verlässlicher als das Ableiten einer Entwarnung aus einem Kollationsnamen.
5. Upgrade-Risiko vorab prüfen. Vor dem Update potenziell problematische Duplikate erfassen: SELECT provider, authname, COUNT(*) AS n FROM authmap GROUP BY provider, authname HAVING COUNT(*) > 1; Nicht automatisch löschen – die Zuordnung mit dem jeweiligen Identitätsprovider abgleichen.
6. Nach der Aktualisierung verifizieren. Sicherstellen, dass Composer 2.0.13 auflöst, drush updatedb fehlerfrei durchläuft, drush cache:rebuild abschließt und die externen Anmeldewege in einer Testumgebung funktionieren.

Das müssen Sie jetzt tun

1. Inventarisieren und priorisieren. Jede Installation mit drupal/externalauth vor 2.0.13 als patchpflichtig behandeln. Der Hersteller empfiehlt wegen der verbreiteten Kollationen ausdrücklich allen Sites das Upgrade.
2. Sichern und testen. Vorher Datenbank- und Code-Backup anfertigen und den Ablauf bei einer Live-Site zuerst in einer Staging-Umgebung testen – so schreiben es auch die offiziellen Drupal-Anleitungen vor.
3. Patch einspielen. Für Composer-gepflegte Projekte lautet der dokumentierte Ablauf: composer update drupal/externalauth --with-all-dependencies, danach drush updatedb und drush cache:rebuild. Das Datenbankupdate ist hier essentiell, weil 2.0.13 ein Schema-Update für authmap mitliefert.
4. Duplikatwarnung ernst nehmen. Der Patch warnt ausdrücklich: Das Datenbankupdate kann fehlschlagen, wenn bereits Zeilen desselben Providers existieren, die sich nur in Groß-/Kleinschreibung oder Akzent unterscheiden. Solche Duplikate keinesfalls blind löschen – erst Backup sichern, dann den betroffenen Provider und die echte externe Kennung ermitteln und die Zuordnung kontrolliert bereinigen.
5. Keine Behelfslösung erfinden. Drupal nennt keine allgemein sichere manuelle Kollationsänderung. Ist ein Upgrade nicht sofort möglich, die externen Anmeldewege gemeinsam mit dem Betriebs- und Identitätsprovider-Verantwortlichen risikobasiert vorübergehend einschränken, eng überwachen und einen verbindlichen Patch-Termin festlegen. Das ersetzt 2.0.13 nicht.
6. Auf Spuren einer Fehlzuordnung prüfen. Nach dem Patch Authentifizierungs-, SSO-/IdP-, Drupal- und Webserver-Logs sichern und auf unerwartete Logins, Konto- oder Rollenänderungen sowie Zugriffe auf nicht öffentliche Inhalte prüfen.

Das BSI bringt die Grundregel auf den Punkt: „Install updates as soon as possible after they are released.“ – Updates so schnell wie möglich nach Erscheinen einspielen.

Einordnung und DSGVO

Hinweis: Die folgende Einordnung ist allgemeine Information, keine Rechtsberatung. Eine ungepatchte Schwachstelle ist nicht automatisch eine meldepflichtige Datenpanne. Nach Art. 4 Nr. 12 DSGVO liegt eine Verletzung des Schutzes personenbezogener Daten erst vor, wenn eine Sicherheitsverletzung unter anderem zu unbefugtem Zugang zu oder unbefugter Offenlegung von personenbezogenen Daten führt. Wird über CVE-2026-73476 tatsächlich ein fremdes Drupal-Konto erreicht und sind darüber personenbezogene Daten zugänglich, kann diese Definition erfüllt sein.

In einem solchen Fall muss der Verantwortliche den Sachverhalt – betroffene Daten und Konten, Zeitraum, mögliche Zugriffe und getroffene Abhilfen – belastbar untersuchen und dokumentieren. Art. 33 DSGVO verlangt dann eine 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 für die Rechte und Freiheiten natürlicher Personen. Bei voraussichtlich hohem Risiko sind die betroffenen Personen nach Art. 34 grundsätzlich unverzüglich zu benachrichtigen.

Für die Prävention verlangt Art. 32 ein dem Risiko angemessenes Schutzniveau und Verfahren zur regelmäßigen Überprüfung der Maßnahmen. Ein kurzfristiges Sicherheitsupdate, dokumentierte Updateprozesse und die Prüfung der tatsächlich zugeordneten Accounts sind damit relevante technische und organisatorische Maßnahmen. Verstöße gegen Art. 32 fallen unter den Bußgeldrahmen des Art. 83 Abs. 4: bis zu 10 Mio. EUR oder bei Unternehmen bis zu 2 % des weltweiten Jahresumsatzes des vorangegangenen Geschäftsjahres, je nachdem welcher Betrag höher ist. Aus CVE-2026-73476 oder einer bloßen Patch-Verzögerung folgt jedoch keine automatische Geldbuße.

Fazit

CVE-2026-73476 ist keine spektakuläre Fernübernahme, sondern eine unauffällige, aber tückische Zugriffslücke: Eine Datenbankeinstellung, die im Alltag nützlich erscheint, kann dazu führen, dass zwei verschiedene Identitäten fälschlich als dieselbe behandelt werden. Weil die betroffenen Kollationen laut Drupal „recht verbreitet“ sind, gilt die Empfehlung ausdrücklich für alle Nutzer des Moduls – nicht nur für jene mit exotischen Konfigurationen.

Gegen akute Massenangriffe sprechen derzeit der fehlende öffentliche Exploit und der fehlende CISA-KEV-Eintrag. Das ist aber Grund zur Sorgfalt, nicht zur Sorglosigkeit. Für deutsche KMU lautet die praktikable Priorität deshalb klar: zeitnah auf External Authentication 2.0.13 aktualisieren, das Datenbankupdate ausführen, die externen Identitätszuordnungen und Logs kontrollieren – und den gesamten Vorgang sauber dokumentieren. Wer External Authentication gar nicht einsetzt, ist von dieser Meldung nicht betroffen. Wer es nutzt, sollte den Patch fest in die nächste Wartung einplanen.