Le proxy.php du serveur CODE intégré de Collabora laisse exécuter des commandes sur les Nextcloud exposés
Le 14 octobre 2026, la CVE-2026-110447 documente une injection de commandes non authentifiée dans proxy.php de l’application Collabora Online Built-in CODE Server de Nextcloud, exploitée depuis septembre pour déposer des web shells PHP. Mettez à jour vers la version 26.4.303 et chassez les fichiers shx*.php, car le correctif ne supprime pas les coquilles déjà posées.
11 septembre 2026. Collabora publie la version 26.4.303 de son application Built-in CODE Server pour Nextcloud, qui corrige une injection de commandes dans proxy.php. 3 octobre 2026. Le forum d’aide de Nextcloud prévient que la faille est déjà exploitée et que des utilisateurs ont trouvé des web shells sur leurs instances. 14 octobre 2026. La CVE-2026-110447 est publiée, cotée CVSS 4.0 9.2 (critique), sans privilège requis. Le point qui compte : l’exécution de code est non authentifiée, et le correctif ne fait pas disparaître les coquilles déjà déposées sur les serveurs compromis.
Une faille dans un composant optionnel que presque personne ne surveille
La CVE-2026-110447 ne touche pas Nextcloud lui-même, mais une application optionnelle de son écosystème : Collabora Online Built-in CODE Server, dont le paquet porte le nom richdocumentscode. Cette application a une particularité : elle télécharge et exécute un CODE complet — le serveur d’édition bureautique de Collabora, dérivé de LibreOffice — sous forme d’AppImage locale, pour éviter d’avoir à déployer un serveur séparé.
La faille est une injection de commandes système dans proxy.php, le script qui relaie les requêtes vers le serveur CODE. Le scénario d’exploitation est précis : quand le serveur CODE n’est pas en cours d’exécution — typiquement juste après un redémarrage, avant que l’AppImage n’ait fini de démarrer — une requête non authentifiée vers /apps/richdocumentscode/proxy.php?status peut faire exécuter une commande système par le serveur web. Les opérateurs ont signalé des web shells PHP écrits sous l’arborescence de l’application, sous des noms correspondant à shx*.php.
Le point aveugle est là : richdocumentscode est un composant de confort — il embarque une suite bureautique entière pour épargner une installation séparée — mais il hérite de toute la surface d’attaque d’un serveur d’édition de documents, sans que personne ne le traite comme tel. Les installations qui utilisent le simple connecteur richdocuments sans richdocumentscode, ou qui font tourner Collabora via Docker, un paquet de distribution ou un service hébergé, ne sont pas concernées. Le problème est spécifique à l’AppImage intégrée.
Une exploitation silencieuse, des coquilles qui survivent au correctif
Le calendrier raconte une exploitation qui a précédé la publicité. Des opérateurs ont signalé des compromissions dès septembre 2026, avec des web shells déposés après des requêtes vers l’endpoint proxy.php?status. Le 3 octobre, le forum d’aide de Nextcloud confirmait que l’injection était déjà exploitée et que des utilisateurs avaient découvert des coquilles. La CVE n’a été publiée que le 14 octobre — et GitHub a publié la version corrigée 26.4.303 dès le 11 septembre, ce qui signifie que la fenêtre entre le correctif et la divulgation publique a laissé plusieurs semaines de visibilité aux attaquants.
La conséquence pratique est sévère pour la remédiation : mettre à jour vers 26.4.303 ne supprime pas les web shells déjà déposés. Un attaquant qui a posé shx*.php avant le correctif conserve son accès après la mise à niveau. La remédiation de Collabora le dit explicitement : montez en version et supprimez les fichiers PHP inattendus sous le répertoire de l’application. Une instance compromise doit être traitée comme non fiable : rotation des identifiants, revue des journaux web à la recherche d’abus de proxy.php, et reconstruction depuis des sauvegardes saines.
Le 24 octobre, la CISA a signalé la faille comme activement exploitée, aux côtés d’une vulnérabilité distincte chez Arista VeloCloud. Le signal change alors de nature : il ne s’agit plus d’une faille théorique à corriger, mais d’une campagne en cours qu’il faut traiter comme un incident, pas comme un simple ticket de correctif.
Ce qu’un défenseur doit chercher
Les indicateurs publiés par les équipes de détection — SentinelOne notamment — sont précis et faciles à industrialiser :
- des requêtes HTTP vers
proxy.phpdans le chemin derichdocumentscode, contenant des métacaractères de shell :;,|,`,$(),&&; - des processus enfants inattendus lancés par le travailleur PHP ou l’utilisateur du serveur web, en particulier des interpréteurs (
sh,bash) et des utilitaires réseau (curl,wget,nc) ; - des connexions sortantes depuis l’hôte Nextcloud vers des destinations inhabituelles ;
- la présence de fichiers PHP inconnus sous le répertoire de l’application, notamment les motifs
shx*.php.
Ces indicateurs partagent une caractéristique : ils détectent le comportement, pas la signature d’un binaire. C’est cohérent avec la nature de l’attaque — une injection de commandes laisse peu de traces statiques, mais beaucoup de traces comportementales : un serveur web qui enfante un shell est toujours anormal.
La leçon dépasse Nextcloud
La CVE-2026-110447 illustre un coût caché des « applications tout-en-un ». richdocumentscode existe pour simplifier le déploiement : un clic dans l’App Store de Nextcloud, et vous avez une suite bureautique complète sans gérer un second service. Ce confort a un prix — une AppImage de serveur d’édition, avec son propre point d’entrée proxy.php, exposée sur l’Internet. Ce n’est pas un hasard si les installations qui déploient Collabora en Docker ou via un paquet de distribution sont épargnées : elles n’embarquent pas ce proxy dans le même contexte que Nextcloud.
Pour un RSSI, la règle pratique est simple : chaque application « intégrée » qui embarque un service complet ajoute la surface d’attaque de ce service, pas seulement celle d’un greffon. La question n’est pas « est-ce que j’utilise Collabora », mais « est-ce que richdocumentscode est installé et exposé ». Beaucoup d’instances Nextcloud l’ont activé pour un essai, puis oublié — c’est précisément le profil que cette campagne a ciblé.
Verdict
Si vous faites tourner richdocumentscode sur un Nextcloud accessible depuis Internet, montez en version 26.4.303 immédiatement, puis traitez la chasse comme une priorité distincte : recherchez les fichiers shx*.php et tout PHP inattendu sous le répertoire de l’application, et considérez l’hôte comme compromis tant que vous n’avez pas écarté la présence d’un web shell. Si vous n’avez pas besoin du CODE intégré, désinstallez richdocumentscode et basculez vers un Collabora autonome en Docker ou via un paquet de distribution — vous supprimez la faille avec le composant. La CVE-2026-110447 est un rappel chiffré : un correctif ne vaut rien contre une coquille déjà posée, et un composant optionnel oublié reste une porte d’entrée aussi réelle qu’un service principal.
Références
- NVD — CVE-2026-110447, Collabora Online Built-in CODE Server command injection
- CollaboraOnline/richdocumentscode — issue #354 (advisory et signalements de web shells)
- Nextcloud Help Forum — To Collabora Built-in users: update ASAP (3 octobre 2026)
- The Hacker News — CISA Flags Two Actively Exploited Critical Flaws in Collabora Online and Arista VeloCloud (24 octobre 2026)
- SentinelOne — CVE-2026-110447, Collabora Online CODE Server RCE Vulnerability