Roundcube : failles multiples dont RCE à corriger sans tarder

Le CERT-FR a publié le 26 mai 2026 une alerte relative à de multiples vulnérabilités affectant Roundcube Webmail, avec un niveau de gravité particulièrement élevé du fait de l’impact potentiel annoncé par l’éditeur et repris par le CERT : exécution de code à distance, compromission de comptes de messagerie, atteinte à la confidentialité des échanges et, selon l’architecture d’hébergement, rebond vers le serveur de messagerie ou l’infrastructure adjacente. Pour les équipes d’exploitation, d’administration système, de sécurité et les RSSI, cette famille de failles est stratégique car Roundcube est très souvent exposé directement sur Internet, derrière un simple frontal HTTP, et sert de point d’entrée à des utilisateurs nombreux, parfois externes, parfois fédérés.

Le risque n’est pas théorique. Un webmail accessible publiquement concentre plusieurs caractéristiques recherchées par les attaquants : surface d’attaque large, exposition continue, présence de données sensibles, sessions authentifiées, pièces jointes, carnet d’adresses, et interaction directe avec des composants critiques comme PHP, le serveur web, le stockage de sessions et les serveurs IMAP/SMTP. Dans des environnements mutualisés ou d’hébergement administré, notamment chez des acteurs fréquemment rencontrés en France comme OVHcloud, o2switch ou Scaleway, un Roundcube non corrigé peut devenir un point d’appui majeur pour un attaquant cherchant à compromettre des boîtes aux lettres, à détourner des campagnes de phishing ou à obtenir une exécution de code sur l’hôte applicatif.

L’avis du CERT-FR s’appuie sur l’annonce de sécurité officielle de l’éditeur de Roundcube. La sévérité exacte dépend des vulnérabilités concernées et de la configuration déployée, mais la mention explicite d’un impact pouvant aller jusqu’à la RCE impose une priorisation immédiate du patching. Lorsqu’un score CVSS est fourni par l’éditeur ou les bases de vulnérabilités, il doit être retenu dans la qualification interne, mais même en l’absence de score consolidé au moment de l’alerte, le simple triptyque service exposé + authentification utilisateur + exécution de code possible justifie une fenêtre de remédiation courte, idéalement en urgence contrôlée.

La source originale à consulter est l’avis du CERT-FR du 26 mai 2026 intitulé Multiples vulnérabilités dans Roundcube, ainsi que l’advisory de sécurité publié par l’éditeur Roundcube. Les identifiants CVE exacts, les scores CVSS et les branches corrigées doivent être validés à partir de ces sources au moment du déploiement, car les distributions Linux, les intégrateurs et les hébergeurs peuvent publier des rétroportages avec des numéros de paquet différents de la version amont.

Versions affectées

Selon l’alerte du CERT-FR du 26 mai 2026 et les informations fournies par l’éditeur, plusieurs branches de Roundcube Webmail sont concernées. La règle opérationnelle à retenir est simple : toute instance non mise à jour vers la version de sécurité publiée par l’éditeur doit être considérée comme vulnérable jusqu’à vérification formelle.

Dans les environnements de production, il faut distinguer trois cas :

Installation amont manuelle : Roundcube a été déployé depuis l’archive officielle ou via git. La version affichée dans l’interface ou dans le fichier de programme correspond généralement à la branche amont.
Installation packagée distribution : la version visible dans le code peut sembler ancienne, mais le correctif peut avoir été rétroporté dans le paquet par la distribution. Il faut alors se fier au changelog du paquet et aux bulletins de sécurité du fournisseur.
Offre d’hébergement mutualisé ou managée : l’éditeur du service, par exemple un hébergeur ou un panel d’administration, peut piloter lui-même les mises à jour. Une vérification spécifique auprès du fournisseur est nécessaire.

Les versions vulnérables et corrigées doivent être reprises telles qu’annoncées par l’éditeur et le CERT-FR. En pratique, il convient d’identifier :

la ou les branches de maintenance encore supportées par l’éditeur ;
les versions antérieures à la publication de sécurité du 26 mai 2026 ;
la première version corrigée dans chaque branche supportée ;
les branches en fin de vie qui ne reçoivent plus de correctif et qui nécessitent une montée de version plus importante.

