Dieser Text wurde mit künstlicher Intelligenz (KI) erstellt.In der weit verbreiteten Open-Source-Wiki-Software DokuWiki wird eine als CVE-2026-37106 geführte Schwachstelle diskutiert, die von der National Vulnerability Database (NVD) mit einem CVSS-Score von 9.8 eingestuft wird. Anders als in ersten Meldungen dargestellt handelt es sich nicht um Remote Code Execution, sondern um die Möglichkeit, über die Registrierungsfunktion (register in inc/auth.php) ein Benutzerkonto anzulegen. Der Hersteller bestreitet die Einstufung als Schwachstelle: Das Verhalten sei beabsichtigt, sobald die optionale Selbstregistrierung aktiviert ist – eine Funktion, die in der Standardkonfiguration deaktiviert ist. Dieser Beitrag ordnet die Meldung sachlich ein.
Zentrale Fakten:
CVE-ID: CVE-2026-37106
Einstufung: CVSS 9.8 (kritisch) laut NVD/CISA-ADP – vom Hersteller ausdrücklich bestritten
Art der Schwachstelle: Unautorisierte Konto-Anlage über die register-Funktion (CWE-640) – keine Remote Code Execution
Voraussetzung: Nur relevant, wenn die optionale Selbstregistrierung aktiviert ist (Standard: deaktiviert)
Status: Als beabsichtigtes Verhalten bestritten; kein Patch angekündigt; keine aktive Ausnutzung bekannt
Was CVE-2026-37106 tatsächlich beschreibt
Laut NVD erlaubt die Registrierungsfunktion (register in inc/auth.php) der DokuWiki-Version 2025-05-14b „Librarian“ einem entfernten Nutzer das Anlegen eines Kontos. Die NVD ordnet dies der Schwäche CWE-640 zu und vergibt über die CISA-ADP-Anreicherung einen CVSS-Score von 9.8. Ein zunächst kursierendes GitHub-Advisory sprach von „arbitrary code execution“ – diese Darstellung ist widersprüchlich und wird durch die NVD-Beschreibung nicht gestützt: Es geht um Konto-Anlage, nicht um Codeausführung.
Wichtige Einordnung: Der DokuWiki-Hersteller bestreitet die Schwachstelle. Die Selbstregistrierung ist ein dokumentiertes, optionales Feature, das in der Standardinstallation deaktiviert ist. Ist sie bewusst aktiviert, ist das Anlegen von Konten das erwartete Verhalten. Der hohe CVSS-Wert (Vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) spiegelt die reale Auswirkung einer reinen Konto-Anlage daher nur eingeschränkt wider und ist entsprechend umstritten.
Welches Risiko besteht realistisch?
Für Installationen mit deaktivierter Selbstregistrierung – dem Standard – ergibt sich aus dieser Meldung kein unmittelbares Risiko. Wo die Selbstregistrierung aktiv ist, kann ein nicht angemeldeter Nutzer selbstständig ein Konto anlegen. Je nach Konfiguration (etwa fehlende E-Mail-Verifikation) und vergebenen Zugriffsrechten (ACLs) könnte er damit auf nicht-öffentliche Wiki-Inhalte oder angemeldete Funktionen zugreifen. Eine Codeausführung, eine Server-Übernahme oder ein Ransomware-Szenario lässt sich aus dieser Schwachstelle – anders als ursprünglich berichtet – nicht ableiten.
Empfohlene Handlungsmaßnahmen
Angesichts der bestrittenen Einstufung ist ein besonnenes, konfigurationsorientiertes Vorgehen sinnvoll:
Konfiguration prüfen: Stellen Sie fest, ob die Selbstregistrierung aktiviert ist. In der Standardkonfiguration ist sie deaktiviert – dann sind Sie von dieser Meldung nicht betroffen.
Registrierung absichern (falls genutzt): Beschränken Sie die Registrierung auf vertrauenswürdige Nutzer, aktivieren Sie die E-Mail-Verifikation und überprüfen Sie Ihre ACL-Rechte, damit neu angelegte Konten keinen Zugriff auf sensible Inhalte erhalten.
Bestand & Updates im Blick behalten: Identifizieren Sie exponierte DokuWiki-Instanzen und deren Versionsstand und beobachten Sie die offiziellen Release-Kanäle, falls der Hersteller die Registrierungslogik künftig weiter härtet.
Einordnung in Compliance-Anforderungen
Unabhängig von diesem konkreten Fall bleibt ein strukturiertes Schwachstellen- und Konfigurationsmanagement Kern moderner Sicherheitsstandards: Die EU-Richtlinie NIS-2 sowie die ISO 27001 (Anhang A, A.8.8) fordern einen definierten Prozess zur Handhabung technischer Schwachstellen und sicherer Konfigurationen. Eine Meldepflicht nach Art. 33 DSGVO entsteht nur, wenn es tatsächlich zu einem unbefugten Zugriff auf personenbezogene Daten kommt – bei korrekt konfigurierter DokuWiki-Instanz ist das durch diese Meldung nicht der Fall.
Wie LocateRisk Transparenz schafft
Selbst betriebene Systeme wie DokuWiki sind häufig nicht zentral dokumentiert. Eine kontinuierliche Überwachung der externen Angriffsfläche hilft, solche Instanzen samt Konfigurations- und Versionsstand im Blick zu behalten.
External Attack Surface Management (EASM): LocateRisk deckt öffentlich erreichbare Systeme Ihrer Organisation auf – einschließlich vergessener Subdomains, unkontrollierter Cloud-Assets und Schatten-IT. Exponierte DokuWiki-Instanzen werden über Fingerprinting erkannt, sodass Sie veraltete oder unnötig öffentlich erreichbare Installationen identifizieren und deren Absicherung veranlassen können.
Continuous Vendor Risk Management (C-VRM): Betreiben externe Dienstleister oder Partner exponierte Web-Anwendungen für Sie, lässt sich deren Sicherheits- und Patch-Niveau über ein kontinuierliches Vendor Risk Management bewerten und nachverfolgen.
LocateRisk ist als Lösung „Made in Germany“ konzipiert und unterstützt Unternehmen bei der Erfüllung von DSGVO-Anforderungen – gehostet in zertifizierten deutschen Rechenzentren mit Schutz vor dem US Cloud Act.
Quellen und weitere Infos
NVD/NIST (maßgebliche Einordnung, Status „Disputed“): CVE-2026-37106
LocateRisk identifiziert Ihre externen IT-Systeme und bewertet deren Sicherheit kontinuierlich und vollautomatisiert. So erkennen Sie Schwachstellen, bevor Angreifer sie ausnutzen.
Nein. Die maßgebliche NVD-Beschreibung spricht vom Anlegen eines Benutzerkontos über die register-Funktion in inc/auth.php, nicht von Codeausführung. Ein frühes GitHub-Advisory nannte zwar „arbitrary code execution“, diese Formulierung ist widersprüchlich und wird von der NVD nicht gestützt.
Nur, wenn Sie die optionale Selbstregistrierung aktiviert haben. In der Standardkonfiguration ist diese deaktiviert – dann besteht aus dieser Meldung kein Risiko. Prüfen Sie Ihre Konfiguration und die vergebenen ACL-Rechte.
Nein. Der Hersteller bestreitet die Einstufung als Schwachstelle, da es sich um beabsichtigtes Verhalten der optionalen Selbstregistrierung handelt (NVD-Status „Disputed“). Ein Sicherheits-Patch ist daher nicht angekündigt. Die Absicherung erfolgt über die Konfiguration – die Selbstregistrierung deaktiviert lassen oder einschränken.
We use cookies to optimize our website and our service.
Functional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistics
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Deutsch 
English 
Français