CVE-2026-110447 : faille critique Nextcloud Collabora CODE exploitée, web shells en circulation

La CISA a ajouté le 23 octobre 2026 la vulnérabilité CVE-2026-110447 à son catalogue KEV (Known Exploited Vulnerabilities), avec une date limite de correction fixée au 26 octobre 2026. La faille touche l'application Collabora Online Built-in CODE Server (richdocumentscode) pour Nextcloud : une injection de commande OS non authentifiée dans le fichier proxy.php, classée CVSS 9.2 (critique), CWE-78. Des attaquants l'exploitent activement depuis la mi-septembre 2026 pour déployer des web shells (scripts PHP malveillants) sur des instances Nextcloud auto-hébergées. Si vous administrez Nextcloud sur un VPS Linux ou un serveur dédié avec l'app richdocumentscode installée, la correction est urgente.

Source : GitHub Advisory GHSA-f97p-r72q-64h2 ; CISA Known Exploited Vulnerabilities Catalog, 23 octobre 2026.

Nextcloud auto-hébergé : l'environnement type concerné

Nextcloud est l'un des logiciels les plus installés par les administrateurs qui veulent un cloud privé sur leur propre serveur. L'installation type repose sur un VPS Linux ou un serveur dédié bare metal chez un hébergeur, sous Debian 12 ou Ubuntu 24.04 LTS. L'admin configure un serveur web (Apache ou Nginx en reverse proxy), PHP-FPM, et une base de données MySQL/MariaDB (ou PostgreSQL selon les préférences). Le nom de domaine pointe vers l'adresse IP du serveur via un enregistrement DNS de type A, et un certificat TLS protège les échanges.

Sur une machine virtuelle avec 2 à 4 Go de RAM et quelques coeurs de CPU, cette configuration fait tourner Nextcloud pour une équipe de 5 à 50 personnes : fichiers partagés, calendriers, contacts et, quand on installe l'app richdocumentscode, édition collaborative de documents directement dans le navigateur. C'est cette dernière brique, le serveur Collabora CODE intégré, qui est visée par CVE-2026-110447.

Ce que fait la vulnérabilité CVE-2026-110447

L'application richdocumentscode est le serveur Collabora Online intégré (Built-in CODE Server) que de nombreux administrateurs installent depuis le magasin d'applications Nextcloud pour éditer des documents directement dans le navigateur. Cette application embarque un fichier proxy.php qui sert de point d'entrée PHP autonome. Le problème : ce fichier est servi directement par le serveur web (Apache, Nginx) sans passer par le routeur ni le système d'authentification de Nextcloud. Toute requête HTTP vers /apps/richdocumentscode/proxy.php atteint le code PHP sans vérification d'identité.