Pour inventorier précisément la version déployée, plusieurs méthodes sont possibles selon l’installation :

vérifier l’écran About ou les informations de l’interface d’administration si elles sont disponibles ;
consulter le fichier program/include/iniset.php, index.php ou les métadonnées de version fournies par l’application ;
interroger le gestionnaire de paquets du système ;
contrôler le dépôt git si l’application est versionnée localement.

Exemples de commandes utiles :

dpkg -l | grep roundcube
apt-cache policy roundcube roundcube-core
rpm -qa | grep -i roundcube
dnf info roundcubemail
grep -R "version" /var/www/roundcube 2>/dev/null | head
git -C /var/www/roundcube tag --points-at HEAD

Si l’instance est exposée derrière un nom comme webmail.domaine.tld, il faut également vérifier si plusieurs nœuds existent derrière un répartiteur de charge. Une mise à jour partielle laisse subsister un risque d’exploitation sur les nœuds oubliés, avec des symptômes intermittents difficiles à diagnostiquer.

Pour les organisations qui exploitent plusieurs environnements, la matrice minimale de suivi devrait inclure :

nom de l’instance ;
URL publique ;
version amont ou version de paquet ;
mode d’installation ;
hébergement concerné ;
correctif appliqué ou non ;
date de redéploiement ;
vérification post-patch réalisée.

En l’absence d’un inventaire fiable, il faut partir du principe que toute instance Internet-facing de Roundcube est prioritaire. C’est particulièrement vrai dans les contextes où le webmail est publié depuis des serveurs mutualisés, des VPS ou des instances cloud chez des hébergeurs français, car la découverte d’exposition est triviale via DNS, moteurs de scan et empreintes HTTP.

Vecteur d’attaque

Le vecteur d’attaque principal est l’interface webmail exposée sur Internet. Cette caractéristique change la manière de prioriser le risque : contrairement à une vulnérabilité touchant un composant interne non publié, Roundcube reçoit des requêtes depuis l’extérieur en continu, souvent sans filtrage fort, avec de multiples paramètres HTTP, des formulaires d’authentification, des traitements de messages, des uploads de pièces jointes et des interactions AJAX. Une faille exploitable via cette surface peut être sondée à distance, industrialisée, puis enchaînée avec d’autres faiblesses de configuration.

Le scénario le plus critique est celui d’une vulnérabilité permettant une exécution de code à distance sur le serveur hébergeant Roundcube. Selon la nature exacte de la faille, l’attaquant peut avoir besoin :

d’aucune authentification préalable ;
d’un compte utilisateur valide sur le webmail ;
d’inciter un utilisateur légitime à ouvrir un message ou une page spécifique ;
de combiner la faille avec une mauvaise configuration locale.

Même lorsqu’une authentification est requise, le risque reste élevé. Les comptes de messagerie sont des cibles fréquentes de réutilisation de mots de passe, de credential stuffing et de phishing. Une faille post-authentification sur un webmail exposé ne doit donc pas être sous-estimée. Dans beaucoup d’environnements, un simple compte utilisateur standard suffit à accéder à des fonctionnalités riches qui manipulent du HTML, des pièces jointes, des carnets d’adresses, des préférences et parfois des plugins.

Concrètement, plusieurs chemins d’impact sont envisageables :

RCE côté serveur : exécution de commandes sous l’identité du processus PHP-FPM ou du serveur web, avec accès potentiel aux fichiers de configuration, aux sessions et aux secrets applicatifs.
Vol de données : extraction de messages, d’adresses, de pièces jointes ou d’identifiants stockés dans la configuration.
Prise de contrôle de comptes : détournement de session, modification de préférences, règles de transfert ou filtres malveillants.
Pivot interne : usage de l’hôte compromis pour scanner le réseau, atteindre l’IMAP interne, le SMTP, une base de données ou d’autres applications du même serveur.
Abus de la réputation mail : utilisation de comptes compromis pour envoyer du phishing, contourner les contrôles anti-spam ou usurper la communication interne.

Le caractère stratégique de Roundcube vient aussi de sa place dans la chaîne de messagerie. Un serveur webmail compromis n’est pas toujours synonyme de contrôle complet du MTA, mais il donne souvent accès à des éléments très sensibles :

