Betreiber selbst gehosteter Nextcloud-Instanzen sollten den Einsatz der App Collabora Online – Built-in CODE Server jetzt eindeutig erfassen. In CVE-2026-110447 steckt eine OS-Command-Injection, durch die eine Anfrage einen Betriebssystembefehl mit den Rechten des Webserver-Benutzers ausführen kann. CISA hat die Schwachstelle am 23. Oktober in den Katalog bereits ausgenutzter Schwachstellen aufgenommen.

Die Abgrenzung verhindert zwei gefährliche Fehlannahmen: Eigenständige Collabora-Online-Server sind laut Hersteller nicht betroffen. Für die betroffene Nextcloud-App genügt es umgekehrt nicht, sie nur zu deaktivieren. Sie muss auf mindestens 26.4.303 aktualisiert oder entfernt werden.

Wichtige Punkte auf einen Blick
  • Aktive Ausnutzung ist der Prioritätsfaktor: CISA führt CVE-2026-110447 seit dem 23. Oktober 2026 im KEV-Katalog. Das ist ein Anlass für eine zeitnahe technische Prüfung, nicht für die nächste Routinewartung.
  • Betroffen ist eine bestimmte Betriebsart: Die Schwachstelle liegt in richdocumentscode, der Nextcloud-App „Collabora Online – Built-in CODE Server“, vor Version 26.4.303. Ein externer, eigenständiger Collabora-Server gehört nicht zu diesem Scope.
  • Ein Neustart kann relevant sein: Der dokumentierte Angriffspfad besteht nur, solange der eingebaute CODE Server nicht läuft – etwa nach Neustart, Update oder Absturz.
  • Deaktivieren ist keine Abhilfe: Collabora verlangt ein Upgrade auf mindestens 26.4.303 oder die Entfernung der App. Ein früherer Fix für CVE-2025-66208 behebt diesen separaten Pfad nicht.
  • Forensik gehört zur Entscheidung: CISA markiert den Eintrag mit „Forensic Triage: Yes“. Bei Hinweisen auf eine Ausnutzung sollten Teams Nachweise sichern und die Reichweite prüfen, statt nur den Patch einzuspielen.

Warum die Meldung jetzt zählt

Der CISA-KEV-Katalog ist kein allgemeines CVE-Verzeichnis. Eine Aufnahme bedeutet, dass der Behörde eine Ausnutzung in der Praxis bekannt ist. Für US-Bundesbehörden ist die im Katalog genannte Frist bindend; sie ist keine unmittelbare Frist für deutsche Unternehmen. Als Risikoindikator bleibt die Aufnahme dennoch relevant: Sie hebt die Lücke aus der Masse theoretischer Schwachstellen heraus und rechtfertigt eine priorisierte Prüfung.

Die NVD beschreibt die Ausnutzung der Lücke im September und Oktober 2026. Entscheidend ist deshalb nicht, ob eine Organisation „Collabora“ allgemein verwendet. Entscheidend ist, ob auf einer eigenen Nextcloud-Instanz die konkrete App richdocumentscode installiert ist und welche Version tatsächlich betrieben wird.

Betroffene Architektur präzise abgrenzen

Die Herstellerberatung benennt ausdrücklich die Nextcloud-App Collabora Online – Built-in CODE Server. Diese Komponente bringt einen CODE-Server direkt in die Nextcloud-Installation. Betroffen sind Releases vor 26.4.303. Der Artikel bezieht sich nicht auf einen separat betriebenen Collabora-Online-Server, denn diese Betriebsart ist laut Collabora von CVE-2026-110447 nicht betroffen.

Diese Unterscheidung ist operativ wichtig. Ein externer Collabora-Service kann andere Sicherheitsaufgaben haben, gehört aber nicht automatisch zu diesem CVE. Umgekehrt darf ein Team eine betroffene eingebaute Komponente nicht übersehen, nur weil sie unter der Bezeichnung „Office-Integration“ oder „Dokumentbearbeitung“ geführt wird. Prüfen Sie Inventar, App-Verwaltung, Paketierung und Deployment-Manifeste auf richdocumentscode.

Separater Fix, separater Prüfpunkt.

Collabora stellt klar, dass CVE-2026-110447 nicht derselbe Angriffspfad wie CVE-2025-66208 ist. Ein bereits dokumentiertes Update für die ältere Schwachstelle darf daher nicht als Nachweis für diese Abhilfe gelten.

Die technische Bedingung: Der eingebaute CODE Server läuft nicht

