L’application Nextcloud qui démarre Collabora lance une commande tant que l’éditeur est arrêté

Le 14 octobre 2026, Collabora a publié GHSA-g3vx-3m76-fghh pour CVE-2026-110447. Une requête vers un fichier PHP d’une application Nextcloud facultative peut lancer une commande du système d’exploitation, avec le compte du serveur web. Le lendemain, BleepingComputer rapportait que la faille servait depuis le 10 septembre à déposer des shells PHP sur des serveurs Nextcloud. Ce texte explique le mécanisme derrière ce titre : quel programme écoute vraiment, pourquoi la ligne dangereuse ne s’exécute que lorsque ce programme est arrêté, et pourquoi désactiver l’application ne ferme pas le trou.

La faille n’est pas dans Collabora Online installé comme serveur séparé. Les images Docker, les paquets RPM et DEB, et Nextcloud All-in-One sont en dehors. Un Nextcloud qui a l’application bureautique et qui la pointe vers un serveur Collabora installé à part l’est aussi.

Deux applications qui partagent un nom

La bureautique dans le navigateur, chez Nextcloud, ce sont deux applications.

Nextcloud Office est l’application dont le dossier s’appelle richdocuments. C’est la partie que les gens voient. Elle parle à un éditeur avec WOPI, le Web Application Open Platform Interface : Nextcloud garde le fichier et émet un jeton de courte durée, et l’éditeur va chercher les octets avec ce jeton. Nextcloud est l’hôte. L’éditeur est un autre processus.

Collabora Online - Built-in CODE Server est l’application dont le dossier s’appelle richdocumentscode. CODE veut dire Collabora Online Development Edition. Le README de l’application la décrit comme un serveur intégré pour un usage personnel ou une petite équipe, plus lent qu’un Collabora séparé, et sans les fonctions de montée en charge de celui-ci. Elle télécharge une AppImage, un seul fichier qui contient l’éditeur et ses bibliothèques, et elle lance ce fichier sur la même machine que Nextcloud. Le processus à l’intérieur s’appelle coolwsd. La version ARM64 est une autre application, richdocumentscode_arm64. L’application x86_64 refuse le reste : sa vérification renvoie not_x86_64 quand php_uname dit que la machine n’est pas x86_64, not_linux hors de Linux, appimage_missing quand le fichier n’est pas là, et no_fontconfig quand le cache de l’éditeur de liens dynamique n’a pas fontconfig. Elle refuse aussi un système musl. La vérification lance l’AppImage avec LD_TRACE_LOADED_OBJECTS, ce qui affiche les bibliothèques qu’un chargeur glibc tirerait, et elle traite un échec comme no_glibc.

C’est toute l’installation concernée. Un site qui n’a que richdocuments, et un site dont l’éditeur est un conteneur ou un paquet de distribution, n’a pas ce fichier PHP.

proxy.php est un relais, et c’est aussi lui qui démarre l’éditeur

Le fichier est apps/richdocumentscode/proxy.php. Le serveur web l’exécute comme n’importe quel autre fichier PHP d’un répertoire qu’il a le droit d’exécuter. The Hacker News, en lisant le script, note qu’il ne charge pas Nextcloud. Rien dans la requête n’a à être un utilisateur Nextcloud connecté. Le score de l’avis correspond : aucun privilège requis, aucune interaction d’un utilisateur.

Le script publié accepte deux formes de requête. status demande si l’éditeur est démarré. req= suivi d’un chemin est une requête de document, et le chemin doit commencer par /. Pour une requête de document, le script ouvre une socket TCP vers localhost, port 9983, avec un délai de trois secondes, et il écrit la requête dans cette socket. La réponse revient par le même chemin. Le port 9983 est aussi celui de la ligne de commande coolwsd qu’un administrateur a collée dans le rapport public. Le « relais » est ce tuyau écrit à la main. Il n’y a pas de relais inverse général dans le fichier.

Si cette socket ne se connecte pas, et que la vérification du système passe, et que coolwsd ne tourne pas déjà, le script le démarre. Une requête status prend la même branche. Les requêtes qu’un hébergeur a collées le 11 septembre étaient des requêtes status. Une fois la socket ouverte, une requête suivante ne construit pas de commande de démarrage. Elle ne fait que transmettre.

