Sie betreiben Nextcloud im eigenen Haus, auf dem eigenen Server, und Sie haben aus gutem Grund das Gefühl, alles richtig gemacht zu haben. Starke Passwörter, Zwei-Faktor-Authentifizierung für alle Konten, regelmäßige Updates. Genau auf diese Kombination haben Sie sich verlassen. Und dann lesen Sie eine Meldung, die diese Verlässlichkeit an ihrem wundesten Punkt trifft: Eine Lücke, die den zweiten Faktor umgeht.
Das ist kein Grund zur Panik. Aber es ist ein Befund. In meiner Praxis sehe ich immer wieder denselben Reflex: Wer 2FA aktiviert hat, hakt das Thema Anmeldesicherheit innerlich ab. Dieser Fall zeigt, warum das zu kurz greift. Der zweite Faktor ist ein Werkzeug, kein Wundermittel.
Die kurze Antwort zuerst
Wenn Sie Nextcloud in den Server-Zweigen 32 oder 33 betreiben, spielen Sie jetzt die gepatchte Version ein, 32.0.9 oder 33.0.3. Es gibt für diese Lücke keine Umgehungslösung, das Update ist der einzige Schutz. Die Einstufung ist mittel, die Ausnutzung technisch anspruchsvoll und an ein bekanntes Passwort gebunden. Das entschärft die Dringlichkeit nicht, es ordnet sie nur ein. Der eigentliche Punkt liegt tiefer und gilt unabhängig von Nextcloud: 2FA bewacht den Anmeldevorgang, nicht automatisch jede Sitzung, die dahinter schon in Gang ist.
Was genau in Nextcloud passiert ist
Am 1. Juni 2026 wurde laut NVD, der US-amerikanischen Schwachstellendatenbank, die Lücke CVE-2026-45690 veröffentlicht und als fehlerhafte Authentifizierung (Kategorie CWE-287) eingestuft. Der Kern in einem Satz: Ein Angreifer, der das Passwort eines Nutzers bereits kannte, konnte die Zwei-Faktor-Authentifizierung umgehen. Das gestohlene Passwort ist dabei die Voraussetzung, nicht die Folge der Lücke. Ohne Passwort greift der Angriff nicht.
Der Mechanismus dahinter ist lehrreich, und der offizielle Titel des Nextcloud-Advisory benennt ihn präzise: "Two-Factor Authentication Bypass via Pending Session Token Replay". Übersetzt heißt das: Zwischen der Passworteingabe und der Abfrage des zweiten Faktors stellt das System ein vorläufiges Sitzungs-Token aus, eine Art Zwischenschein. Laut SentinelOne gilt: "An attacker can extract this token and replay it via HTTP Basic Authentication to access authenticated endpoints." HTTP Basic Authentication ist das älteste und einfachste Anmeldeverfahren im Web, bei dem Zugangsdaten direkt mitgeschickt werden. Über diesen Weg ließ sich der Zwischenschein wiederverwenden, bevor der zweite Faktor je abgefragt war.
Achtung
Für diese Lücke gibt es laut Nextcloud keine Umgehungslösung (No workaround available). Der einzige Schutz ist das Update auf die gepatchte Version, für die Community-Ausgabe Server 32.0.9 oder 33.0.3. Wer wartet, hofft. Und Hoffen ist hier keine Strategie.
Betroffen war laut NVD die Community-Version Nextcloud Server in den Zweigen 32.0.0 bis vor 32.0.9 sowie 33.0.0 bis vor 33.0.3. Die letzten verwundbaren Ausgaben sind damit 32.0.8 und 33.0.2, die genannten Fix-Versionen enthalten die Korrektur. Wer eine ältere Nummer betreibt, sollte davon ausgehen, betroffen gewesen zu sein, bis das Gegenteil geprüft ist.
Achtung
Verbreiteter Irrtum: Wer die kostenpflichtige Enterprise-Version einsetzt, ist außen vor. Das ist zu viel versprochen. Auch die Enterprise-Zweige waren betroffen und wurden gesondert gepatcht, zurück bis zu den älteren Branches 31, 30 und 29. Die Enterprise-Fixes tragen die Nummern 31.0.14.5, 30.0.17.9 und 29.0.16.16.
Zur Schwere: Nach dem auf der NVD-Seite angezeigten Score der zuständigen Vergabestelle GitHub, Inc. ist die Lücke mit CVSS 3.1 auf 5.9 eingestuft, also mittel. CVSS ist der internationale Standard, der Schwachstellen auf einer Skala von 0 bis 10 einordnet. Der Vektor nennt eine hohe Angriffskomplexität und erforderliche niedrige Rechte. Wichtig für die ehrliche Einordnung: Die NVD selbst hatte zum Abrufzeitpunkt noch keine eigene Bewertung veröffentlicht, die Zahl stammt von der Vergabestelle, nicht von der NVD. Ob die Lücke in freier Wildbahn tatsächlich ausgenutzt wurde, belegt keine der geprüften Quellen.
Hinweis
Mittel bei hoher Angriffskomplexität heißt nicht harmlos, es heißt: kein Massen-Selbstläufer, aber ein realer Weg für einen Angreifer, der ohnehin schon ein Passwort in der Hand hält. Wer Ihnen daraus eine Weltuntergangsmeldung baut, verkauft Ihnen etwas. Wer sie ignoriert, unterschätzt sie.
Warum das kein reines Nextcloud-Problem ist
Hier liegt der Teil, der über dieses eine Produkt hinausreicht. Das BSI ordnet Mehr-Faktor-Authentisierung als präventiven Ansatz ein und grenzt sie von der kontinuierlichen Authentifizierung ab, die laut BSI "reaktiv" ist und "eine Kompromittierung nicht verhindern, sondern lediglich den Schaden reduzieren" kann. Meine eigene Einordnung, nicht die des BSI: Der zweite Faktor ist ein Türsteher an der Anmeldung. Eine Sitzung, die technisch schon losgelaufen ist, bevor dieser Türsteher gefragt wurde, ist eine andere Baustelle. Genau diese Lücke im Ablauf war der Angriffspunkt.
Dass es sich um ein Muster und nicht um einen Einzelfall handelt, zeigt derselbe Patch-Zyklus. Nextcloud schloss zeitgleich eine zweite, verwandte Umgehung, CVE-2026-45691. Ihr Advisory-Titel lautet "Bypass of second factor authentication on DAV endpoints by reusing a pre-2FA session ID". Wieder ein Sitzungsmerkmal aus der Phase vor dem zweiten Faktor, diesmal auf den DAV-Schnittstellen, über die etwa Kalender- und Dateizugriffe laufen. Zwei ähnliche Befunde im selben Zug sind kein Zufall, sondern ein Hinweis auf die Klasse des Problems.
Tipp
Wer HTTP Basic Authentication in seiner Nextcloud gar nicht aktiv hat, ist über diesen konkreten Vektor nicht angreifbar. Verstehen Sie das nicht als Entwarnung: Ob andere Anmeldewege in Ihrer Konfiguration den gleichen Zwischenschein akzeptieren, sieht man von außen nicht. Die Antwort steht in Ihrer Konfiguration, nicht in einer Überschrift.
Was Sie jetzt konkret tun sollten
- Version feststellen. Prüfen Sie, welcher Nextcloud-Zweig bei Ihnen läuft. Der Grund: Nur wer weiß, was betrieben wird, kann entscheiden, ob überhaupt Handlungsbedarf besteht. Raten Sie hier nicht.
- Community-Server aktualisieren. Spielen Sie 32.0.9 oder 33.0.3 ein. Der Grund: Es gibt keine Umgehungslösung, das Update ist der einzige Schutz gegen genau diese Lücke.
- Enterprise-Server nicht vergessen. Bei der kostenpflichtigen Ausgabe sind es die Zweige 31.0.14.5, 30.0.17.9 oder 29.0.16.16. Der Grund: Die bezahlte Version war ebenso betroffen, nur der Patch-Pfad ist ein anderer.
- Anmeldewege einmal bewusst durchsehen. Klären Sie, ob HTTP Basic Authentication in Ihrer Instanz aktiv ist und wozu. Der Grund: Nicht jeder Betrieb braucht dieses alte Verfahren, und was aus ist, kann nicht missbraucht werden.
- Passwörter als Voraussetzung ernst nehmen. Meine Empfehlung: Wenn Sie nicht sicher ausschließen können, dass Zugangsdaten im Umlauf waren, erzwingen Sie einen Passwortwechsel. Der Grund: Ohne bekanntes Passwort läuft dieser Angriff ins Leere, Sie nehmen ihm damit die Grundlage.
Mein Fazit
Diese Lücke ist ernst, aber sie ist beherrschbar, sobald Sie aufhören, den zweiten Faktor als Freifahrtschein zu behandeln. Sie ist gepatcht, mittelschwer eingestuft und an eine Bedingung geknüpft, die Sie beeinflussen können, nämlich ein bekanntes Passwort. Die gute Nachricht: Die Reparatur ist ein Update, kein Umbau. Die schlechtere: Ohne dieses Update gibt es keinen Ausweg.
Selbst hosten heißt, die Kontrolle zu haben, und mit der Kontrolle kommt die Pflicht, sie auch auszuüben. Was Sie nicht tun sollten, ist das Naheliegende: die Meldung wegklicken und darauf setzen, dass es Sie schon nicht getroffen hat. Glück ist keine dokumentierte Risikomanagementmaßnahme. Ein eingespielter Patch ist eine.