Continuwuity 26.7.3: Wer nur den Container neu startet, hat noch nicht gepatcht

Ein Matrix-Homeserver kann erreichbar sein, Nachrichten zustellen und im Monitoring vollständig grün aussehen – und trotzdem auf einem sicherheitskritisch veralteten Stand laufen. Genau deshalb ist Continuwuity 26.7.3 mehr als eine neue Versionsnummer. Das stabile Release vom 11. August 2026 schließt laut Projekt zwei Schwachstellen: die Offenlegung bestimmter Matrix-Ereignisse über Föderation und unter bestimmten Bedingungen die Übernahme eines anderen Kontos auf demselben Server.

Die Release-Seite fordert ein schnelles Update. Besonders hervorgehoben werden Betreiber, die Continuwuitys SMTP-Unterstützung verwenden. Gleichzeitig sind die technischen Details einer als hoch eingestuften Schwachstelle noch nicht öffentlich. Das verlinkte Advisory GHSA-v2x6-m99h-vqxx war am 18. August weder als öffentliche GitHub-Seite noch über die geprüften Advisory-Schnittstellen abrufbar.

Das schafft eine unangenehme, aber beherrschbare Lage: Die Warnung ist ernst genug zum Handeln. Die öffentliche Beleglage ist zu dünn für erfundene Exploitgeschichten.

Was tatsächlich veröffentlicht wurde

Continuwuity 26.7.3 ist laut offizieller Forgejo-Release-API weder Entwurf noch Vorabversion. Der annotierte Tag v26.7.3 zeigt auf Commit 6957ff7689a3184903a717159287acdcd6a79d23; die API weist die Signaturprüfung des Tags als erfolgreich aus.

Der Vergleich zwischen 26.7.2 und 26.7.3 umfasst vier Commits. Die Release-Notiz betont, dass keine neuen Funktionen aus dem Entwicklungszweig enthalten sind. Das ist für den Betrieb wichtig: Der stabile Sicherheitspatch soll die bekannten Probleme mit möglichst begrenztem Änderungsumfang beheben. Die später veröffentlichte Version 26.8.0-alpha.1 ist ausdrücklich eine Vorabversion und damit kein gleichwertiger Ersatz für einen stabilen Serverbetrieb.

Das Projekt benennt zwei Korrekturen:

SEC26: Bestimmte Ereignisse konnten über Föderation offengelegt werden.
SEC28: Unter bestimmten Bedingungen konnte ein Angreifer ein anderes Konto auf demselben Server übernehmen.

Mehr Details liefert der öffentliche Release-Text nicht. Welche Ereignistypen betroffen waren, welche Rechte ein Angreifer brauchte, ob Nutzerinteraktion notwendig war und welche Versionen vor 26.7.3 exakt betroffen sind, bleibt offen.

„This Week in Matrix“ vom 14. August bestätigt die zwei Korrekturen und die hohe Priorität für Betreiber mit konfiguriertem SMTP. Der Wochenbericht ist eine primärnahe Projektquelle, keine unabhängige Sicherheitsanalyse. Er bestätigt den Release-Charakter und die Dringlichkeit, liefert aber keine fehlenden Exploitdetails nach.

SMTP erhöht die Dringlichkeit – es erklärt nicht den Angriff

Die Continuwuity-Konfigurationsreferenz dokumentiert unter [global.smtp] E-Mail-Funktionen. Dazu zählen selbstbediente Passwort-Zurücksetzungen sowie optionale E-Mail-Anforderungen bei Registrierung und Registrierungs-Token. Die Release-Warnung hebt SMTP-Installationen ausdrücklich hervor.

Aus diesen beiden Tatsachen darf kein konkreter Angriffspfad konstruiert werden. Es ist derzeit nicht öffentlich belegt, welche SMTP-Funktion die Dringlichkeit auslöst oder ob das GHSA eindeutig SEC26 oder SEC28 zugeordnet ist. Ein Beitrag, der jetzt einen detaillierten Passwort-Reset-Exploit behauptet, wäre keine Aufklärung, sondern Spekulation.

