← Retour au blog

Faille Nextcloud Collabora : désactiver Built-in CODE ne suffit pas

CVE-2026-110447 est exploitée pour déposer des webshells sur des serveurs Nextcloud. Application concernée, version corrective et vérifications à mener.

Serveur Nextcloud et composant Collabora Built-in CODE compromis, avec l'identifiant CVE-2026-110447 et le logo Forget About IT

Dans le cadre de notre veille sécurité, nous signalons CVE-2026-110447, une faille de l’application Collabora Online – Built-in CODE Server utilisée avec Nextcloud.

Des attaques ont déjà permis de déposer des webshells, des fichiers PHP donnant un accès à des commandes sur le serveur. La fiche CVE mentionne une exploitation en septembre et octobre 2026. Les versions de richdocumentscode antérieures à 26.4.303 sont concernées. Source : fiche CVE officielle.

La priorité est claire : identifier les instances concernées, corriger l’application et rechercher les traces d’une éventuelle compromission. Désactiver le composant ne constitue pas une protection suffisante.

Ce que l’on sait sur CVE-2026-110447

Le défaut se situe dans proxy.php, le script utilisé par l’application pour lancer le serveur bureautique intégré. Une requête peut déclencher une commande système sans authentification lorsque CODE n’est pas en cours d’exécution, notamment après un redémarrage ou un plantage.

Collabora attribue un score CVSS 4.0 de 9,2, critique. L’exécution se fait avec les droits du serveur web, pas automatiquement en root. Le bulletin concerne le mode Built-in CODE ; les serveurs Collabora autonomes ne sont pas affectés par cette faille. Source : bulletin officiel Collabora.

Pourquoi cette faille doit être traitée rapidement

Le signalement initial, ouvert le 11 septembre sur le dépôt Collabora, contient des journaux d’attaques des 10 et 11 septembre contre plusieurs installations. Les administrateurs rapportent la création de fichiers PHP malveillants dans le répertoire de l’application.

Sur une instance, l’attaquant a ensuite recherché des fichiers associés à des coffres de mots de passe et des portefeuilles de cryptomonnaies. Le rapport ne démontre pas une exfiltration, mais confirme l’utilisation du webshell après son dépôt. Source : signalement et échanges avec les mainteneurs.

Pour une entreprise, l’enjeu n’est pas seulement la disponibilité de l’éditeur bureautique. Il faut déterminer ce que le compte du serveur web peut lire ou modifier : documents, configuration, secrets applicatifs, connexions à des services tiers.

Notre recommandation est de traiter en priorité les instances exposées sur Internet, celles contenant des données sensibles et les environnements dont l’historique de maintenance est incomplet. Une instance peu utilisée ne doit pas être oubliée dans l’inventaire.

Versions et déploiements concernés

Déploiement Situation pour cette vulnérabilité
Application richdocumentscode avant 26.4.303 Mise à jour ou suppression nécessaire
Application richdocumentscode à partir de 26.4.303 Correctif présent ; vérifier l’exposition passée
Serveur Collabora autonome, sans l’application Built-in CODE Non concerné par cette faille

Ce périmètre est confirmé par Collabora. Il faut relever la version de l’application, pas seulement celle de Nextcloud.

Le correctif est disponible depuis la version du 11 septembre 2026. Le bulletin de sécurité a été publié le 14 octobre : l’alerte est récente, mais la période à examiner commence avant cette publication.

Vérifier son installation sans lancer d’exploit

Commencez par l’inventaire des applications, y compris celles désactivées. Sur une installation classique Debian ou Ubuntu, la commande suivante donne la liste et les versions :

sudo -u www-data php /var/www/nextcloud/occ app:list

Adaptez le chemin, le compte HTTP et la version de PHP à votre installation. Dans un déploiement conteneurisé, utilisez la procédure prévue pour exécuter occ dans le conteneur applicatif. La documentation Nextcloud précise les conditions d’exécution de cet outil.

Relevez ensuite :

  • la présence de richdocumentscode et sa version ;
  • l’emplacement réel de ses fichiers, notamment dans les répertoires d’applications personnalisés ;
  • les dates des mises à jour et redémarrages ;
  • les sauvegardes disponibles et la durée de conservation des journaux ;
  • les autres instances utilisant le même modèle de déploiement.

Évitez les tests d’exploitation sur la production. Ces informations suffisent pour décider de la correction, sans chercher à obtenir une exécution de commande sur un serveur métier.

Corriger : ne pas se limiter à désactiver l’application

