Les administrateurs Nextcloud ont plus qu’un correctif à installer. Des hackers exploitent une vulnérabilité critique de l’application CODE Server intégrée de Collabora pour exécuter des commandes et déposer des webshells PHP sur des serveurs vulnérables.
Référencée sous le nom CVE-2026-110447, cette faille d’injection de commandes affecte les versions antérieures à 26.4.303 de l’application richdocumentscode. Son exploitation est possible lorsque le serveur de documents local ne fonctionne pas, notamment lors d’un redémarrage, d’une mise à niveau ou d’un plantage. Des attaques sont observées depuis le 10 septembre, ce qui rend indispensables les vérifications de compromission, y compris pour les organisations qui ont déjà effectué la mise à jour.
La faille de Collabora expose une configuration spécifique de Nextcloud
Le composant concerné est Collabora Online - Built-in CODE Server, une application Nextcloud facultative qui permet de modifier des documents sans nécessiter de serveur Collabora distinct. Nextcloud la décrit comme une option facile à installer pour un usage personnel ou les petites équipes, bien qu’elle ne dispose pas de certaines fonctionnalités de performance et d’évolutivité d’un déploiement autonome.
L’avis de sécurité de Collabora indique que la faille peut permettre à un attaquant non authentifié d’exécuter des commandes du système d’exploitation avec les privilèges du compte du serveur web lorsque le serveur CODE local est hors ligne. L’éditeur a corrigé le problème dans la version 26.4.303 et averti que désactiver l’application ne suffisait pas. Les administrateurs doivent la mettre à jour ou la supprimer. Les serveurs Collabora Online autonomes ne sont pas concernés.
Les attaquants ont déposé des webshells et recherché des fichiers sensibles
The Hacker News a rapporté que plusieurs administrateurs avaient trouvé des preuves d’exploitation, notamment des webshells PHP placés dans le répertoire de l’application Collabora. Les attaquants ont utilisé cet accès pour rechercher des fichiers associés aux gestionnaires de mots de passe, aux portefeuilles de cryptomonnaies et à d’autres données sensibles. Les rapports examinés par la publication ne montrent pas que les attaquants aient obtenu un accès root.
Ces mêmes informations ont identifié des fichiers shx*.php parmi les indicateurs que les administrateurs devraient examiner, ainsi que des requêtes proxy.php?status suspectes, des marqueurs d’injection de commandes et des tentatives sudo infructueuses impliquant le compte du serveur web.
Dans le rapport d’incident original sur GitHub, un administrateur a documenté des charges utiles qui tentaient d’envoyer des informations système à des callbacks de webhook. Les requêtes examinées ne montraient pas de commandes visant à archiver ou téléverser des fichiers ; le vol de magasins d’identifiants ou d’autres fichiers sensibles n’est donc pas établi. Toutefois, les fichiers accessibles au compte du serveur web compromis doivent être considérés comme potentiellement exposés.
Les équipes de sécurité doivent rechercher une compromission, pas seulement installer le correctif
L’installation de la version corrigée ferme le chemin de commande vulnérable, mais ne supprime pas un webshell qui pourrait déjà être présent. Les serveurs qui utilisaient l’application CODE intégrée et qui ont redémarré, été mis à niveau ou subi un plantage pendant la période d’exploitation doivent faire l’objet d’un examen prioritaire.
Les équipes de sécurité doivent :
- Vérifier l’application et la version installées. Mettre richdocumentscode à niveau vers la version 26.4.303 ou une version ultérieure, ou la supprimer. Les organisations qui utilisent Nextcloud 29 ou une version antérieure en fin de vie doivent mettre Nextcloud à niveau ou supprimer l’application, comme le recommande Collabora.
- Rechercher les signes d’une exploitation antérieure. Inspecter apps/richdocumentscode/ à la recherche de fichiers PHP inattendus, notamment ceux dont le nom correspond à shx*.php et le fichier signalé shrf4645.php. Examiner les journaux d’accès conservés jusqu’au 10 septembre au moins pour repérer les requêtes ciblant proxy.php?status et contenant des marqueurs d’injection de commandes tels que $( ou ${IFS} dans le chemin de la requête. Rechercher les tentatives sudo infructueuses du compte du serveur web.
- Évaluer les identifiants exposés et les données. Déterminer ce que le compte du serveur web pouvait lire et renouveler les identifiants concernés si des signes de compromission sont détectés.
Le journal des versions de Collabora date la version 26.4.303 du 11 septembre, tandis que son avis de sécurité a été publié le 14 octobre. Cet écart est une raison supplémentaire pour les équipes de sécurité de surveiller les avis des éditeurs et les mises à jour des applications parallèlement aux flux CVE, plutôt que d’attendre un identifiant officiel de vulnérabilité.
Si des preuves de compromission sont découvertes, conservez les journaux pertinents et les fichiers suspects, isolez le serveur concerné et examinez l’accès de l’attaquant avant de rétablir le service. Évaluez les identifiants potentiellement exposés, renouvelez-les depuis un système de confiance et déterminez si le serveur doit être reconstruit. L’installation du correctif ferme la vulnérabilité, mais ne supprime pas un accès existant de l’attaquant.
À lire également : nous avons aussi expliqué comment l’échec du correctif d’Ahsay a laissé deux failles de sauvegarde exploitées à découvert, autre cas où des attaquants ont utilisé des vulnérabilités de serveur pour déployer des webshells.