Le démarrage est sérialisé avec un fichier verrou ouvert en création exclusive. Un verrou dont le ctime a plus de cinq minutes est effacé d’abord, pour qu’un démarrage planté ne bloque pas le suivant pour toujours. Le fichier de pid est retiré avant le lancement du nouveau processus, puis le script attend que la socket locale réponde et efface le verrou. Ce verrou sert à empêcher deux requêtes de démarrer deux éditeurs. Ce n’est pas un contrôle d’authentification.

Où la requête est devenue une commande shell

La classe du bogue est CWE-78 : une commande du système d’exploitation qui contient du texte fourni par l’auteur de la requête.

Un exec PHP sur une seule chaîne donne cette chaîne à un shell. The Hacker News, en comparant les versions, écrit que jusqu’à 26.4.302 la commande de démarrage était construite ainsi, et que le texte de la requête, y compris le chemin, se trouvait entre guillemets doubles. Les guillemets doubles de bash suppriment le découpage en mots et le globbing. Ils ne suppriment pas la substitution de commande. Une substitution dans la requête s’exécutait avec le compte du serveur web, et seulement sur cette branche de démarrage. L’avis dit la même limite en une phrase : la commande ne peut partir que pendant que le serveur CODE intégré n’est pas déjà en marche.

La copie de proxy.php sur la branche publique actuelle ne construit plus cette chaîne pour exec. Elle construit une liste d’arguments et la passe à proc_open : bash, -c, un script, le chemin de l’AppImage, puis les options. Une liste d’arguments n’est pas analysée comme de la syntaxe shell. The Hacker News décrit le changement comme quatre lignes, déposées avec le message « tidy up how the coolwsd launch command is built », écrites par Caolán McNamara le 20 août 2026. Elles n’étaient pas dans 26.4.302, sorti le 31 août. Elles ont été committées le 9 septembre. La version 26.4.303, qui contient le changement, est sortie le 11 septembre. Les notes de version nommaient la version CODE empaquetée. Elles ne disaient pas que cette version était un correctif de sécurité. Une personne qui lisait le rapport le 30 septembre disait la même chose : les notes n’en mentionnaient pas.

La vérification du système, dans le fichier actuel, appelle encore exec, deux fois, pour la sonde glibc et la sonde fontconfig. Ces chaînes sont écrites dans le script. Elles ne sont pas la requête. Le bogue, c’était la requête qui faisait partie de la commande de démarrage.

Un éditeur arrêté est un moment normal

Un serveur qui tourne depuis des semaines ne prend pas la branche de démarrage. La fenêtre s’ouvre quand rien n’écoute sur ce port local, ou quand le script décide que le processus qui écoute est la mauvaise build.

La vérification de build est un condensé. Quand l’application est empaquetée, un condensé du coolwsd inclus est écrit dans le PHP. Sur une requête status, si la socket se connecte, le script va chercher http://localhost:9983/hosting/capabilities et lit productVersionHash. Si les deux condensés diffèrent, il envoie SIGTERM au processus en cours, attend jusqu’à dix secondes, et en démarre un nouveau si le port est encore fermé. Une mise à jour remplace le PHP et l’AppImage ensemble, donc le nouveau PHP voit l’ancien processus, les condensés diffèrent, et la branche de démarrage s’exécute. Un plantage, un redémarrage, ou un hôte qui a arrêté le processus font la même chose sans différence de condensé. Le champ attack requirements de l’avis, AT:P, est cette condition : le serveur intégré doit être arrêté, ou sur le point d’être remplacé.

Les premières requêtes qu’un hébergeur a journalisées datent du 10 septembre, le lendemain du commit du correctif et la veille de la publication de 26.4.303. Ces serveurs étaient en 26.4.302. L’avis du secteur santé français dit que l’exploitation a été confirmée sur cette version, et que la faille est exploitée.

Ce qui se trouvait ensuite sur les serveurs