Quand le processus Collabora (l'AppImage coolwsd) tourne normalement, la requête est relayée au serveur de documents local. Mais quand ce processus est arrêté (redémarrage du serveur, crash du service après un pic de RAM, mise à jour en cours), proxy.php tente de relancer l'AppImage en passant des paramètres non assainis dans la commande shell. Les valeurs du paramètre remote_font_config.url ne sont pas échappées : un attaquant peut injecter des commandes OS via la substitution de commandes shell ($()) et l'obfuscation avec ${IFS}. Le résultat : une exécution de code arbitraire sous l'utilisateur du serveur web (www-data), sans aucune authentification.

La fenêtre d'exploitation s'ouvre à chaque fois que coolwsd ne tourne pas : un redémarrage du VPS, un crash mémoire quand la RAM est saturée, un script de mise à jour qui relance les services. Sur un serveur auto-hébergé sans surveillance de processus, cette fenêtre peut rester ouverte indéfiniment.

Exploitation active : web shells et vol de données

Les premières attaques ont été observées dès la mi-septembre 2026, soit un mois avant la publication formelle du bulletin de sécurité et du CVE le 14 octobre. Les attaquants envoient des requêtes GET forgées vers /apps/richdocumentscode/proxy.php?status avec des séquences de traversée de chemin encodées (%2e%2e). Une fois l'injection réussie, ils déposent des web shells PHP directement dans le répertoire de l'application, sous des noms caractéristiques : shx*.php ou shrf*.php dans /apps/richdocumentscode/.

Une fois le web shell en place, les scripts d'attaque lancent une reconnaissance automatisée ciblant les fichiers sensibles stockés sur le serveur :

• Bases de données de gestionnaires de mots de passe : fichiers *.kdbx (KeePass), répertoires Bitwarden et 1Password ;
• Portefeuilles de cryptomonnaies : wallet.dat (Bitcoin), keystore.json (Ethereum), répertoires Monero ;
• Fichiers de configuration contenant des secrets : clés API, jetons d'accès, identifiants SMTP et mots de passe de bases de données MySQL ou PostgreSQL ;
• Sauvegardes chiffrées ou non, stockées dans des répertoires accessibles par www-data.

Les serveurs compromis transmettent un identifiant système à des URL webhook.site pour confirmer l'infection au serveur de commande et contrôle (C2). Nextcloud étant souvent utilisé comme cloud privé pour stocker justement ce type de données sensibles, l'impact d'une compromission est potentiellement critique pour l'ensemble de vos sites web et services hébergés sur la même machine.

Qui est concerné et qui ne l'est pas

La distinction est simple mais essentielle :

Seul le serveur CODE intégré (richdocumentscode) est touché. Si vous avez déployé Collabora Online via Docker sur votre VPS ou via Docker Compose comme conteneur séparé, votre installation n'est pas affectée par cette CVE. La différence tient au fait que l'app richdocumentscode expose proxy.php directement dans l'arborescence web de Nextcloud, alors qu'un conteneur Docker Collabora tourne dans son propre environnement isolé, avec sa propre pile réseau et ses propres paquets.

Comment corriger la faille

Trois options, par ordre de préférence. Toutes les commandes ci-dessous s'exécutent en ligne de commande sur votre serveur, en tant qu'utilisateur root ou via sudo.

Option 1 : mettre à jour vers 26.4.303 ou supérieur

Depuis l'interface d'administration Nextcloud ou en ligne de commande, mettez à jour l'application richdocumentscode vers la version 26.4.303 (publiée le 11 septembre 2026) ou supérieure. Cette version corrige l'assainissement des paramètres dans proxy.php.

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

Vérifiez la version installée :

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

Le correctif nécessite Nextcloud 30 ou supérieur. Si votre instance tourne sur Nextcloud 29 ou une version antérieure (fin de vie), vous devez d'abord mettre à jour Nextcloud, ou supprimer l'application. Sur Debian 12, vérifiez que vos paquets PHP (php-fpm, php-mbstring, php-mysql, php-gd) sont compatibles avec la version de Nextcloud visée avant de lancer la mise à jour.

Option 2 : supprimer l'application

Si vous n'utilisez pas l'édition collaborative de documents dans Nextcloud, supprimez l'application :

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

Après la suppression, redémarrez votre serveur web pour vider les caches de configurations :

# Sur Debian/Ubuntu avec Nginx
sudo systemctl restart nginx php8.3-fpm

# Sur Debian/Ubuntu avec Apache
sudo systemctl restart apache2

Option 3 (temporaire) : bloquer l'accès à proxy.php

En attendant la mise à jour, configurez votre serveur web pour bloquer les requêtes vers proxy.php au niveau du pare-feu applicatif. Exemple pour Nginx configuré en reverse proxy :

location ~ ^/apps/richdocumentscode/proxy\.php {
    deny all;
    return 403;
}

Pour Apache, ajoutez dans le virtualhost ou un fichier .htaccess :

<Files "proxy.php">
    <If "%{REQUEST_URI} =~ m#/apps/richdocumentscode/proxy\.php#">
        Require all denied
    </If>
</Files>

Après modification, redémarrez le service web concerné pour appliquer la nouvelle configuration.

Attention : désactiver l'application depuis l'interface Nextcloud ne suffit pas. Le fichier proxy.php reste accessible par le serveur web même quand l'app est désactivée, car il s'agit d'un point d'entrée PHP indépendant du routeur Nextcloud. Seules la mise à jour, la suppression complète ou le blocage au niveau des configurations du serveur web protègent votre instance.

Vérifier si votre instance est compromise

Si l'application richdocumentscode était installée en version inférieure à 26.4.303 entre septembre et octobre 2026, vérifiez la présence de web shells depuis la ligne de commande :

find /var/www/nextcloud/apps/richdocumentscode/ -name "shx*.php" -o -name "shrf*.php"

Cherchez aussi des scripts PHP récents dans l'ensemble du répertoire Nextcloud :

find /var/www/nextcloud/ -name "*.php" -newer /var/www/nextcloud/version.php -not -path "*/appdata_*"

Consultez les logs d'accès de votre serveur web pour repérer les requêtes suspectes vers proxy.php :

# Nginx
grep "proxy.php" /var/log/nginx/access.log | grep -v "200"

# Apache
grep "proxy.php" /var/log/apache2/access.log

Si l'une de ces commandes retourne des résultats, votre instance a probablement été compromise. Dans ce cas :

1. Isolez le serveur du réseau si possible (règle de pare-feu ou déconnexion) ;
2. Listez les processus suspects exécutés par www-data : ps aux | grep www-data ;
3. Vérifiez les connexions sortantes inhabituelles : ss -tnp | grep www-data ;
4. Exportez une copie des fichiers de logs et des scripts malveillants trouvés (preuve) ;
5. Changez tous les mots de passe et secrets stockés sur l'instance Nextcloud, y compris les identifiants de la base de données MySQL ou PostgreSQL ;
6. Révoquez les jetons d'application et les clés API accessibles depuis le serveur ;
7. Restaurez le serveur depuis une sauvegarde antérieure à la compromission ou réinstallez Nextcloud proprement.

Réduire l'exposition aux prochaines failles

CVE-2026-110447 illustre un schéma classique : un composant optionnel, installé pour le confort (l'édition de documents), expose une surface d'attaque imprévue. Voici les configurations qui limitent l'impact de ce type de vulnérabilité sur votre serveur :

• Séparer les services dans des conteneurs Docker. Collabora Online en conteneur isolé n'aurait pas été affecté. Chaque service (Nextcloud, base de données, Collabora) tourne dans sa propre machine virtuelle ou son conteneur, avec sa propre adresse IP interne et ses propres droits Unix. Un compromis dans un conteneur ne donne pas accès au système hôte.
• Configurer un pare-feu réseau. UFW et Fail2ban limitent les ports exposés. Sur un serveur Nextcloud, seuls les ports 80, 443 et SSH doivent être ouverts. Bloquez tout le reste et vérifiez régulièrement les ports en écoute avec ss -tlnp.
• Automatiser les mises à jour de sécurité. Le correctif de richdocumentscode est sorti un mois avant les premières attaques. Les mises à jour automatiques des paquets de sécurité sous Debian et Ubuntu auraient protégé l'OS, mais les applications Nextcloud nécessitent aussi un suivi via occ app:update --all ou l'activation des mises à jour automatiques dans les configurations admin de Nextcloud.
• Planifier des sauvegardes hors site. Après compromission, la restauration depuis un backup propre est souvent la seule option fiable. Chiffrez vos sauvegardes et stockez-les sur un serveur distant pour qu'un attaquant root sur la machine compromise ne puisse pas les altérer.
• Surveiller les ressources et les processus. Surveillez la RAM et le CPU de votre VPS. Un crash de coolwsd par manque de mémoire ouvre la fenêtre d'exploitation. Configurez le swap pour éviter les arrêts brutaux quand la mémoire est saturée.

Pour les administrateurs qui gèrent plusieurs instances Nextcloud, un script de vérification périodique (cron) qui contrôle la version de richdocumentscode et l'état du processus coolwsd sur chaque serveur aurait permis de détecter les installations vulnérables avant l'exploitation. Les premiers réglages de sécurité d'un serveur dédié couvrent les fondamentaux pour un socle solide.

Chronologie complète

Le correctif a été publié un mois avant la divulgation publique du CVE. Les administrateurs qui n'avaient pas activé les mises à jour automatiques des applications Nextcloud sont restés vulnérables pendant toute cette période, alors que les attaques étaient déjà en cours.