fichiers de configuration contenant des paramètres IMAP/SMTP et parfois des secrets ;
base de données de préférences utilisateurs ;
répertoire temporaire avec pièces jointes traitées ;
sessions PHP ;
journaux applicatifs utiles à l’attaquant pour comprendre l’environnement.

Exemples de chemins et artefacts fréquemment rencontrés :

/var/www/html/roundcube/
/var/lib/roundcube/
/etc/roundcube/config.inc.php
/usr/share/roundcube/
/var/log/apache2/access.log
/var/log/nginx/access.log
/var/log/php*-fpm.log

Du point de vue de l’attaquant, un webmail comme Roundcube est également intéressant pour sa discrétion. Une compromission peut produire des effets qui ressemblent à des usages normaux : consultation de messages, création de règles de transfert, envoi de mails, lecture de pièces jointes. Si l’attaque aboutit à une exécution de code, l’attaquant peut ensuite déposer un webshell, modifier un fichier applicatif ou créer une tâche de persistance avec un bruit réseau limité.

Un scénario d’attaque réaliste en environnement PME ou collectivité :

repérage de l’URL webmail via DNS public ou scan HTTP ;
identification de l’empreinte Roundcube par le titre de page, les ressources statiques ou les réponses HTTP ;
exploitation de la faille via une requête forgée ou via un compte utilisateur compromis ;
lecture de config.inc.php et récupération des paramètres de base de données ;
accès aux sessions ou aux préférences ;
mise en place de règles de transfert sur des comptes ciblés ;
utilisation du serveur compromis pour relayer des actions internes ou déployer une charge secondaire.

Exemple générique de requête à surveiller lorsqu’une tentative d’exploitation vise des paramètres applicatifs inhabituels :

POST /?_task=settings&_action=upload-display HTTP/1.1
Host: webmail.exemple.fr
User-Agent: curl/8.5.0
Content-Type: multipart/form-data; boundary=----

Le détail exact dépendra de la ou des CVE publiées, mais plusieurs signaux faibles sont communs aux campagnes visant des webmails :

hausse soudaine des requêtes POST vers des routes peu sollicitées en temps normal ;
user-agents non navigateurs sur des actions normalement initiées par l’interface ;
codes HTTP 500 ou 403 répétés sur des chemins applicatifs spécifiques ;
création ou modification de fichiers .php dans des répertoires non prévus ;
processus fils anormaux déclenchés par php-fpm ou apache2.

Cette alerte s’inscrit dans une tendance plus large : les clients webmail restent des cibles récurrentes parce qu’ils combinent exposition Internet, données à forte valeur et code applicatif complexe. Les vulnérabilités antérieures touchant des webmails ou des interfaces d’administration de messagerie ont montré que l’exploitation peut être rapide dès qu’un correctif public est disponible, car la phase de rétro-ingénierie du patch permet de produire des preuves de concept en peu de temps.

Impact

L’impact maximal annoncé est l’exécution de code à distance. Dans un contexte de sécurité opérationnelle, cela signifie qu’un attaquant peut potentiellement exécuter du code arbitraire sur le serveur hébergeant Roundcube, avec les privilèges du compte de service associé au serveur web ou à PHP-FPM. Même si ces privilèges sont limités, ils suffisent souvent à compromettre la confidentialité des messages, à altérer le fonctionnement du webmail et à préparer une élévation de privilèges locale si d’autres faiblesses sont présentes.

Les conséquences concrètes pour l’entreprise ou l’administration incluent :

lecture et exfiltration d’e-mails sensibles ;
vol de pièces jointes confidentielles ;
prise de contrôle de comptes utilisateurs ;
implantation de persistance sur le frontal webmail ;
utilisation du webmail comme relais de phishing interne ou externe ;
atteinte à la réputation du domaine de messagerie ;
risque réglementaire en cas de fuite de données personnelles ou stratégiques.

