CVE-2026-110447 est une injection de commande du système d'exploitation (OS command injection, CWE-78) dans proxy.php du paquet richdocumentscode, l'application optionnelle « Collabora Online, Built-in CODE Server » de Nextcloud. Elle permet l'exécution de code à distance et a été exploitée dans la nature en septembre et octobre 2026, avec dépôt de portes dérobées web (webshells) sur les serveurs touchés. Collabora a corrigé le défaut en version 26.4.303, publiée le 11 septembre 2026, et a publié son avis de sécurité le 14 octobre 2026, date que porte également l'enregistrement de la CVE. Deux particularités rendent cette vulnérabilité intéressante au-delà de l'actualité : elle n'est atteignable que dans une fenêtre précise, quand le serveur de documents local de l'application ne tourne pas, et désactiver l'application ne protège pas. Cet article détaille le mécanisme, la condition d'atteignabilité, ce qui est solidement établi et ce qui ne l'est pas, et la leçon de conception que cette faille illustre mieux que la plupart des injections de commande.
Le périmètre exact
La confusion la plus coûteuse, sur cette vulnérabilité, porte sur ce qui est touché.
| Composant | Concerné |
|---|---|
richdocumentscode (Collabora Online, Built-in CODE Server) antérieur à 26.4.303 | Oui |
| Serveur Collabora Online autonome, installé séparément | Non |
| Nextcloud sans l'application Collabora intégrée | Non |
| Nextcloud Server lui-même | Non, le défaut est dans l'application |
Le composant visé est un serveur de documents embarqué. Nextcloud propose deux façons d'obtenir l'édition collaborative de documents : installer un serveur Collabora Online séparé, ou installer l'application qui embarque une version du moteur directement dans l'instance. La seconde est plus simple, ne demande aucune infrastructure supplémentaire, et c'est pour cette raison qu'elle est très répandue sur les instances de taille moyenne. C'est aussi celle qui est vulnérable.
La condition d'atteignabilité, et pourquoi elle est perverse
Le défaut n'est pas atteignable en permanence. D'après l'enregistrement de la vulnérabilité et les analyses publiées, il ne l'est que lorsque le serveur de documents local de l'application n'est pas en cours d'exécution : après un redémarrage, pendant une mise à jour, ou après un plantage. Dans cette fenêtre, une requête non authentifiée vers proxy.php peut faire exécuter une commande sur le serveur.
Cette conditionnalité produit trois effets qu'il faut nommer.
Elle crée une fenêtre qui coïncide avec les interventions d'administration. Le serveur de documents est arrêté exactement au moment où l'administrateur met à jour, redémarre ou dépanne. La vulnérabilité s'ouvre pendant la maintenance, c'est-à-dire pendant l'opération censée améliorer la posture.
Elle rend le test de vulnérabilité non reproductible. Un scanner lancé sur une instance saine, serveur de documents en fonctionnement, ne déclenchera pas le chemin de code. L'absence de détection ne vaut pas absence de vulnérabilité. C'est une limite générale des tests dynamiques face aux défauts conditionnés par l'état du système, et un argument pratique en faveur de l'analyse de composition logicielle, qui identifie la version du paquet plutôt que son comportement instantané.
Elle explique pourquoi la désactivation ne suffit pas. Désactiver une application Nextcloud en retire l'intégration fonctionnelle, mais le code reste sur le disque et le serveur de documents local, par construction, ne tourne plus. La désactivation garantit donc la condition d'atteignabilité au lieu de la supprimer. C'est le contraire du réflexe attendu, et c'est la raison pour laquelle les avis insistent sur la mise à jour ou le retrait du paquet.
Ce qui est établi, ce qui ne l'est pas
La ligne éditoriale de ce site impose des chiffres datés et sourcés. Sur cette vulnérabilité, deux éléments circulent largement sans être solidement corroborés, et il faut le dire.
Solidement établi. La nature du défaut (injection de commande du système d'exploitation dans proxy.php), le paquet touché, la version corrective 26.4.303, la condition d'atteignabilité, l'exploitation dans la nature en septembre et octobre 2026, le fait que la désactivation ne protège pas, et l'absence d'impact sur les serveurs Collabora Online autonomes.
Non corroboré. Le score CVSS. Plusieurs publications avancent 9.2 et une classification critique ; d'autres référentiels indiquent un score en attente. Le chiffre de 9.2 est le plus repris, il n'est pas pour autant confirmé par l'ensemble des sources, et une injection de commande non authentifiée aboutissant à l'exécution de code sur un serveur de fichiers se traite de la même façon quel que soit le nombre affiché.
Issu d'une source unique. Les détails de la charge déposée (noms de fichiers des portes dérobées, encodage, balises vers un service externe de collecte de requêtes) proviennent d'un seul rapport, qu'aucune seconde source ne reprend indépendamment. Les activités post-compromission mentionnées, recherche de bases de mots de passe et de portefeuilles de cryptomonnaies, relèvent du même rapport. Ces éléments sont utiles pour orienter une recherche, pas pour construire une liste d'indicateurs de compromission qu'on considérerait comme exhaustive.
La leçon de conception : le chemin de secours
Une injection de commande dans un proxy PHP n'a rien d'original. Ce qui est instructif ici, c'est où elle se trouve.
Le code vulnérable est un chemin de secours. Son rôle est de gérer le cas où le service attendu ne répond pas. Ce type de chemin partage trois propriétés qui en font un nid à vulnérabilités :
- Il est peu exercé. Le chemin nominal tourne des millions de fois, le chemin de secours quelques fois par an. Les tests fonctionnels couvrent le premier, rarement le second.
- Il est écrit dans l'urgence. Un chemin de secours naît souvent d'un incident de production : il faut que quelque chose se passe quand le service est absent. L'attention porte sur la disponibilité, pas sur la validation des entrées.
- Il a souvent moins de contrôles. Précisément parce que la situation est déjà dégradée, la tentation est de relâcher les vérifications pour maximiser les chances que le secours fonctionne. Ici, le chemin est atteignable sans authentification.
La règle de conception qui en découle est générale et applicable immédiatement, bien au-delà de Nextcloud : un chemin de secours doit porter les mêmes contrôles que le chemin nominal, et davantage de journalisation. Davantage, parce qu'il s'active rarement : son activation est en soi un événement, et devrait être tracée comme telle. Si l'activation du secours était journalisée et alertée, la fenêtre d'exploitation de cette vulnérabilité serait devenue un signal de sécurité au lieu d'être un angle mort.
Le corollaire pour la revue de code : les blocs catch, les branches else de vérification de disponibilité et les fonctions nommées fallback, legacy ou proxy méritent plus d'attention que le code principal, pas moins. C'est l'inverse de ce que fait une revue pressée.
Le plan d'action
1. Inventorier. Lister les instances Nextcloud, puis pour chacune la présence et la version de richdocumentscode. La version se lit dans l'interface d'administration des applications ou dans le fichier appinfo/info.xml du répertoire de l'application.
2. Corriger ou retirer. Mettre à jour en 26.4.303 ou postérieure, ou retirer l'application. Si l'édition collaborative est nécessaire, le serveur Collabora Online autonome n'est pas concerné par ce défaut : c'est une alternative de remédiation, au prix d'une infrastructure supplémentaire.
3. Chercher une compromission, si l'instance était exposée. La fenêtre de 11 septembre à la date de mise à jour effective est à considérer comme exposée, et l'exploitation est documentée sur cette période.
- Fichiers PHP du répertoire
apps/richdocumentscode/dont la date de modification ne correspond ni à l'installation ni à la dernière mise à jour du paquet. - Journaux du serveur web : requêtes vers
proxy.phppendant les périodes d'arrêt du serveur de documents, puis requêtes vers des chemins PHP inhabituels du même répertoire. - Trafic sortant du serveur vers des destinations non attendues.
- Si une porte dérobée est confirmée : les identifiants accessibles depuis le serveur (configuration Nextcloud, base de données, comptes de service) sont à considérer comme compromis et à faire tourner.
4. Tirer la conséquence sur la surveillance. Deux injections de commande en un an sur le même composant, CVE-2025-66208 corrigée en 25.04.702 puis celle-ci, constituent un motif. Ce paquet mérite une veille nominative, pas une veille générique sur Nextcloud.
Pour aller plus loin
L'injection de commande partage sa racine avec l'injection SQL : une entrée non fiable concaténée dans un interpréteur. La catégorie A03 de l'OWASP Top 10 couvre les deux. Pour identifier une version vulnérable dans un parc sans dépendre d'un test dynamique, voir les scanners de dépendances.
Sources
- Avis de sécurité Collabora pour CVE-2026-110447, 14 octobre 2026 ; correctif en version 26.4.303 publié le 11 septembre 2026.
- Enregistrement CVE-2026-110447, daté du 14 octobre 2026 (description miroir NVD : exécution de code à distance, exploitée dans la nature en septembre et octobre 2026).
- The Hacker News, « Hackers backdoor Nextcloud servers », octobre 2026.
- SecurityOnline, analyse de CVE-2026-110447 (score 9.2 avancé, non confirmé par l'ensemble des référentiels).
- CVE-2025-66208, vulnérabilité antérieure du même composant, corrigée en 25.04.702.