Le rapport est le ticket 354 de CollaboraOnline/richdocumentscode, ouvert le 11 septembre par un hébergeur qui fait tourner plusieurs serveurs Nextcloud. Les requêtes ont créé des fichiers PHP dans le répertoire de l’application. Les noms suivaient un motif que Michael Meeks a ensuite dit aux gens de supprimer : shx, puis d’autres caractères, avec le suffixe .php. Ces fichiers étaient des shells web. À partir de là, rapporte BleepingComputer, les intrus ont cherché sur le serveur des bases de mots de passe, des fichiers de gestionnaires de mots de passe, et des portefeuilles de cryptomonnaie.

Un administrateur, le 14 septembre, après le passage à 26.4.303, a collé une liste de processus qui contenait encore la requête malveillante. Elle se trouvait dans une option de coolwsd, remote_font_config.url. La réponse de Meeks : la liste a l’air alarmante et devrait être sans effet une fois les fichiers PHP en trop retirés. L’option pointe l’éditeur vers une configuration de polices qui n’est pas un vrai serveur. La même liste montrait coolwsd démarré avec security.capabilities et security.seccomp à false, et les processus enfants démarrés avec --nocaps et --noseccomp. C’est une propriété du lancement que cet hôte a vu. C’est aussi une raison de ne pas prendre « Collabora isole les documents » pour une description de cette application. La commande que le bogue exécute est le processus PHP du serveur web, qui est de toute façon en dehors de coolwsd.

Le même rapport demande si une requête atteignait encore proxy.php d’une application qui avait été désactivée. L’avis répond à la version pratique de cette question. Désactiver l’application dans les réglages de Nextcloud ne retire pas le fichier, et le serveur web ne demande pas à Nextcloud si l’application est activée avant d’exécuter un fichier PHP. Le correctif, c’est de mettre l’application à jour vers 26.4.303 ou plus récent, ou de la retirer. Nextcloud 29 et les versions plus anciennes sont en fin de vie, et l’avis dit que ces installations doivent mettre Nextcloud à jour ou retirer l’application.

Un autre administrateur s’en est aperçu le 18 septembre parce que le serveur a envoyé un courriel au sujet de tentatives sudo refusées. Le courriel ne dit pas quel compte a lancé sudo. Ce que le compte du serveur web peut faire sans sudo suffit déjà : il peut lire le config/config.php de Nextcloud, là où vivent le mot de passe de la base de données et le secret de l’instance, et il peut lire le répertoire de données que le serveur garde pour les utilisateurs. Un shell qui n’a jamais atteint root avait quand même ces fichiers.

Le 29 septembre, un commentaire sur le même ticket disait que des opérateurs de rançongiciels avaient commencé à utiliser le bogue la semaine précédente. BleepingComputer a demandé et n’a pas pu confirmer un déploiement de rançongiciel. Les deux phrases ont leur place. Aucune des deux n’est un nombre de serveurs victimes. Personne qui a publié là-dessus n’en a donné un.

9,2 et 9,8 sont deux échelles, pas deux mesures

L’avis de Collabora le note CVSS 4.0 à 9,2 :

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Réseau, complexité faible, aucun privilège, aucun clic, impact élevé sur la confidentialité, l’intégrité et la disponibilité du système vulnérable, aucun impact noté sur un système suivant. Le AT:P est la condition du serveur arrêté. CVSS 4.0 a ajouté ce champ pour qu’une condition préalable puisse baisser le score sans faire semblant que l’attaque est compliquée.

L’avis du secteur santé français, sur cyberveille.esante.gouv.fr, note le même CVE à 9,8 sur l’échelle CVSS 3.1, et dit que l’exploitation a été confirmée contre 26.4.302. CVSS 3.1 n’a pas de champ pour les conditions d’attaque. Une attaque réseau, sans privilège, avec un impact élevé sur les trois volets, tombe à 9,8 que l’éditeur doive être arrêté ou non. Les deux nombres sont publiés. Ils ne sont pas un désaccord sur la gravité d’un shell. Ils sont un désaccord sur le fait que le score doive mentionner la condition.