Für Betreiber folgt trotzdem eine klare Priorität: intern feststellen, ob SMTP aktiviert ist, Installationsweg und laufende Version klären und den stabilen Patch kontrolliert einspielen. SMTP-Host, Zugangsdaten, interne IP-Adressen, Tokens und reale Konten gehören weder in einen öffentlichen Artikel noch in ein Supportticket.

Ein SMTP-Test nach dem Update sollte mit einem isolierten Testkonto erfolgen. Er prüft Anforderung, Mailzustellung und Abschluss einer Passwort-Zurücksetzung. Das belegt den legitimen Nutzerweg. Es beweist nicht, dass jede unbekannte Angriffsvariante ausgeschlossen ist.

Die Paketquelle gehört zur Sicherheitskette

Das Projekt bietet mehrere Auslieferungswege: das Image forgejo.ellis.link/continuwuation/continuwuity:v26.7.3, ein Debian-Paket sowie Binärdateien für x86-64 und ARM64. Docker Hub, GitHub Container Registry und GitLab Container Registry werden in der Release-Notiz als Spiegel bezeichnet, die veraltet sein können. Die Docker-Dokumentation empfiehlt die Forgejo-Registry für das aktuelle getaggte Release.

Damit wird die Quelle selbst zum Teil des Sicherheitsnachweises. Ein latest-Tag aus einem Spiegel und ein erfolgreicher Neustart beweisen nicht, dass 26.7.3 läuft. Belastbar wird der Vorgang erst mit einer kleinen Kette:

Ausgangsversion feststellen.
Installationsweg und tatsächlich verwendete Quelle dokumentieren.
Stabilen Zielstand festlegen.
Backup und Rückweg prüfen.
Update ausführen.
Gestartete Version über den vorgesehenen Versionsendpunkt verifizieren.
Zentrale Nutzerwege testen.

Dasselbe Problem kann bei Paketen und manuellen Binärdateien auftreten. Der Paketmanager kann eine neue Version installieren, während der Dienst über einen alten Pfad eine andere Binärdatei startet. Der Nachweis endet deshalb nicht bei der Meldung des Updatewerkzeugs, sondern bei der tatsächlich laufenden Version.

RocksDB: Eine Kopie ist noch kein Rückweg

Continuwuity verwendet RocksDB. Die Wartungsdokumentation warnt davor, Dateien im Datenbankverzeichnis manuell zu verändern. Für ein Offline-Backup wird der Dienst heruntergefahren und der vollständige database_path kopiert; die Mediendaten liegen im Unterordner media/.

Online-Backups verwenden ein anderes Format. Ihre Wiederherstellung besteht aus mehreren ausdrücklich dokumentierten Schritten. Ein gefüllter Backup-Ordner ist deshalb kein Beleg für einen funktionierenden Restore.

Zwei typische Fehler sind leicht zu übersehen. Wer nur media/ kopiert, sichert Anhänge, aber nicht den vollständigen Serverzustand. Wer regelmäßig ein Online-Backup erzeugt, es aber nie in einer getrennten Umgebung wiederherstellt, kennt weder die tatsächliche Dauer noch mögliche Lücken im Ablauf.

Ein dringender Patch ist kein Argument gegen eine Sicherung. Im Gegenteil: Ein vorbereiteter Rückweg verkürzt die Zeit, in der ein Betreiber zwischen Sicherheitsrisiko und Ausfallangst festhängt. Patchgeschwindigkeit und Restore-Fähigkeit sind zwei Teile desselben Betriebsprozesses.

Nach dem Neustart beginnt die Abnahme

Continuwuitys Bereitstellungsdokumentation nennt den Versionsendpunkt, Matrix-Client-Endpunkte und Föderationstests als Prüfwege. Für einen Community-Homeserver reicht ein einzelner HTTP-Check trotzdem nicht.

Nach dem Update sollten mindestens Anmeldung, lokale Nachricht, Einladung, Beitritt, Medienzugriff, verschlüsselte Kommunikation und Föderation zu einer kontrollierten Gegenstelle geprüft werden. Bei aktiviertem SMTP kommt ein Test der Passwort-Zurücksetzung hinzu. Dafür werden Testkonten und Test-Räume verwendet; echte Access Tokens, Nutzerkennungen und Raum-IDs werden nicht in öffentliche Protokolle kopiert.

