CVE-2026-44825: Apache Solr — bin/solr auth enable legt heimlich vier Default-Nutzer mit öffentlich bekannten Passwörtern an

TL;DR — die 90-Sekunden-Zusammenfassung

Was wurde veröffentlicht?

CVE-2026-44825 (Apache Solr, 01.06.2026). Klasse: unsichere Default-Konfiguration / hardcodierte Zugangsdaten. Mechanismus: bin/solr auth enable bootstrappt BasicAuth und schreibt dabei neben dem vom Betreiber gewählten Konto vier Template-Nutzer (superadmin, admin, search, index) mit öffentlich bekannten Passwörtern in die security.json.

Wie schwer?

Hoch — CVSS v3.1 8.1 (AV:N/AC:H/PR:N/S:U/C:H/I:H/A:H), CWE-798 + CWE-1188. Reichweite: voller administrativer Zugriff auf den Solr-Cluster über bekannte Default-Konten. Eintrittsschwelle: BasicAuth wurde über bin/solr auth enable eingerichtet und der Solr-Endpoint ist für den Angreifer erreichbar.

Welche Solr-Versionen sind betroffen?

Apache Solr 9.4.0 bis 9.10.1 sowie 10.0.0. Behoben in den (zum Veröffentlichungszeitpunkt noch nicht freigegebenen) Versionen 9.11.0 und 10.1.0.

Bin ich als Moselwal-Kunde betroffen?

Betroffen sind Sie, wenn Sie eine Solr-Instanz im genannten Versionsbereich betreiben, deren BasicAuth über bin/solr auth enable eingerichtet wurde — typisch bei TYPO3-Suchen über EXT:solr mit eigenem Solr-Host. Nicht betroffen: Cluster, die BasicAuth nie über dieses Tool gebootstrappt haben, oder bei denen die Template-Nutzer nachträglich starke Passwörter bekommen haben.

Sofort-Mitigation?

In die security.json schauen und die Template-Nutzer superadmin, admin, search, index entweder entfernen oder mit starken, einzigartigen Passwörtern versehen. Parallel den Solr-Endpoint gegen das öffentliche Netz abschotten (er gehört ohnehin nie direkt ins Internet). Mittelfristig auf 9.11.0 / 10.1.0 heben, sobald verfügbar.

Kritikalität?

Siehe Hero-Badge high (CVSS 8.1). Keine KEV-Aufnahme, EPSS sehr niedrig Stand 02.06. — aber öffentlich bekannte Default-Credentials senken die Exploit-Hürde drastisch, sobald der Endpoint erreichbar ist.

 

Was ist passiert

Apache Solr hat am 1. Juni 2026 CVE-2026-44825 veröffentlicht — einen Befund im Werkzeug, mit dem man die Basic Authentication aktiviert. Solr liefert dafür den CLI-Befehl bin/solr auth enable, der die Authentifizierung einrichtet und eine security.json mit den Zugangsdaten erzeugt. Der Betreiber gibt dabei ein eigenes Konto an und erwartet, dass genau dieses Konto angelegt wird.

Das Problem: In den Versionen 9.4.0 bis 9.10.1 und in 10.0.0 schreibt das Tool zusätzlich und ohne sichtbaren Hinweis vier Template-Nutzer in die security.json — superadmin, admin, search und index — mit Passwörtern, die fest im Tool hinterlegt und damit öffentlich bekannt sind. Diese Konten tragen administrative Rollen. Der Betreiber, der gerade BasicAuth eingeschaltet hat, um seinen Solr abzusichern, hat damit unbemerkt vier Hintertüren mit bekannten Schlüsseln mitinstalliert.

Die Folge ist direkt: ein Angreifer, der den Solr-Endpoint über das Netz erreicht, meldet sich mit einem der bekannten Template-Konten an und hat vollen administrativen Zugriff auf den Cluster. Er kann die Konfiguration ändern, alle Indizes lesen, Daten exfiltrieren oder den Dienst stören. Genau deshalb klassifiziert der CVE die Schwachstelle als Kombination aus CWE-798 (hardcodierte Zugangsdaten) und CWE-1188 (unsichere Default-Initialisierung): die Unsicherheit entsteht nicht durch einen Fehler des Betreibers, sondern durch das Default-Verhalten des Setup-Tools.

Der Workaround ist einfach und sofort umsetzbar: die vier Template-Nutzer aus der security.json löschen oder ihnen starke, einzigartige Passwörter geben. Die saubere Lösung sind die kommenden Versionen 9.11.0 und 10.1.0, die das Tool so korrigieren, dass es keine zusätzlichen Konten mehr anlegt; ein Upgrade dorthin genügt dann, um das Problem zu beheben.