Ce n’est pas non plus le bogue de l’an dernier dans le même fichier. CVE-2025-66208 est une injection de commande dans proxy.php qui dépend d’un relais inverse faisant confiance à X-Forwarded-Host. Collabora a corrigé celui-là dans 25.04.702, le 3 décembre 2025, et a dit qu’une installation par défaut typique n’était pas touchée. L’avis actuel dit que ce correctif n’arrête pas CVE-2026-110447. Corriger le bogue de 2025 et rester en 26.4.302 laisse celui-ci en place.

Le correctif est sorti le 11 septembre. Le CVE est daté du 14 octobre.

La chronologie publique, à partir du dépôt, du rapport, du billet du 15 octobre de Collabora, et des deux articles :

• 20 août. Le rangement de la commande de lancement est écrit, selon The Hacker News. Il n’est pas étiqueté comme un correctif de sécurité.
• 31 août. 26.4.302 sort, sans ce changement. C’est la version que les attaques de septembre ont touchée.
• 9 septembre. Le changement est committé.
• 10 septembre. Les journaux de l’hébergeur montrent les premières requêtes réussies. Les serveurs sont en 26.4.302.
• 11 septembre. 26.4.303 sort, et l’hébergeur ouvre le ticket 354. Dans le fil, Meeks écrit que cela touche la Development Edition, et seulement le mode qui télécharge une AppImage locale. Il pointe un billet de GitHub sur le retard de la base d’avis.
• 14 septembre. Meeks confirme que 26.4.303 est la version corrigée et dit aux gens de retirer les fichiers shx*.php qui restent. Le même jour, un administrateur demande si des requêtes atteignaient encore proxy.php après la désactivation de l’application.
• 18 septembre. Un courriel de sudo refusé est la façon dont le propriétaire d’un autre serveur s’en est aperçu.
• 29 septembre. Un commentaire demande un CVE et dit que des opérateurs de rançongiciels avaient commencé à s’en servir. Cette seconde affirmation est celle que BleepingComputer n’a pas pu confirmer.
• 30 septembre. Un lecteur signale que les notes de 26.4.303 ne mentionnent pas de correctif de sécurité.
• 2 octobre. Quelqu’un publie la comparaison de 26.4.302 et de 26.4.303.
• 3 octobre. Un fil du forum Nextcloud prévient les utilisateurs du CODE intégré que le bogue est déjà utilisé et qu’aucun CVE n’existe encore.
• 14 octobre. L’avis et CVE-2026-110447 sont publiés. Caolán McNamara ferme le ticket avec un lien vers l’avis.
• 15 octobre. Le billet de Collabora, et l’article de BleepingComputer.

Le récit de Collabora sur cet écart, c’est la paperasse du CVE. Ils disent que l’attribution par GitHub, qui prenait environ un jour, prenait plusieurs semaines, et que les rapports reçus cette année étaient de l’ordre de dix ans de leur volume précédent, ce qu’ils attribuent à des rapports produits avec l’IA. Ils disent demander à devenir une autorité de numérotation CVE pour pouvoir attribuer les numéros eux-mêmes. Ils disent aussi que l’application intégrée n’est pas l’installation qu’ils recommandent, qu’elle est une minorité des utilisateurs de Nextcloud, et qu’aucun client Collabora Online n’a été touché. Ils remercient Nextcloud et disent que la personne qui a signalé le bogue sera créditée. The Hacker News, en lisant l’avis, dit que ce crédit est l’utilisateur GitHub wwwshellcodeit. Ni l’avis ni le fil du ticket ne disent quand le signalement est arrivé.

Le récit de Nextcloud, donné à BleepingComputer, est différent. Ils ont dit que Collabora avait signalé le bogue à la mi-septembre, que la mise à jour était déjà dans la boutique d’applications, que la divulgation avait attendu pour laisser le temps de mettre à jour, et que Nextcloud n’avait pas vu d’exploitation généralisée.

Les deux récits peuvent être des choses que les organisations croient. Le ticket public reste la partie qu’un lecteur peut vérifier. Depuis le 11 septembre, un hébergeur décrivait des serveurs compromis sur la version d’avant le correctif. Depuis le 14 septembre, un mainteneur de Collabora disait que 26.4.303 était le correctif. L’identifiant CVE n’existait pas avant le 14 octobre.