Der Unterschied zwischen Transport und Funktion ist zentral. Nginx, TLS, DNS und .well-known können korrekt sein, während eine Matrix-Funktion scheitert. Das zeigte bereits der andere Continuwuity-Fall vom Juli 2026, bei dem föderierte Einladungen zwischen Serverimplementierungen Probleme machten. Das heutige Sicherheitsupdate behandelt andere Fehler. Die Betriebslehre ist dieselbe: Ein grüner Reverse Proxy ist kein semantischer End-to-End-Test.

Gegenposition: Sind schnelle Updates bei offenen Details zu riskant?

Eine faire Gegenposition lautet: Ohne öffentliches Advisory lässt sich die eigene Betroffenheit nicht präzise bestimmen. Ein übereiltes Update eines kleinen Community-Projekts könne selbst Ausfälle oder Interoperabilitätsprobleme erzeugen. Wer im Juli den Continuwuity-Invite-Vorfall erlebt hat, nimmt dieses Risiko zu Recht ernst.

Die Unsicherheit ist real. Sie spricht für Backup, feste Paketquelle, stabilen Zielstand und Abnahmetests. Sie spricht nicht für Nichtstun. Das Projekt nennt mit Kontoübernahme und Föderationsdatenabfluss ernste Folgen, stuft eine Schwachstelle als hoch ein und fordert zum schnellen Update auf. Mehr Präzision kann später mit dem öffentlichen Advisory kommen; die betriebliche Priorität ist heute schon klar.

Auch der Sprung auf 26.8.0-alpha.1 wäre keine saubere Abkürzung. Eine Vorabversion vergrößert den Änderungsraum. Solange keine neuere stabile Empfehlung vorliegt, ist 26.7.3 der belegte stabile Sicherheitspfad.

Bewertung: Souveränität ist Wartungsfähigkeit

Meine redaktionelle Bewertung: Freie Software verhindert keine Sicherheitslücken. Ihr Vorteil liegt darin, dass Warnung, Release, Tag, Quellvergleich, Dokumentation und Auslieferungswege öffentlich geprüft werden können. Betreiber besitzen eine reale Entscheidungsmöglichkeit.

Diese Möglichkeit wird aber erst zur Souveränität, wenn eine Community sie organisatorisch tragen kann. Wer Sicherheitsmeldungen nicht sieht, Spiegelstände nicht prüft, Backups nie wiederherstellt und nach dem Neustart keine Nutzerwege testet, besitzt zwar den Server, aber nicht den verlässlichen Betrieb.

Die Machtfrage ist deshalb auch eine Ressourcenfrage. Kleine freie Infrastruktur braucht Zeit für Pflege, verständliche Dokumentation und gemeinschaftlich verteiltes Betriebswissen. Sonst wird Selbsthosting zur unbezahlten Dauerbereitschaft einzelner Personen, während große Plattformen ihre Abhängigkeit als Bequemlichkeit verkaufen.

Fazit

Continuwuity 26.7.3 ist ein dringendes stabiles Sicherheitsupdate, kein Feature-Hype. Belegt sind zwei Korrekturen: die Offenlegung bestimmter Ereignisse über Föderation und eine mögliche Kontoübernahme unter bestimmten Bedingungen. Besonders hervorgehoben werden Installationen mit SMTP. Nicht belegt sind derzeit genaue Angriffsvoraussetzungen, eine vollständige Versionsmatrix, CVE/CVSS/CWE oder aktive Ausnutzung.

Die richtige Reaktion ist weder Panik noch Abwarten: Quelle klären, Backup und Restore-Pfad sichern, stabilen Zielstand einspielen, Laufzeitversion prüfen und die entscheidenden Nutzerwege abnehmen. Direkt vor einer Veröffentlichung müssen das GHSA und der dann aktuelle stabile Patchstand erneut geprüft werden.