CybersécuritéExplication
Pour la faille Collabora de Nextcloud, mettre à jour ne suffit pas
Des serveurs Nextcloud ont été piratés dès le 10 septembre par une faille de l’appli qui fait tourner Collabora, corrigée le lendemain mais annoncée le 14 octobre seulement. Les administrateurs concernés doivent aussi chercher les fichiers laissés par les pirates.
Le 10 septembre à 19 h 51, heure de Paris, un serveur Nextcloud reçoit une adresse web de plusieurs centaines de caractères, terminée par /apps/richdocumentscode/proxy.php?status. Le lendemain, son hébergeur signale sur GitHub des « piratages réussis » sur plusieurs des serveurs qu’il gère, et les fichiers que l’intrus y a déposés : de petites pages PHP qui exécutent toute commande qu’on leur transmet, ce que les spécialistes appellent des « webshells ». C’est la plus ancienne attaque documentée publiquement contre une faille que Collabora a corrigée le 11 septembre, mais qu’elle n’a décrite que le 14 octobre, et que l’agence américaine de cybersécurité (CISA) a ajoutée le 23 octobre à son catalogue des failles exploitées.

Nextcloud est un logiciel libre de partage de fichiers que l’on installe sur son propre serveur. La faille ne touche pas Nextcloud lui-même, mais une appli facultative de son magasin, « Collabora Online - Built-in CODE Server » (nom technique : richdocumentscode). Elle permet d’éditer des documents dans le navigateur avec la suite bureautique en ligne Collabora sans installer de serveur séparé : elle télécharge la version gratuite de Collabora, dite CODE, et la fait tourner sur la machine même de Nextcloud. Sa description la destine à « des tests locaux et un usage hors production ». Le nombre de serveurs qui l’utilisent n’est pas public : la page de l’appli n’affiche aucun compteur.
Une adresse web recopiée dans une ligne de commande
L’avis publié le 14 octobre par Collabora, l’éditeur de la suite, résume le défaut : une simple requête vers le fichier proxy.php de l’appli, sans identifiant, « peut faire exécuter une commande du système d’exploitation sous l’identité de l’utilisateur du serveur web ». Une condition : que le serveur bureautique intégré ne soit pas en marche, ce qui arrive « au redémarrage d’un conteneur, lors d’une mise à jour ou après un plantage ». Dans ce cas, proxy.php le relance, et c’est cette relance qui ouvrait la porte. La faille porte le numéro CVE-2026-110447 et la note de 9,2 sur 10 sur le barème de gravité CVSS.
Les correctifs publiés dans le dépôt de l’appli montrent comment. Pour démarrer le serveur, proxy.php composait une ligne de commande transmise au shell (l’interpréteur de commandes de Linux), en y glissant l’adresse d’un fichier de polices qu’il calculait à partir de l’adresse demandée par le visiteur. Les attaquants plaçaient donc dans cette adresse une commande entre $( et ), que le shell exécute au lieu de la prendre pour du texte. Le 14 septembre, un administrateur déjà passé à la version corrigée a d’ailleurs retrouvé, selon le ticket ouvert sur GitHub, la commande des pirates recopiée telle quelle dans les paramètres du programme lancé, mais sans effet : les tentatives « n’aboutissent pas », écrit-il, et Michael Meeks, de Collabora, estime que cette trace « devrait être sans danger ». Le correctif de la version 26.4.303 tient en quelques lignes qui neutralisent la commande avant de la passer au shell, sous un intitulé anodin : « mise au propre de la construction de la commande de lancement ».
Les requêtes publiées décodent un petit programme qui écrit le webshell dans le dossier de l’appli, puis prévient l’attaquant par le service webhook.site. Sur l’un des serveurs, raconte l’hébergeur, l’intrus s’en est ensuite servi pour chercher des coffres de mots de passe (fichiers KeePass, dossiers Bitwarden ou 1Password) et des portefeuilles de cryptomonnaies. Les journaux qu’il a examinés ne montraient pas de commande d’envoi de fichiers ; mais un webshell qui tourne sous le compte du serveur web « peut lire ou modifier tout ce qui est accessible à ce compte », écrit-il. Un autre administrateur dit avoir découvert l’intrusion par les messages d’alerte de son serveur sur des tentatives ratées d’obtenir les droits d’administration du système.
Pourquoi la désactivation ne protégeait pas
Désactiver une appli dans Nextcloud ne retire pas ses fichiers du serveur : seule la suppression le fait, selon la documentation. Le fichier proxy.php restait donc joignable depuis Internet, et toujours capable de relancer le serveur bureautique. Collabora l’admet dans un commit du 20 octobre : « désactiver l’appli laissait proxy.php démarrer » le serveur bureautique à partir des réglages déjà enregistrés. D’où la consigne de l’avis : mettre à jour ou supprimer.
Les installations sous Nextcloud 29 ou plus ancien sont dans une impasse : depuis la version 26.4.302 du 31 août, l’appli « exige Nextcloud 30 ou plus récent ». Ces versions de Nextcloud ne reçoivent donc pas le correctif, et l’avis demande à leurs utilisateurs de mettre Nextcloud à jour ou de retirer l’appli.
Les autres façons d’utiliser Collabora avec Nextcloud ne sont pas concernées. L’avis le dit des serveurs Collabora Online autonomes. Un utilisateur du forum de Nextcloud y ajoute Collabora installé par Docker ou par les paquets d’une distribution Linux, et les offres hébergées ; selon BleepingComputer, Collabora lui a confirmé la même liste en y incluant Nextcloud All-in-One, l’installation tout-en-un de Nextcloud par Docker. Il ne s’agit pas non plus de la faille CVE-2025-66208, qui visait le même fichier proxy.php en décembre 2025 : selon l’avis, son correctif « n’empêche pas » la nouvelle attaque.
Cinq semaines entre le correctif et l’avis
La chronologie se lit dans le ticket n° 354 et les versions de l’appli. Le correctif est intégré au code le 9 septembre au soir ; la plus ancienne attaque publiée date du 10 au soir ; la version 26.4.303 sort le 11 à 15 h 43 (heure de Paris), avec une note de version qui ne parle que de la version de Collabora embarquée. Le ticket est ouvert un peu plus d’une heure après. Le 14 septembre, un développeur demande aux victimes si elles utilisent la 26.4.303 ; le même jour, Michael Meeks les presse de mettre à jour et explique : « Nous sommes bloqués derrière un retard record depuis quelques jours. » Il renvoie à un billet de GitHub de juin : sa base d’avis de sécurité en a publié 1 560 en mai 2026, plus de cinq fois son rythme habituel, et ses délais de traitement se comptaient alors, pour une part notable des avis, en semaines. Selon BleepingComputer, Collabora a imputé surtout le retard de l’annonce aux files d’attente de GitHub, saturées selon elle par l’afflux de signalements produits avec l’IA, un phénomène que subissent aussi les listes de diffusion du logiciel libre.
Entre-temps, aucun avis n’alertait les administrateurs qui ne lisaient pas ce ticket. Le 29 septembre, un participant y demande si un numéro CVE a été attribué. Le 3 octobre, un utilisateur ouvre sur le forum de Nextcloud un fil intitulé « Mettez à jour au plus vite », « puisqu’à ma connaissance aucun avertissement ni CVE n’a été publié ». L’avis de Collabora et la fiche CVE paraissent le 14 octobre ; le numéro a été attribué par MITRE, l’organisme qui gère le catalogue, et la fiche précise que la faille a été « exploitée dans la nature en septembre et octobre 2026 ». Nextcloud, interrogé par BleepingComputer, a indiqué que Collabora lui avait signalé la faille à la mi-septembre et que la mise à jour était disponible dans le magasin d’applis. L’éditeur n’avait publié aucun avis propre le 26 octobre au matin dans sa liste d’avis de sécurité sur GitHub. Le CERT-FR, le centre de réponse aux incidents de l’administration française, ne la mentionnait ni dans ses avis consultés ce jour-là, ni dans son bulletin hebdomadaire du 19 octobre, qui couvre la semaine de l’annonce. Debian, de son côté, classe la faille hors de son périmètre : l’appli ne passe pas par les paquets de la distribution, seulement par le magasin de Nextcloud.
Le 23 octobre, la CISA a inscrit la faille à son catalogue. Les agences fédérales civiles américaines ont jusqu’au 26 octobre pour corriger, trois jours seulement, et l’entrée exige en plus un « triage forensique », que la directive BOD 26-04 définit comme l’examen du système « pour déterminer s’il est compromis ». L’agence classe l’usage par des groupes de rançongiciels comme « inconnu ». Le CERT Polska, centre de réponse aux incidents polonais, est plus affirmatif : la faille est « activement exploitée pour mener des attaques par rançongiciel et prendre le contrôle de serveurs », écrivait-il le 20 octobre, sans citer d’élément à l’appui. Son homologue italien, le CSIRT Italia, a décrit le 16 octobre un serveur compromis : l’intrus y avait installé trois webshells et récupéré un fichier de configuration contenant des identifiants et des secrets de l’application ; aucun indice d’accès aux documents des utilisateurs n’était apparu à ce stade. Aucune de ces sources ne dit qui mène ces attaques, ni combien de serveurs ont été touchés.
Ce qu’ajoute la version 26.4.502
La version publiée le 23 octobre ne corrige pas de nouvelle faille déclarée, mais elle referme plusieurs portes laissées ouvertes. Désactiver l’appli arrête désormais le serveur bureautique : la requête suivante reçoit un refus. L’attente d’un démarrage, qui pouvait bloquer sans fin, est abandonnée après cinq minutes, et l’appli vérifie que le processus qu’elle s’apprête à arrêter est bien le sien. Les documents ne peuvent plus aller chercher de données que sur les adresses de Nextcloud lui-même, et non plus sur les réseaux privés que la configuration fournie autorisait par défaut, ce qu’un commit du 21 octobre justifie ainsi : l’administrateur de cette appli n’a « pas de coolwsd.xml à modifier », le fichier de configuration du serveur bureautique. La note de version, elle, se contente encore d’indiquer la version de Collabora embarquée.
Mettre à jour aujourd’hui protège contre la prochaine requête, pas contre celles d’avant. Le webshell déposé en septembre reste en place après la mise à jour : Michael Meeks demandait dans la nuit du 18 au 19 septembre de passer à la 26.4.303 « et aussi de supprimer tout fichier shx*.php restant ». Le 16 octobre encore, un administrateur a trouvé par le contrôle d’intégrité, après une mise à jour de Nextcloud, un fichier Nx_33143.php d’une ligne, <?php system($_GET[c]);, un nom différent de ceux du ticket : chercher seulement les shx ne suffit pas, c’est tout fichier étranger au dossier de l’appli qu’il faut traquer.
Les citations de Collabora, de la CISA, de GitHub, du ticket, du forum de Nextcloud et de la fiche CVE sont traduites de l’anglais par la rédaction, celle du CERT Polska du polonais.