Technische Einordnung

Strukturell ist CVE-2026-44825 ein Lehrstück über die Differenz zwischen „Authentifizierung aktiviert“ und „Authentifizierung sicher“. Das Setup-Tool tut auf den ersten Blick genau, was es soll: nach bin/solr auth enable verlangt Solr Zugangsdaten. Der Betreiber sieht einen Login-Prompt und hakt „abgesichert“ ab. Dass derselbe Schritt vier bekannte Konten mit installiert hat, ist im Normalbetrieb unsichtbar — es steht in der security.json, die kaum jemand nach dem Setup noch einmal Zeile für Zeile liest. Genau diese Unsichtbarkeit ist die Gefahr: die Lücke wird nicht durch eine Aktion geöffnet, sondern durch das Ausbleiben einer Aktion (niemand entfernt die Template-Nutzer, weil niemand von ihnen weiß).

Der zweite Punkt ist die Erreichbarkeit. Der CVSS-Vektor weist AV:N (Network) und PR:N (keine Privilegien nötig) aus, aber AC:H (hohe Angriffskomplexität) — letzteres, weil zwei Bedingungen zusammenkommen müssen: BasicAuth wurde über das verwundbare Tool gebootstrappt, und der Endpoint ist für den Angreifer erreichbar. Solr gehört nie direkt ins öffentliche Internet; in einer sauberen Architektur sitzt es hinter der Anwendung im internen Netz. Die unangenehme Realität ist aber, dass exponierte Solr-Instanzen seit Jahren ein wiederkehrender Fund bei Internet-Scans sind. Wer einen solchen exponierten Solr betreibt und BasicAuth „zur Sicherheit“ über das Tool eingeschaltet hat, hat die Tür mit bekanntem Schlüssel verschlossen.

Drittens, die TYPO3-Relevanz. Apache Solr ist im TYPO3-Ökosystem die verbreitete Such-Infrastruktur: die Extension EXT:solr (Apache Solr for TYPO3) bindet einen Solr-Host an, der die Inhalte indiziert. Viele Mittelstands-TYPO3-Installationen betreiben dafür eine eigene Solr-Instanz — teils als Docker-Container, teils als Paket auf einem Such-Host. Wenn diese Instanz im verwundbaren Versionsbereich liegt und BasicAuth über bin/solr auth enable eingerichtet wurde, ist sie betroffen. Der Index enthält dabei oft genau die Inhalte, die das CMS ausliefert — bei Intranets oder geschützten Bereichen also potenziell personenbezogene oder vertrauliche Daten.

Wer ist betroffen

Die schnellste Antwort liefert ein Blick in die security.json: stehen dort die Nutzer superadmin, admin, search oder index, ohne dass Sie sie bewusst angelegt haben, ist die Instanz betroffen. Der Versionsstand ergänzt das (bin/solr version oder die Admin-UI).

Auswirkungen und Sofortmaßnahmen

Die Auswirkung ist ein vollständiger Admin-Takeover des Solr-Clusters über bekannte Zugangsdaten. Wer als superadmin oder admin eingeloggt ist, kontrolliert Konfiguration und Indizes — kann also Suchergebnisse manipulieren, indizierte Inhalte (inklusive geschützter) auslesen oder den Dienst lahmlegen. Bei TYPO3-Suchen, deren Index auch nicht-öffentliche Inhalte enthält, ist das datenschutzrelevant.

Operational Decision Block

• Sofort handeln, wenn: die Solr-Instanz im verwundbaren Versionsbereich liegt, über bin/solr auth enable abgesichert wurde und über mehr als nur localhost erreichbar ist.
• Kontrolliert im Wartungsfenster, wenn: die Instanz nur lokal an die Anwendung gebunden ist (kein Netzpfad für Dritte) — der Workaround bleibt Pflicht, der akute Hebel ist kleiner.
• Kein Solr-Druck, wenn: Sie kein Solr betreiben oder BasicAuth nie über das Tool eingerichtet haben — kurz die security.json gegenprüfen und abhaken.

In dieser Reihenfolge. Erstens, security.json prüfen und die Template-Nutzer superadmin, admin, search, index identifizieren. Zweitens, entfernen oder neu passworten: die Konten löschen oder ihnen starke, einzigartige Passwörter geben (und die Rollen prüfen). Drittens, Erreichbarkeit absichern: der Solr-Endpoint gehört ins interne Netz hinter die Anwendung, nicht ins öffentliche Internet — Firewall/Netzwerk-Policy entsprechend setzen. Viertens, Logs prüfen: Zugriffe der Template-Konten in den Solr-Request-Logs suchen (Login als superadmin/admin ist ein klares Signal, wenn Sie diese Konten nie selbst nutzen). Fünftens, mittelfristig auf 9.11.0 / 10.1.0 heben, sobald verfügbar.