Pour un RSSI, il faut aussi considérer l’effet de second ordre : la messagerie reste un pivot de nombreuses chaînes d’authentification et de réinitialisation de mot de passe. Un attaquant qui contrôle des boîtes aux lettres ou des règles de transfert peut intercepter des liens de réinitialisation, surveiller des échanges contractuels, compromettre des workflows métiers et préparer des fraudes ciblées. Une faille Roundcube n’est donc pas seulement un incident applicatif ; elle peut devenir un incident de confiance numérique à l’échelle de l’organisation.

Dans les hébergements mutualisés, l’impact dépend fortement de l’isolation effective entre tenants. Une compromission limitée au vhost Roundcube peut déjà être grave, mais une mauvaise séparation des droits, des répertoires temporaires ou des processus peut élargir l’exposition. C’est une raison supplémentaire pour accélérer le correctif sur les plateformes partagées et interroger l’hébergeur sur l’état de remédiation.

Comment patcher

La mesure prioritaire est la mise à jour vers la version corrigée publiée par l’éditeur et référencée par le CERT-FR. Le bon réflexe n’est pas seulement de télécharger la dernière archive, mais de vérifier le mode d’installation existant afin d’appliquer un correctif cohérent et maintenable.

Cas 1 : installation depuis l’archive officielle Roundcube

Si Roundcube a été installé manuellement dans un répertoire web, il faut sauvegarder la configuration et les personnalisations, déployer la version corrigée, puis exécuter les éventuelles migrations de base de données prévues par l’éditeur.

cd /var/www
cp -a roundcube roundcube.bak-20260526
wget https://github.com/roundcube/roundcubemail/releases/download/<version-corrigee>/roundcubemail-<version-corrigee>-complete.tar.gz
tar xzf roundcubemail-<version-corrigee>-complete.tar.gz
rsync -a --delete roundcubemail-<version-corrigee>/ /var/www/roundcube/
chown -R www-data:www-data /var/www/roundcube/temp /var/www/roundcube/logs

Ensuite, vérifier le fichier de configuration principal :

/var/www/roundcube/config/config.inc.php

Si l’éditeur fournit un script de mise à jour de schéma, l’exécuter selon la documentation officielle. Selon les déploiements, cela peut prendre la forme d’un script SQL, d’un installateur web temporaire ou d’une commande PHP dédiée. Il faut ensuite redémarrer le serveur web ou le pool PHP-FPM si nécessaire.

systemctl reload nginx
systemctl reload apache2
systemctl reload php8.2-fpm

Cas 2 : Debian / Ubuntu via APT

Sur les systèmes basés sur APT, le nom de paquet peut varier selon la distribution et la version, par exemple roundcube, roundcube-core ou des paquets complémentaires. Vérifier d’abord la politique de version :

apt update
apt-cache policy roundcube roundcube-core

Appliquer ensuite la mise à jour de sécurité disponible :

apt install --only-upgrade roundcube roundcube-core

Sur certains environnements, une mise à jour plus large sera préférable pour intégrer les dépendances corrigées :

apt update && apt full-upgrade

Après installation, contrôler le changelog du paquet pour confirmer la prise en compte de la faille mentionnée par le CERT-FR :

zgrep -i "CVE\|Roundcube" /usr/share/doc/roundcube/changelog.Debian.gz

Cas 3 : RHEL / AlmaLinux / Rocky / Fedora via DNF

Sur les distributions utilisant DNF, le paquet peut être nommé roundcubemail ou de manière proche selon le dépôt activé.

dnf info roundcubemail
dnf upgrade roundcubemail

Pour vérifier l’historique et les correctifs appliqués :

rpm -q --changelog roundcubemail | grep -i "CVE\|security"

Cas 4 : déploiement via Composer ou pipeline CI/CD

Si Roundcube est intégré dans une chaîne de build, il faut mettre à jour la dépendance vers la version corrigée, reconstruire l’artefact puis redéployer :

composer show | grep roundcube
composer require roundcube/roundcubemail:<version-corrigee>
composer install --no-dev --prefer-dist

Dans ce cas, le point critique est la reproductibilité : l’image ou l’artefact déployé doit être reconstruit proprement, les caches invalidés, puis le déploiement propagé sur tous les nœuds.

Vérifications post-patch

Une mise à jour n’est complète qu’après contrôle fonctionnel et sécurité :