BleepingComputer cite Second Security sur un motif plus large : le délai médian entre un correctif public et un CVE était de 39 jours en août 2026, contre 5,1 jours en janvier, et le code d’exploitation public apparaissait souvent dans les heures suivant un correctif et des jours avant le CVE. C’est la mesure de Second Security, telle que rapportée par BleepingComputer. C’est le contexte dans lequel s’inscrit le mois de Collabora, pas un chiffre tiré des journaux de Collabora.

Landlock est arrivé dans la même mise à jour, et ce n’est pas ce correctif

Le billet du 15 octobre de Collabora dit que passer à une version actuelle apporte aussi Landlock, un module de sécurité Linux qui permet à un processus de se limiter à une liste de fichiers. Ils appellent cela un avantage supplémentaire de la mise à jour. Ils n’appellent pas cela le correctif de CVE-2026-110447.

Ce serait la mauvaise couche même s’il avait été là plus tôt. Landlock s’applique à un processus qui s’y inscrit, ou à un superviseur qui y place un processus. L’injection de commande s’exécute dans l’interpréteur PHP, avec l’utilisateur du serveur web, au moment où cet interpréteur décide de démarrer coolwsd. Un bac à sable autour de l’éditeur commence plus tard, et seulement autour de l’éditeur. La liste de processus du 14 septembre est l’illustration : les métacaractères du shell étaient déjà dans la ligne de commande de l’éditeur, parce qu’ils avaient fait partie de la chaîne qui l’a lancé.

Si cette application est sur un serveur que vous tenez

1. Dans la liste des applications de Nextcloud, cherchez Collabora Online - Built-in CODE Server, y compris la variante ARM64. Si la version est inférieure à 26.4.303, mettez-la à jour ou retirez-la. Si le Nextcloud lui-même est en version 29 ou plus ancienne, l’avis dit de mettre Nextcloud à jour ou de retirer l’application. Éteindre l’application dans le menu laisse proxy.php sur le disque.
2. Si cette application a été installée en dessous de 26.4.303 à un moment quelconque depuis le 10 septembre, regardez dans apps/richdocumentscode/ s’il y a des fichiers PHP qui n’appartiennent pas à l’application. Le motif de nom que Meeks a dit aux opérateurs de retirer est shx*.php. Une mise à jour n’efface pas un fichier qu’un intrus a déjà écrit.
3. Dans le journal d’accès du serveur web, cherchez des requêtes vers proxy.php dont le chemin n’est pas le chemin normal de l’application, et des requêtes status que vous n’avez pas envoyées. Une ligne est une raison de faire la vérification des fichiers. Ce n’est pas, à lui seul, la preuve que la branche de démarrage a tourné.
4. Si un shell était là, faites tourner les secrets que le compte du serveur web pouvait lire. Cela comprend le mot de passe de la base de données et le secret de l’instance dans config/config.php, et les identifiants de tout le reste que cet utilisateur pouvait ouvrir. Effacer le fichier PHP ne désapprend pas un fichier que le shell a déjà ouvert.
5. Pour des documents dans le navigateur ensuite, les installations que Collabora recommande sont un serveur séparé : leur image Docker, un paquet de distribution, ou Nextcloud All-in-One. Ce sont les installations que ce CVE ne couvre pas.

Sources (en anglais) :

• GHSA-g3vx-3m76-fghh, Collabora, 14 octobre 2026.
• Stay safe: upgrade everything regularly, Collabora, 15 octobre 2026.
• Ticket 354 de richdocumentscode, ouvert le 11 septembre 2026.
• Comparaison de 26.4.302 et de 26.4.303.
• To Collabora built-in user: update ASAP, forum Nextcloud, 3 octobre 2026.
• Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers, Bill Toulas, BleepingComputer, 15 octobre 2026.
• Hackers backdoor Nextcloud servers, The Hacker News, octobre 2026.
• GHSA-f97p-r72q-64h2, GitHub Advisory Database.
• Avis du CERT Santé, 14 octobre 2026.