Dieser Beitrag spiegelt unsere technische und strategische Einschätzung. Er ersetzt keine Rechtsberatung und keine Datenschutz-Folgenabschätzung.

Detection / Prüfung

Zwei Fragen: „habe ich die Template-Nutzer“ (Konfig-Frage) und „hat jemand sie benutzt“ (Log-Frage).

Prüf-Snippets (Copy/Paste):

# 1) Solr-Version feststellen
bin/solr version

# 2) security.json auf Template-Nutzer prüfen (Dateipfad je nach Setup)
grep -nE '"(superadmin|admin|search|index)"' /var/solr/data/security.json 2>/dev/null \
  || grep -nE '"(superadmin|admin|search|index)"' server/solr/security.json 2>/dev/null

# 3) Falls Solr läuft: Authentifizierungs-Config über die API lesen
curl -s -u <ihr-admin>:<pw> 'http://localhost:8983/solr/admin/authentication' | jq .

# 4) Request-Logs auf Logins der Template-Konten durchsuchen
grep -REn '(superadmin|admin|search|index)' server/logs/*.request.log 2>/dev/null

Was auffällig ist: das Vorhandensein der vier Konten in security.json, das Sie nicht selbst angelegt haben — sowie jeder erfolgreiche Request, der über eines dieser Konten authentifiziert wurde, falls Sie sie nie aktiv nutzen. Da die Default-Passwörter öffentlich bekannt sind, ist jeder Fremd-Login über diese Konten als Kompromittierung zu behandeln.

Betreiberempfehlung

Mittelstand

Für TYPO3-Betreiber mit EXT:solr ist der schnellste Schritt der Blick in die security.json des Solr-Hosts. Stehen dort die Template-Nutzer, entfernen oder neu passworten — das ist eine Minutenarbeit und schließt den Pfad sofort. Parallel sicherstellen, dass der Solr-Port (Standard 8983) nicht aus dem Internet erreichbar ist; in vielen Setups ist das die eigentlich gefährlichere Baustelle, unabhängig von diesem CVE.

Container / Kubernetes

Wer Solr als Container betreibt, prüft, ob die security.json aus einem Image, einem ConfigMap/Secret oder einem bin/solr auth enable-Init-Step stammt — und ob dieser Init-Step die Template-Nutzer mitbringt. Die Korrektur gehört in das Image bzw. das Secret, nicht in den laufenden Container; danach Pod neu ausrollen. Den Versionssprung auf 9.11.0 / 10.1.0 in die Image-Pflege aufnehmen, sobald die Releases da sind.

Hosting & Betrieb

Generell gilt für Solr: Authentifizierung ist die zweite Verteidigungslinie, Netz-Isolation die erste. Ein Solr, der nur intern an die Anwendung gebunden ist, ist auch mit Default-Konten nur von innen angreifbar. Die Kombination aus exponiertem Endpoint und bekannten Credentials ist der gefährliche Fall — und genau die Kombination, die dieser CVE adressiert.

Fazit

CVE-2026-44825 ist kein Exploit-Feuerwerk, sondern die stille Variante des Risikos: ein Setup-Schritt, der „Sicherheit einschalten“ verspricht und dabei vier bekannte Schlüssel mit ausliefert, die niemand bewusst bestellt hat. Die Triage ist billig (ein Blick in die security.json), der Workaround ist ein Minuten-Job (Konten löschen oder neu passworten), und die Dauerlösung ist ein normales Upgrade auf 9.11.0 / 10.1.0. Die wichtigste Begleit-Lehre ist die alte: Solr gehört nie offen ins Internet — Netz-Isolation ist die erste Linie, Authentifizierung die zweite. Risiko nüchtern: hoch für exponierte, über das Tool abgesicherte Instanzen, gering für sauber isolierte — die security.json und die Firewall-Regel trennen die beiden Fälle in Minuten.

Quellen

• Apache Solr — Security (offizielle Advisory-Übersicht, CVE-2026-44825: bin/solr auth enable konfiguriert zusätzliche unsichere Nutzer)
• OpenCVE — CVE-2026-44825 (Beschreibung, CVSS v3.1 8.1 AV:N/AC:H/PR:N/S:U/C:H/I:H/A:H, CWE-798/CWE-1188, betroffene Versionen, Stand 01.06.2026)
• Apache Solr Wiki — SolrSecurity (Kontext zu BasicAuth und security.json)