connexion utilisateur réussie ;
lecture et envoi de message opérationnels ;
accès aux pièces jointes et préférences conforme ;
absence d’erreurs nouvelles dans les logs ;
version corrigée confirmée sur chaque nœud ;
suppression des fichiers d’installation ou de migration laissés temporairement accessibles.

Exemples de contrôles utiles :

curl -I https://webmail.exemple.fr/
tail -f /var/log/nginx/error.log
tail -f /var/log/apache2/error.log
tail -f /var/log/php8.2-fpm.log

Mitigation

Si le correctif ne peut pas être appliqué immédiatement, il faut réduire l’exposition sans attendre. Ces mesures ne remplacent pas le patch, mais elles peuvent diminuer la fenêtre d’attaque.

1. Restreindre l’exposition Internet

Si le webmail n’a pas besoin d’être accessible publiquement à tous, limiter l’accès par filtrage réseau, VPN, liste d’IP autorisées ou reverse proxy avec authentification forte. Pour certaines populations internes, publier Roundcube uniquement derrière un accès d’entreprise réduit fortement le risque d’exploitation opportuniste.

Exemple nginx avec restriction d’IP :

location / {
  allow 198.51.100.0/24;
  allow 203.0.113.10;
  deny all;
}

2. Activer ou durcir le WAF et les règles de filtrage HTTP

Un WAF ne corrigera pas la vulnérabilité, mais peut bloquer des charges triviales, des séquences connues ou des patterns d’exploitation massifs. Les équipes disposant de ModSecurity, d’un reverse proxy applicatif ou d’une protection managée chez leur hébergeur doivent déployer des règles temporaires ciblant les routes et paramètres identifiés par l’advisory.

3. Désactiver les fonctionnalités ou plugins non indispensables

Si la vulnérabilité implique un composant particulier, désactiver temporairement le plugin ou la fonctionnalité concernée. Beaucoup d’instances Roundcube accumulent des extensions historiques peu maintenues. C’est souvent un angle de risque sous-estimé.

Dans la configuration, vérifier notamment :

$config['plugins'] = [];

ou retirer explicitement les plugins non essentiels avant redémarrage du service.

4. Renforcer l’isolation du processus web

En attendant le patch, il est utile de limiter les conséquences d’une éventuelle compromission :

désactiver les fonctions PHP dangereuses si elles ne sont pas nécessaires ;
restreindre les droits d’écriture aux seuls répertoires temp et logs ;
séparer le pool PHP-FPM de Roundcube ;
interdire l’exécution de scripts dans les répertoires d’upload et temporaires ;
mettre en place open_basedir ou des mécanismes d’isolation comparables lorsque c’est compatible.

Exemple de règle nginx pour empêcher l’exécution dans un répertoire temporaire exposé par erreur :

location ^~ /temp/ {
deny all;
return 403;
}

5. Réduire la portée d’un compte compromis

Si la faille nécessite une authentification, renforcer temporairement les contrôles d’accès : MFA en amont si disponible, politique de mots de passe, surveillance des connexions anormales, verrouillage des comptes exposés à des campagnes de phishing. Le bénéfice est double : limiter l’exploitation directe et réduire les scénarios d’enchaînement avec des identifiants déjà volés.

Détection

La détection doit se concentrer sur trois axes : traces HTTP, activité système sur l’hôte webmail, et signaux métier côté messagerie.

Indicateurs de compromission potentiels

requêtes inhabituelles vers des actions Roundcube rarement utilisées ;
pics de POST ou de réponses 500 sur l’interface webmail ;
création récente de fichiers .php, .phtml ou .phar dans l’arborescence web ;
modification de config.inc.php ou de fichiers de plugin ;
processus shell enfants lancés par www-data, apache ou nginx ;
connexions sortantes inattendues depuis l’hôte webmail ;
création de règles de transfert mail non autorisées ;
envois de messages inhabituels depuis des comptes utilisateurs légitimes.

Recherches rapides côté système :

find /var/www/roundcube -type f $ -name "*.php" -o -name "*.phtml" $ -mtime -7 -ls
grep -R "base64_decode\|shell_exec\|system(" /var/www/roundcube 2>/dev/null
ps -ef | egrep "php-fpm|apache2|nginx|sh|bash|curl|wget"
ss -tpn

Recherches dans les logs HTTP :

