# Faille Nextcloud Collabora : désactiver Built-in CODE ne suffit pas > Faille Nextcloud Collabora CVE-2026-110447 : Built-in CODE est exploité pour déposer des webshells. Versions concernées, correctif et contrôles. - URL canonique : [https://forgetaboutit.fr/blog/faille-nextcloud-collabora-built-in-code-cve-2026-110447/](https://forgetaboutit.fr/blog/faille-nextcloud-collabora-built-in-code-cve-2026-110447/) - Publication : 2026-10-16T09:00:00.000Z - Catégorie : Sécurité - Sujets : Nextcloud, Collabora, CVE-2026-110447, Auto-hébergement, Patch management, Cybersécurité 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 : ```bash 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](/blog/faille-wordpress-click2shell-theme-inactif/) : 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](/blog/nextcloud-hub-26-summer-equipes-ia-locale/) 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](/blog/suivi-cve-pourquoi-quotidien/) 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 : - [Découvrir notre infogérance Linux](/infogerance/) - [Nous contacter pour votre infrastructure Nextcloud](/contact/) ## Sources - Collabora — bulletin de sécurité officiel CVE-2026-110447 - CVE Program — fiche CVE-2026-110447 - Collabora — signalement des attaques et réponses des mainteneurs - Collabora — publication de richdocumentscode 26.4.303 - Nextcloud — utilisation de la console occ ## 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.