Le bulletin Collabora exige une mise à jour ou une suppression de Built-in CODE. Pour les installations Nextcloud 29 et antérieures, arrivées en fin de vie, il demande de faire évoluer Nextcloud ou de retirer l’application. Source : consignes de l’éditeur.

Nous recommandons la séquence suivante :

  1. conserver les journaux et préparer une sauvegarde de l’état existant, sans la considérer comme une copie saine ;
  2. en cas d’indicateur de compromission, isoler l’instance avant de poursuivre une maintenance ordinaire ;
  3. mettre à jour Built-in CODE vers une version corrigée compatible, ou retirer le composant si son usage n’est plus nécessaire ;
  4. confirmer la version et les fichiers réellement déployés sur chaque instance ;
  5. tester l’ouverture, la modification et l’enregistrement d’un document non sensible ;
  6. vérifier les erreurs applicatives et poursuivre l’analyse de l’exposition passée.

Le principe rejoint celui présenté dans notre analyse de WordPress Click2Shell : le suivi de sécurité doit couvrir le code présent sur le serveur, pas uniquement les fonctionnalités affichées comme actives.

Rechercher les traces d’une compromission

Le ticket initial signale notamment des fichiers nommés shx*.php et shrf4645.php, ainsi que des requêtes vers proxy.php?status. Il fournit des exemples de chemins encodés et de commandes dissimulées dans les requêtes. Ces éléments sont consultables dans le signalement.

Pour notre revue opérationnelle, nous privilégions trois axes :

  • Les fichiers : comparer le répertoire applicatif à une distribution officielle, examiner les ajouts et les modifications inexpliqués.
  • Les journaux : rapprocher les accès suspects des dates de création des fichiers et des interventions autorisées, en incluant les archives disponibles.
  • Les accès et secrets : examiner les comptes, jetons, tâches planifiées et connexions sortantes qui ne correspondent pas à l’activité attendue.

Les noms de fichiers observés sont des points de départ, pas une liste exhaustive. Leur absence ne prouve pas que le serveur est intact.

Si un webshell est découvert, la mise à jour ne clôt pas l’incident. Préservez une copie des éléments utiles à l’analyse, limitez l’accès au serveur et définissez le périmètre à reconstruire ou restaurer. Les secrets potentiellement accessibles devront être renouvelés dans un environnement assaini. Supprimer le fichier visible sans comprendre les autres modifications peut laisser un accès persistant.

Notre lecture opérationnelle

Nextcloud permet de reprendre la maîtrise de ses documents et de ses outils collaboratifs. Cette maîtrise implique aussi de suivre les applications installées autour du service principal.

Les fonctions présentées dans notre article sur Nextcloud Hub 26 Summer ne changent pas ce besoin : chaque composant ajouté doit entrer dans l’inventaire, la veille, les sauvegardes et les contrôles après intervention.

Chez Forget About IT, nous abordons ce type d’alerte comme une opération de maintien en condition de sécurité : qualification du parc, priorisation, correction, validation fonctionnelle et investigation lorsque des indices le justifient. Notre article sur le suivi quotidien des CVE détaille cette organisation.

Conclusion

CVE-2026-110447 nécessite une intervention sur les installations Nextcloud utilisant une version vulnérable de Built-in CODE. Le bon réflexe est d’identifier le composant, appliquer la correction et vérifier l’état du serveur.

Si votre parc manque d’inventaire ou si des fichiers suspects apparaissent, nous pouvons vous accompagner dans la qualification et la remédiation :

Sources

FAQ : faille Nextcloud Collabora

Quelle application faut-il vérifier ?

Collabora Online – Built-in CODE Server, identifiée par richdocumentscode. Le seuil corrigé est la version 26.4.303.

Désactiver Built-in CODE suffit-il ?

Non. Collabora demande de mettre à jour l’application ou de la supprimer, pas seulement de la désactiver.

Faut-il vérifier le serveur après la mise à jour ?

Oui. Recherchez les fichiers inattendus et analysez les journaux. Si une compromission est confirmée, conservez les preuves et engagez une remise en état contrôlée.

Suivre nos publications

Retrouvez plus facilement nos analyses dans Google

Ajoutez Forget About IT à vos sources préférées pour signaler à Google que vous souhaitez voir davantage nos contenus.

Ajouter ce site à mes sources préférées sur GoogleCela augmente vos chances de voir nos articles mis en avant dans le Mode IA, les Aperçus IA et la section « À la une » de Google.

Articles recommandés