Ce que corrige richdocumentscode 26.4.303
CVE-2026-110447 est une injection de commande système sans authentification, classée CWE-78 et notée 9,2 en CVSS 4.0 par l'avis de Collabora. Elle touche une seule application : Collabora Online - Built-in CODE Server, identifiant richdocumentscode, un module optionnel de Nextcloud qui embarque un serveur Collabora dans l'application elle-même. Le point d'entrée est le fichier proxy.php de l'application. L'avis dit qu'une requête peut faire exécuter une commande du système avec les droits de l'utilisateur du serveur web.
Le correctif est la version 26.4.303 : le commit date du 9 septembre 2026 et la version est disponible depuis le 11 septembre 2026. L'avis, lui, n'a été publié que le 14 octobre 2026, plus d'un mois après. Collabora explique ce délai par l'engorgement du traitement des CVE sur GitHub. Conséquence pratique : un serveur resté en retard a pu être attaqué bien avant que l'identifiant existe. Cet article part de ce constat et traite donc deux questions, pas une : le correctif, et la recherche de traces.
Ce que l'on sait de l'exploitation
- Condition d'attaque — l'avis précise que l'attaque ne fonctionne que lorsque le serveur CODE intégré n'est pas en cours d'exécution : redémarrage de conteneur, mise à jour, plantage. Aucune authentification ni interaction n'est requise.
- Début des attaques — les administrateurs rapportent des premières attaques les 10 et 11 septembre 2026 sur la version 26.4.302. BleepingComputer parle de la mi-septembre ; les sources divergent de quelques jours, et nous ne tranchons pas.
- Inscrit au catalogue KEV — la CISA a ajouté CVE-2026-110447 à son catalogue des vulnérabilités exploitées le 23 octobre 2026, avec une échéance fédérale au 26 octobre. L'exploitation est donc constatée, pas théorique.
- Ce que les attaquants ont cherché — des webshells PHP déposés sur le serveur, puis la recherche de bases de mots de passe, de gestionnaires de mots de passe et de portefeuilles de cryptomonnaies.
- Rançongiciel : non confirmé — des utilisateurs en ont signalé sur le ticket du projet ; BleepingComputer n'a pas pu le confirmer. Nous le rapportons comme une rumeur, rien de plus.
- Nombre de serveurs touchés — inconnu. Aucune source primaire ne donne de chiffre.
Versions touchées, versions corrigées, configurations non concernées
Faites défiler le tableau
| Configuration | État | Action |
|---|---|---|
| Application `richdocumentscode` en version antérieure à 26.4.303 | Vulnérable | Mettre à jour vers 26.4.303 ou plus, ou supprimer l'application |
| Application `richdocumentscode` en version 26.4.303 ou plus | Corrigée | Chercher quand même des traces antérieures à la mise à jour |
| Application `richdocumentscode` simplement désactivée | Non protégée | La désactivation ne suffit pas : mettre à jour ou supprimer |
| Serveur Collabora Online autonome | Non concerné, selon Collabora | Aucune action liée à cette CVE |
| Collabora en Docker ou en paquet RPM/DEB | Non concerné, selon Collabora | Aucune action liée à cette CVE |
| Nextcloud All-in-One | Non concerné, selon Collabora | Aucune action liée à cette CVE |
| Nextcloud 29 ou antérieur | Fin de vie | Mettre à jour Nextcloud, ou supprimer l'application |
Built-in CODE ou serveur externe : comment trancher
Beaucoup d'administrateurs ne savent pas lequel des deux ils ont, parce que l'application Nextcloud Office affiche le même éditeur dans les deux cas. La distinction se lit ailleurs. Le serveur Collabora « externe » est un service à part (conteneur, paquet, machine dédiée) auquel Nextcloud se connecte par une URL, saisie dans les réglages de Nextcloud Office. Le serveur « intégré » est une application Nextcloud de plus, richdocumentscode, qui télécharge et lance un serveur local.
Le critère fiable est donc la présence de l'application, pas l'adresse affichée dans les réglages. Si richdocumentscode est installée, vous êtes dans le périmètre de l'avis, qu'elle soit activée ou non. Si elle est absente, cette CVE ne vous concerne pas, même si vous utilisez Collabora. Un administrateur du forum Nextcloud signale d'ailleurs que les installations qui utilisent richdocuments sans richdocumentscode ne sont pas touchées.
Inventorier un serveur, puis un parc, en cinq gestes
Lister les applications installées
Depuis le répertoire de Nextcloud, ou à l'intérieur du conteneur, exécutez
sudo -E -u www-data php occ app:list | grep richdocumentscode. Adaptez l'utilisateur et le chemin à votre installation. Une ligne affichée signifie que l'application est présente, activée (Enabled) ou non (Disabled).Relever la version installée
Lancez
sudo -E -u www-data php occ config:app:get richdocumentscode installed_version. Si le numéro est inférieur à 26.4.303, l'installation est dans la plage de l'avis.Regarder ce que Nextcloud Office utilise
Ouvrez les réglages de Nextcloud Office et notez l'URL du serveur Collabora. Elle ne remplace pas l'étape 1 : la présence de l'application prime sur l'adresse affichée.
Rapprocher l'état des mises à jour disponibles
sudo -E -u www-data php occ app:update --showonlyliste les mises à jour d'applications proposées sans les appliquer. Vérifiez sirichdocumentscodey figure.Répéter sur chaque serveur et consigner le résultat
Sur un parc, faites passer les mêmes trois commandes par SSH sur chaque instance client et collez les sorties dans un tableau : client, serveur, application présente, version, date de contrôle. C'est ce tableau qui vous permettra de répondre à un client qui demande s'il est concerné.
Désactiver ne suffit pas : mettre à jour ou supprimer
Le réflexe est de désactiver l'application en attendant. L'avis de Collabora le dit sans ambiguïté : il ne suffit pas de désactiver l'application, elle doit être mise à jour vers 26.4.303 ou plus, ou supprimée. Le fichier vulnérable reste sur le disque tant que l'application n'est pas retirée, et l'avis ne dit pas qu'un fichier désactivé devient inatteignable.
Choisissez selon l'usage. Si vos utilisateurs éditent des documents avec le serveur intégré, mettez à jour. Si vous ne vous en servez pas, ou si vous avez un serveur Collabora externe, supprimez l'application : c'est la seule option qui retire la surface d'attaque. Si votre Nextcloud est en version 29 ou antérieure, il n'est plus maintenu : l'avis demande de mettre à jour Nextcloud lui-même, ou de supprimer l'application.
Corriger : mise à jour ou suppression
Sauvegarder avant d'intervenir
Prenez un instantané de la machine ou une sauvegarde de la base et du répertoire de données. Si vous soupçonnez déjà une compromission, conservez aussi une copie des journaux avant toute modification : ils serviront à la chasse aux traces plus bas.
Mettre à jour l'application
sudo -E -u www-data php occ app:update richdocumentscode. Relancez ensuiteocc config:app:get richdocumentscode installed_versionpour confirmer que le numéro est 26.4.303 ou supérieur.Ou supprimer l'application
sudo -E -u www-data php occ app:remove richdocumentscode. La commande désactive puis retire l'application ; l'option--keep-dataconserve ses données. Confirmez avecocc app:list, qui ne doit plus la mentionner.Redémarrer le service concerné
Redémarrez PHP-FPM ou le conteneur Nextcloud pour qu'aucun processus ne garde l'ancien code en mémoire. Rappelez-vous que la condition d'exploitation est justement un redémarrage ou un plantage du serveur intégré.
Contrôler le résultat
Rejouez l'inventaire de la section précédente : l'application doit être absente ou en version 26.4.303 minimum. Notez la date et l'heure de la correction, elles serviront de borne dans la recherche de traces.
Un serveur patché aujourd'hui a pu être compromis avant
La mise à jour ferme la porte, elle ne dit rien de ce qui est déjà entré. Les premières attaques rapportées datent du 10 septembre 2026, et un administrateur a signalé sur le forum Nextcloud qu'un fichier malveillant était resté après la mise à jour. Un serveur à jour n'est donc pas un serveur sain.
L'avis officiel ne liste aucun indicateur de compromission. Ce qui suit n'est pas une liste d'indicateurs officielle : c'est une méthode de chasse générique, assortie de ce que des administrateurs ont rapporté sur le ticket richdocumentscode#354 du dépôt du projet. Un noyau de bon sens vaut pour tout le reste : aucune de ces vérifications ne prouve l'absence de compromission, elles peuvent seulement en révéler une.
Méthode de chasse aux traces (générique, à adapter)
- Fichiers PHP récents —
find /var/www/nextcloud/apps/richdocumentscode -name '*.php' -newermt 2026-09-01liste les fichiers PHP modifiés depuis le 1er septembre dans le répertoire de l'application. Faites de même sur le répertoire de données, où aucun fichier PHP n'a de raison d'exister. - Noms rapportés — des administrateurs ont trouvé des fichiers
shx*.phpdans le répertoire de Nextcloud (ticket #354) ; un autre a trouvé un fichier au nom différent dansapps/richdocumentscode/. Cherchershx*.phpest utile, mais l'absence de ce nom ne prouve rien : les attaquants peuvent choisir un autre. - Comparaison à l'archive officielle — téléchargez la version de l'application depuis le catalogue officiel, dépliez-la dans un répertoire temporaire et comparez avec
diff -r. Tout fichier en plus, ou différent, est suspect. - Contrôle d'intégrité de Nextcloud — un administrateur a découvert son fichier malveillant parce que le contrôle d'intégrité l'avait signalé. Lancez-le et lisez le résultat.
- Journaux du serveur web —
zgrep -hE 'proxy\.php.*(%2e%2e|IFS)' /var/log/nginx/access.log*cherche les requêtes versproxy.phpqui portent une séquence%2e%2eou la variable shell IFS. Les requêtes rapportées sur le ticket visaient/apps/richdocumentscode/proxy.php?status; un administrateur du forum conseille de remonter jusqu'au 10 septembre. Adaptez le chemin à Apache ou à votre rotation de journaux. - Processus étranges — des administrateurs ont observé des processus
coolwsdetcoolforkit-nssous l'utilisateur du serveur web avec une charge utile dans l'argumentremote_font_config.url. Ces processus existent aussi légitimement quand le serveur intégré tourne ; c'est le contenu de l'argument qui est anormal.
Si vous trouvez quelque chose : la machine est compromise
Un webshell exécute des commandes avec les droits de l'utilisateur du serveur web. Considérez alors tout ce que cet utilisateur peut lire comme exposé : config.php de Nextcloud (identifiants de la base, secrets), mots de passe d'application, clés SSH et jetons lisibles par lui, stockages externes branchés. Faites tourner ces secrets, puis restaurez depuis une sauvegarde antérieure au 10 septembre 2026 plutôt que de « nettoyer » la machine en place. Pour un client, prévenez-le : c'est son contenu qui a été exposé.
Un parc de Nextcloud clients : qui porte quoi
Pour une agence, cette CVE n'est pas une commande, c'est un inventaire. Chaque client a son instance, sa version, parfois une application installée « pour essayer » il y a deux ans. La question d'un client est prévisible : « sommes-nous concernés, et l'avez-vous vérifié ? ». La réponse honnête tient dans le tableau de l'étape 5 de l'inventaire, avec les dates de contrôle.
La responsabilité se répartit simplement : vous gérez la relation avec le client et vous décidez de l'action (mise à jour, suppression, restauration) ; nous tenons l'infrastructure sur laquelle tournent ces serveurs. Avec les solutions pour agences de ServOrbit.com, un seul espace réunit les serveurs, les renouvellements et la sécurité de chaque client, ce qui évite de reconstituer le parc depuis des tableurs le jour d'une alerte. Si vous êtes un professionnel qui administre une seule instance, la page solutions pour professionnels décrit l'accompagnement qui vous convient.
La parade durable : un Collabora séparé de Nextcloud
Selon Collabora, les serveurs Collabora Online autonomes, les installations Docker et RPM/DEB et Nextcloud All-in-One ne sont pas concernés. Le point commun est que le serveur d'édition vit dans son propre conteneur ou son propre service, hors de l'arborescence PHP de Nextcloud. C'est l'architecture « sidecar » décrite dans notre guide Nextcloud, Collabora et OnlyOffice : on n'y refait pas le tutoriel ici. Pour partir de zéro, héberger Nextcloud couvre le déploiement.
Ce n'est pas un argument contre l'application intégrée en soi, seulement une façon de réduire ce que l'on doit surveiller. Nous avons aussi publié deux autres guides de mise à jour d'urgence, PHP2Shell et nginx CVE-2026-15176 : la méthode est la même, inventorier, corriger, vérifier, puis chercher ce qui a pu passer avant.