Nach der Collabora-Beratung sitzt die Schwachstelle in proxy.php. Eine Anfrage kann einen Betriebssystembefehl mit den Rechten des Webserver-Benutzers ausführen. Der beschriebene Pfad funktioniert, wenn der integrierte CODE Server nicht läuft. Als Beispiele nennt der Hersteller einen Container- oder Serverneustart, ein Upgrade oder einen Absturz.

Das ist keine Entwarnung durch vermeintliche Verfügbarkeit. Gerade nach einer Wartung oder einem ungeplanten Ausfall kann ein Dienst für kurze Zeit in einem anderen Zustand laufen als im normalen Betrieb. Die passende Maßnahme ist deshalb weder ein manueller Verfügbarkeitscheck noch eine dauerhafte Sonderkonfiguration, sondern die vom Hersteller bereitgestellte korrigierte App-Version beziehungsweise die Entfernung der App.

Sechs kontrollierte Maßnahmen für den Betrieb

  1. Betroffene Instanzen vollständig erfassen. Listen Sie alle selbst betriebenen Nextcloud-Umgebungen auf – inklusive Admin-, Test-, Staging-, Wiederanlauf- und Mandanteninstanzen. Halten Sie pro Instanz fest, ob richdocumentscode installiert ist und ob ein eingebauter oder separater Collabora-Server verwendet wird.
  2. App- und Deployment-Version nachweisen. Prüfen Sie die tatsächlich auf dem Server beziehungsweise im Container ausgerollte Version, nicht nur den Stand eines Repositorys oder einer Dokumentation. Der feste Zielstand lautet 26.4.303 oder höher.
  3. Über den unterstützten Weg aktualisieren. Planen Sie das Upgrade nach Ihrem Change-Prozess, sichern Sie den Ausgangsstand und verifizieren Sie danach die aktive App-Version. Ein erfolgreich gestarteter Update-Job ist nicht automatisch ein Beleg, dass jede produktive Instanz den Zielstand erreicht hat.
  4. Wenn ein Update nicht möglich ist: App entfernen. Laut Collabora reicht das Deaktivieren nicht aus, um den dokumentierten Angriffspfad zu vermeiden. Ist kein Upgrade auf mindestens 26.4.303 möglich, muss die App entfernt werden. Prüfen Sie vorher die betrieblichen Folgen für die Browser-Dokumentbearbeitung.
  5. End-of-Life-Nextcloud nicht als Dauer-Ausnahme behandeln. Für Nextcloud bis einschließlich Version 29 empfiehlt Collabora ein Upgrade der Nextcloud-Installation oder die Entfernung der App. Dokumentieren Sie für veraltete Plattformen einen verbindlichen Migrations- oder Abschaltpfad.
  6. Nachweis und Monitoring ergänzen. Erfassen Sie Zeitpunkt, Instanz, Ausgangs- und Zielversion sowie Ergebnis der Funktionsprüfung. Da CISA den KEV-Eintrag mit forensischer Triage kennzeichnet, sollten Webserver-, Reverse-Proxy- und Prozessprotokolle nach lokalem Aufbewahrungsplan verfügbar und gegen Manipulation geschützt sein.

Bei Ausnutzungsverdacht: Erst eingrenzen, dann belastbar bereinigen

Ein Update beendet die bekannte Schwachstelle, entfernt aber nicht automatisch Folgen einer früheren Ausnutzung. Bestehen Anzeichen für ungewöhnliche Aktivitäten im Kontext einer betroffenen Instanz, sollte der bestehende Incident-Response-Prozess starten. Sichern Sie zunächst die verfügbaren Webserver-, Proxy-, Authentifizierungs- und Prozessdaten sowie die relevanten Zeitstempel. Ordnen Sie diese Daten besonders rund um Neustarts, Upgrades und Störungen ein, weil der Hersteller den Angriffspfad an den nicht laufenden CODE Server knüpft.

Danach folgt die Reichweitenanalyse: Welche Instanz, welcher Webserver-Benutzer und welche angebundenen Systeme oder Zugangsdaten liegen im tatsächlichen Berechtigungsbereich? Erst wenn diese Fragen nachvollziehbar beantwortet sind, können Teams entscheiden, ob Zugangsdaten rotiert, Systeme neu aufgebaut oder weitere Melde- und Eskalationswege erforderlich sind. Bei einem bestätigten Vorfall sollten interne Verantwortliche, Incident-Response-Partner und gegebenenfalls zuständige Stellen früh eingebunden werden.

Quellen & Weiterführende Nachweise