grep -i "roundcube\|webmail" /var/log/nginx/access.log | tail -n 200
awk '$9 ~ /500|403/ {print}' /var/log/nginx/access.log | tail -n 200
grep -E "POST .*(_task|_action|upload|compose|settings)" /var/log/apache2/access.log | tail -n 200

Surveiller également les journaux applicatifs de Roundcube s’ils sont activés :

/var/www/roundcube/logs/
/var/log/roundcube/

Côté messagerie, les IoC métier sont souvent déterminants :

règles de transfert vers des domaines externes récemment créées ;
connexions webmail depuis des pays ou AS inhabituels ;
augmentation de l’envoi SMTP depuis certains comptes ;
consultation de boîtes VIP à des horaires atypiques ;
ouvertures massives de messages avec pièces jointes sensibles.

Si des indices sérieux d’exploitation apparaissent, la réponse doit inclure :

isolation du frontal Roundcube ;
collecte des journaux et de l’image système si nécessaire ;
rotation des secrets applicatifs et des mots de passe administratifs ;
révocation des sessions ;
audit des règles de messagerie ;
vérification de l’intégrité des fichiers applicatifs ;
contrôle des accès à la base de données associée.

Dans les contextes réglementés ou sensibles, une coordination avec le CERT-FR ou le dispositif de réponse à incident interne est pertinente, en particulier si des signes d’exfiltration ou de compromission de comptes stratégiques sont observés.

Perspective écosystème et priorisation

Les failles touchant Roundcube doivent être priorisées haut dans les plans de remédiation, au même niveau que les vulnérabilités critiques affectant les VPN, les passerelles de sécurité ou les interfaces d’administration exposées. La raison est structurelle : un webmail est à la fois un point d’accès public et un concentrateur d’information. Pour les équipes françaises, cette priorisation est d’autant plus importante que de nombreuses organisations conservent encore des déploiements historiques auto-hébergés, parfois peu documentés, parfois intégrés à des stacks LAMP anciennes.

Par comparaison avec d’autres incidents applicatifs récents, les vulnérabilités de webmail présentent trois particularités :

elles sont faciles à repérer depuis Internet ;
elles touchent directement des flux de communication critiques ;
elles peuvent rester discrètes longtemps si la surveillance se limite à l’infrastructure et pas aux usages de messagerie.

Les RSSI ont donc intérêt à formaliser une règle simple de gouvernance : toute alerte critique sur un composant de messagerie exposé déclenche un cycle court d’inventaire, qualification, patching, vérification et chasse aux IoC. Cette discipline est plus efficace que la réaction au cas par cas, surtout dans les environnements hybrides mêlant serveurs internes, cloud, hébergement infogéré et mutualisé.

Pour les administrateurs et équipes DevOps, l’événement rappelle aussi l’importance de quelques bonnes pratiques durables : séparation des rôles, suppression des plugins inutiles, journalisation exploitable, supervision des changements de fichiers, rotation des secrets, et pipelines de mise à jour reproductibles. Sur ce point, des mesures de durcissement complémentaires sont à retrouver dans les ressources de la catégorie /categorie/pratiques, utiles pour réduire l’impact d’une future vulnérabilité même lorsqu’un correctif n’est pas encore déployé.

En pratique, toute instance Roundcube exposée sur Internet doit être vérifiée immédiatement, mise à jour vers la version de sécurité indiquée par l’éditeur et le CERT-FR, puis contrôlée côté logs, intégrité et activité messagerie. Pour les organisations qui ne peuvent pas corriger dans l’heure, la réduction d’exposition, le filtrage d’accès et la chasse aux indicateurs de compromission sont les mesures prioritaires. Les équipes qui exploitent des infrastructures chez OVHcloud, o2switch, Scaleway ou via des prestataires managés gagneront à demander une confirmation écrite de l’état de remédiation et des versions déployées. Au-delà de l’urgence, ce type d’alerte rappelle qu’un webmail n’est pas un simple service de confort, mais un actif critique qui mérite le même niveau de rigueur qu’une passerelle d’accès distante, avec une hygiène de patching et de hardening continue à consolider via les recommandations de /categorie/pratiques.

Serveurs

Retour aux actualités