Redmine : failles multiples dont RCE à corriger sans attendre

Le CERT-FR a publié le 16 juin 2026 un avis intitulé « Multiples vulnérabilités dans Redmine », signalant plusieurs failles affectant la plateforme de gestion de projet auto-hébergée Redmine. Selon le bulletin, certaines de ces vulnérabilités peuvent conduire à une exécution de code arbitraire à distance, avec un impact potentiellement critique pour les organisations qui utilisent Redmine comme brique centrale de pilotage projet, de suivi d’incidents, de documentation interne ou d’intégration avec d’autres outils d’entreprise.

Le risque est particulièrement concret dans les environnements où Redmine est exposé sur Internet, connecté à un annuaire, intégré à des dépôts Git, à des systèmes de tickets ou à des chaînes CI/CD. Dans ce type d’architecture, la compromission d’une instance ne se limite pas à l’application elle-même : elle peut devenir un point d’appui vers des données sensibles, des secrets techniques, des dépôts de code, des webhooks internes, voire des comptes d’administration. L’avis du CERT-FR relaie l’existence de mises à jour de sécurité publiées par l’éditeur, à appliquer rapidement.

À ce stade, l’élément essentiel pour les équipes d’exploitation, d’administration système et de sécurité applicative est simple : toute instance Redmine concernée par l’avis du 16 juin 2026 doit être considérée comme prioritaire au patching. Lorsque des vulnérabilités multiples incluent un scénario de RCE, l’évaluation ne doit pas se limiter au seul score CVSS. Même en l’absence d’exploitation observée publiquement au moment de la publication, la combinaison d’une large base installée, d’instances parfois exposées directement et d’un logiciel historiquement enrichi par plugins augmente la surface d’attaque.

La source de référence à retenir est l’avis officiel du CERT-FR, qui pointe vers les informations de l’éditeur Redmine et les correctifs de sécurité associés. Lorsqu’un doute subsiste sur la branche exacte déployée, la bonne pratique consiste à vérifier immédiatement la version en production, à identifier la branche de maintenance applicable, puis à planifier une mise à jour vers la version corrigée publiée par l’éditeur.

Versions affectées

L’avis du CERT-FR du 16 juin 2026 indique que des instances Redmine sont affectées par de multiples vulnérabilités. La source transmise ici ne détaille pas de façon fiable, dans le brief, l’ensemble des branches exactes vulnérables ni la liste des numéros de versions corrigées. Dans un contexte de sécurité, il est préférable de ne pas inventer une matrice de versions.

Les équipes doivent donc s’appuyer sur les références officielles de l’éditeur Redmine associées à l’avis CERT-FR pour confirmer :

la ou les branches de maintenance concernées ;
les versions vulnérables de chaque branche ;
la version corrigée publiée par l’éditeur pour chaque branche encore maintenue ;
les éventuelles branches en fin de vie qui ne reçoivent plus de correctif.

Concrètement, il faut vérifier la version actuellement déployée sur chaque nœud applicatif, conteneur ou VM hébergeant Redmine. Selon le mode d’installation, cette vérification peut se faire via l’interface d’administration, par inspection du code applicatif ou par la chaîne Ruby/Bundler utilisée au déploiement.

Exemples de vérification côté hôte :

cd /opt/redmine
bundle exec rails runner "puts Redmine::VERSION.to_s"

Ou, selon l’organisation du déploiement :

grep -R "Redmine::VERSION" -n /opt/redmine

Dans un environnement conteneurisé :

docker exec -it redmine-app bundle exec rails runner "puts Redmine::VERSION.to_s"

Pour les équipes qui gèrent plusieurs instances, il est utile d’inventorier :

les instances Internet-facing ;
les instances accessibles via VPN ou extranet partenaires ;
les environnements de préproduction clonés depuis la production ;
les nœuds oubliés ou anciens, parfois hébergés chez OVH, Scaleway, o2switch ou sur une infrastructure interne ;
les plugins tiers installés, qui peuvent compliquer la mise à jour ou ajouter leur propre surface d’attaque.

Concernant les identifiants de vulnérabilité, l’avis du CERT-FR mentionne des multiples vulnérabilités. Si des CVE et des scores CVSS sont publiés dans l’advisory éditeur, ils doivent être repris depuis cette source officielle dans vos procédures internes, votre ticket de remédiation et votre communication RSSI. En l’absence de détail confirmé ici, il ne faut pas attribuer de CVE ou de score de manière spéculative.

Point important pour les environnements d’entreprise : si une branche Redmine n’est plus maintenue par l’éditeur, il ne suffit pas d’attendre un hypothétique correctif. Il faut alors envisager une montée de version vers une branche supportée, avec validation applicative et compatibilité des plugins. Les plateformes de gestion de projet ont souvent une longue durée de vie et deviennent, au fil des ans, des applications « critiques mais peu modernisées ». C’est précisément ce profil qui crée un angle mort de sécurité.

Vecteur d’attaque

D’après l’avis CERT-FR, les vulnérabilités affectant Redmine incluent des scénarios pouvant mener à une exécution de code arbitraire. Sans extrapoler au-delà de la source, cela signifie qu’un attaquant peut potentiellement exploiter un défaut applicatif pour faire exécuter des instructions non prévues par l’application sur le serveur hébergeant Redmine, avec les privilèges du processus applicatif ou d’un composant connexe.

Sur une plateforme comme Redmine, le vecteur d’attaque doit être analysé de façon réaliste, à partir de son usage quotidien :

exposition directe de l’interface web sur Internet ;
accès par des prestataires, partenaires ou sous-traitants ;
présence de comptes à privilèges élevés rarement révisés ;
intégration à la messagerie, à des dépôts de code, à des outils CI/CD ;
stockage de pièces jointes, exports, documents projet et journaux d’activité ;
installation de plugins métiers parfois anciens.

Dans ce contexte, plusieurs scénarios d’attaque plausibles émergent, même sans disposer d’un détail public complet sur chaque vulnérabilité :

Compromission d’une instance exposée sur Internet

Le scénario le plus direct est l’exploitation à distance d’une faille applicative sur une instance accessible publiquement. Si l’attaque ne nécessite pas d’authentification, le risque est maximal : un simple repérage automatisé des bannières, des pages de connexion ou des empreintes HTML peut suffire à identifier des cibles vulnérables.

Si l’exploitation requiert un compte authentifié, le risque reste élevé dans les organisations où :

des comptes de démonstration, de stagiaires ou de prestataires subsistent ;
l’authentification multifacteur n’est pas activée en frontal ;
l’accès est ouvert à un grand nombre d’utilisateurs externes ;
les politiques de mot de passe sont faibles ou hétérogènes.

Pivot depuis l’application vers le système

Une RCE sur Redmine n’est pas seulement une faille « web ». Une fois l’exécution de code obtenue, l’attaquant peut chercher à :

lire les fichiers de configuration de l’application ;
extraire les secrets présents dans config/database.yml, des variables d’environnement ou un coffre mal cloisonné ;
accéder à la base de données ;
récupérer des jetons d’API, webhooks ou identifiants de services tiers ;
explorer le système de fichiers pour des sauvegardes, archives, exports ou clés privées ;
établir une persistance locale si l’hôte n’est pas durci.

Dans bien des déploiements, Redmine tourne derrière Apache, Nginx ou Passenger, parfois avec des droits plus larges que nécessaire, sur un serveur qui héberge aussi d’autres composants. Le niveau de cloisonnement réel détermine alors l’ampleur de l’incident.

Atteinte à la confidentialité des projets

Même en dehors d’une RCE pleinement exploitée, des vulnérabilités multiples peuvent permettre la fuite de données projet. Dans un Redmine d’entreprise, cela peut inclure :

des tickets d’incident contenant des informations de production ;
des documents contractuels ou techniques ;
des plans de migration, schémas d’architecture, procédures d’exploitation ;
des identifiants copiés dans des commentaires ou pièces jointes ;
des informations RH ou juridiques si l’outil est détourné de son usage initial.

Le danger est souvent sous-estimé car Redmine est perçu comme un simple outil de suivi. En pratique, il concentre souvent des données de contexte très utiles à un attaquant : noms d’hôtes, URL internes, noms d’équipes, organisation des projets, dépendances métiers, chronologie des incidents, et parfois même les contournements temporaires mis en place sur d’autres systèmes.

Chaîne d’attaque via plugins et personnalisation

Les déploiements auto-hébergés de Redmine sont fréquemment personnalisés. Cette réalité complique la gestion du risque :

des plugins peuvent ne plus être maintenus ;
des thèmes ou extensions peuvent casser lors d’une montée de version ;
des monkey patches Ruby peuvent masquer des comportements inattendus ;
des intégrations maison peuvent s’appuyer sur des API ou hooks internes.

Dans un incident réel, l’attaquant n’a pas besoin que chaque maillon soit vulnérable. Il lui suffit d’un premier accès, puis d’un environnement permissif. Une faille Redmine peut donc jouer le rôle de porte d’entrée dans une chaîne plus large.

Exposition indirecte par reverse proxy ou publication sélective

Beaucoup d’organisations considèrent leur Redmine « non exposé » car il est derrière un reverse proxy, un WAF ou une liste d’adresses IP autorisées. Cette confiance peut être trompeuse :

une publication partielle via extranet reste une exposition ;
un VPN partenaire compromis rend l’instance accessible ;
un proxy mal configuré peut transmettre des en-têtes inattendus ;
des environnements de test sont parfois plus ouverts que la production.

Pour un RSSI ou un responsable d’exploitation, l’évaluation correcte n’est donc pas « Internet ou pas Internet », mais plutôt : qui peut atteindre l’application, avec quel niveau d’authentification, et quelles données ou privilèges deviennent accessibles en cas de compromission.

Impact

L’impact principal mis en avant par le CERT-FR est la possibilité d’une exécution de code arbitraire. Pour une instance Redmine d’entreprise, cela signifie qu’un attaquant peut potentiellement compromettre :

le serveur applicatif lui-même ;
les données de projets stockées dans la base et les pièces jointes ;
les comptes utilisateurs de l’application ;
les intégrations avec d’autres services ;
la confiance opérationnelle dans les workflows de suivi d’activité et d’incident.

Dans un cas défavorable, la compromission peut déboucher sur :

l’exfiltration de données sensibles ;
la modification de tickets ou de journaux d’activité ;
la suppression de pièces jointes ou de projets ;
l’ajout de comptes administrateurs ;
l’utilisation du serveur comme relais vers d’autres cibles internes.

Pour les équipes SOC et IR, il faut aussi considérer l’impact sur la fiabilité des traces. Si l’attaquant obtient un accès applicatif ou système suffisant, il peut altérer des journaux, brouiller la chronologie ou supprimer certains artefacts. D’où l’importance de disposer de logs centralisés hors du serveur Redmine, par exemple vers une pile de collecte dédiée.

Enfin, la criticité métier d’un Redmine est souvent supérieure à ce qu’indique son exposition apparente. Une indisponibilité ou une compromission pendant une crise de production, une migration majeure ou un audit réglementaire peut perturber la coordination des équipes et ralentir la réponse à incident. La faille ne menace donc pas uniquement la confidentialité, mais aussi la capacité de pilotage opérationnel.

Comment patcher

La recommandation prioritaire est d’appliquer la mise à jour de sécurité publiée par l’éditeur Redmine pour la branche concernée, conformément aux références relayées par le CERT-FR. Comme le détail exact des versions corrigées n’est pas fourni dans le brief, il faut se référer à l’advisory officiel de l’éditeur avant exécution en production.

La méthode de remédiation dépend du mode d’installation.

Déploiement depuis les sources ou dépôt Git interne

Si Redmine est déployé depuis les sources, la pratique courante consiste à basculer vers le tag ou la version corrigée, puis à réinstaller les dépendances Ruby et exécuter les tâches de migration nécessaires.

cd /opt/redmine
git fetch --tags
git checkout <version_corrigee_editeur>
bundle config set without 'development test'
bundle install
bundle exec rake db:migrate RAILS_ENV=production
bundle exec rake tmp:cache:clear RAILS_ENV=production
bundle exec rake tmp:sessions:clear RAILS_ENV=production

Après la mise à jour, il faut redémarrer le service applicatif ou le conteneur concerné. Selon la pile :

systemctl restart redmine
systemctl restart apache2
systemctl restart nginx

Ou avec un serveur applicatif Ruby spécifique :

systemctl restart puma
systemctl restart passenger

Les noms de services varient selon l’intégration locale. Il faut utiliser les unités réellement déployées sur vos hôtes.

Déploiement conteneurisé

Si Redmine est exécuté via image conteneur, la remédiation consiste à tirer l’image correspondant à la version corrigée, mettre à jour le manifeste puis redéployer.

docker pull redmine:<version_corrigee_editeur>
docker compose down
docker compose up -d

Dans un cluster orchestré :

kubectl set image deployment/redmine redmine=redmine:<version_corrigee_editeur>
kubectl rollout status deployment/redmine

Avant redéploiement, vérifier la persistance des volumes, la compatibilité des plugins et le plan de rollback.

Paquets système ou packaging distribution

Lorsque Redmine est installé depuis les paquets de la distribution ou d’un dépôt tiers, il faut utiliser le gestionnaire de paquets de l’OS. La commande exacte dépend de la source logicielle réellement utilisée :

apt update
apt install --only-upgrade redmine

dnf upgrade redmine

Attention : dans de nombreux environnements, les paquets redmine fournis par la distribution peuvent être en décalage avec les versions amont, ou ne pas proposer immédiatement le correctif. Il faut confirmer que le paquet proposé contient bien la version corrigée publiée par l’éditeur ou un backport de sécurité explicitement documenté.

Vérifications post-patch

Une mise à jour de sécurité ne s’arrête pas au redémarrage du service. Les contrôles suivants sont recommandés :

vérifier la version effective exposée ;
tester l’authentification, les projets, les pièces jointes et les workflows critiques ;
valider le fonctionnement des plugins indispensables ;
contrôler les journaux applicatifs et reverse proxy après redémarrage ;
surveiller la charge, les erreurs 5xx et les exceptions Ruby.

Exemples de vérifications :

curl -I https://redmine.exemple.tld/login
journalctl -u redmine -n 200
journalctl -u nginx -n 200

Si l’instance est exposée derrière un équilibreur, il faut aussi valider les checks de santé et le comportement en montée progressive du trafic.

Gestion du risque plugin

Le principal frein au patching rapide de Redmine est souvent la peur de casser un plugin métier. Dans ce cas, la bonne approche n’est pas de repousser indéfiniment la mise à jour, mais de :

cloner la production en préproduction ;
tester la version corrigée avec l’ensemble des plugins ;
désactiver temporairement les extensions non critiques si nécessaire ;
documenter les écarts et planifier la remise en conformité.

En présence d’une faille pouvant mener à une RCE, la priorité sécurité doit rester élevée. Un plugin temporairement désactivé a souvent un coût inférieur à une compromission serveur.

Mitigation

Si le correctif ne peut pas être appliqué immédiatement, des mesures de réduction de surface doivent être mises en place sans attendre. Elles ne remplacent pas le patch, mais peuvent réduire la probabilité d’exploitation ou limiter l’impact.

Réduire l’exposition réseau

restreindre l’accès à Redmine via VPN, bastion ou liste d’adresses IP autorisées ;
désactiver toute exposition publique non indispensable ;
fermer les environnements de test ou de recette clonés depuis la production ;
placer l’application derrière un reverse proxy strictement configuré.

Sur des plateformes hébergées chez un fournisseur cloud ou un hébergeur mutualisé, vérifier les groupes de sécurité, ACL, règles de firewall et publications automatiques. Une instance oubliée chez OVH ou Scaleway, ou un sous-domaine de test encore résolu publiquement, suffit à annuler les efforts faits sur la production principale.

Limiter les privilèges applicatifs et système

faire tourner Redmine avec un compte de service dédié, non privilégié ;
restreindre les permissions sur config/, les sauvegardes et les répertoires de pièces jointes ;
isoler la base de données et interdire les accès réseau inutiles ;
éviter la cohabitation avec d’autres services sensibles sur le même hôte.

Si une RCE est exploitée, le niveau de cloisonnement détermine la suite de l’incident. Un service exécuté avec des droits minimaux, sans accès shell étendu, sans secrets en clair et sans voisinage applicatif sensible, réduit fortement la gravité pratique.

Durcir le frontal web

Sans prétendre bloquer une exploitation complexe, certaines mesures de frontalisation restent utiles :

journalisation détaillée des requêtes HTTP ;
limitation de débit sur les points d’entrée sensibles ;
blocage des méthodes HTTP non nécessaires ;
surveillance des réponses anormales, erreurs répétées et charges inhabituelles ;
activation d’un WAF si déjà maîtrisé opérationnellement.

Exemple de journalisation utile côté Nginx :

log_format redmine_ext '$remote_addr - $remote_user [$time_local] '
                       '"$request" $status $body_bytes_sent '
                       '"$http_referer" "$http_user_agent" '
                       'rt=$request_time ua="$upstream_addr" us="$upstream_status"';
access_log /var/log/nginx/redmine_access.log redmine_ext;

Ce niveau de détail aide à reconstituer un enchaînement de requêtes suspectes, notamment si un attaquant tente plusieurs variantes d’exploitation.

Détection

En l’absence d’IoC publics détaillés fournis dans le brief, la détection doit se concentrer sur les signaux faibles d’exploitation applicative et les indicateurs post-compromission. Il faut surveiller à la fois les logs web, les logs applicatifs Ruby/Rails, le système et la base de données.

Indicateurs à rechercher dans les journaux HTTP

pics de requêtes vers des routes peu utilisées ;
enchaînements de requêtes en erreur 400, 403, 404 ou 500 depuis une même source ;
requêtes contenant des paramètres anormalement longs ou encodés ;
variations inhabituelles des méthodes HTTP ;
accès depuis des plages géographiques inattendues pour l’organisation ;
activité sur l’interface d’administration en dehors des créneaux normaux.

Exemples de recherches simples :

grep ' 500 ' /var/log/nginx/redmine_access.log | tail -n 100
grep -E 'POST|PUT|PATCH' /var/log/nginx/redmine_access.log | tail -n 200

Indicateurs côté application

exceptions Ruby inhabituelles dans les journaux de production ;
création inattendue de comptes ou élévation de privilèges ;
modification de paramètres globaux ;
ajout ou changement de webhooks, intégrations ou dépôts ;
suppression ou altération de tickets, journaux ou pièces jointes.

Chemins fréquemment inspectés selon le déploiement :

/opt/redmine/log/production.log
/var/log/redmine/
config/database.yml
files/

Indicateurs système d’une exploitation réussie

processus fils inattendus lancés par l’utilisateur du service Redmine ;
connexions sortantes inhabituelles depuis le serveur applicatif ;
création de fichiers temporaires suspects ;
tâches planifiées non autorisées ;
modification des permissions sur des répertoires applicatifs ;
archives ou dumps de base de données générés hors procédure normale.

Exemples de contrôles :

ps auxf
ss -plant
find /tmp -type f -mtime -2
find /opt/redmine -type f -mtime -2

Réponse en cas de doute

Si une tentative d’exploitation ou une compromission est suspectée :

isoler l’instance du réseau si possible ;
préserver les journaux et une image système si la procédure interne le prévoit ;
faire pivoter les secrets accessibles par l’application ;
réinitialiser les comptes administrateurs et revoir les sessions ;
contrôler les intégrations externes et les webhooks ;
rechercher un mouvement latéral vers la base, le Git, la messagerie ou la CI/CD.

Pour les organisations françaises, un signalement ou une coordination avec les dispositifs adaptés peut être pertinent selon la gravité et le périmètre, en complément des recommandations du CERT-FR et de vos obligations sectorielles.

Priorisation opérationnelle pour les admins et DevOps

Toutes les instances ne portent pas le même risque, même si elles doivent être corrigées. Pour prioriser efficacement, l’ordre suivant est généralement le plus rationnel :

instances Redmine exposées sur Internet ;
instances accessibles à des tiers externes ;
instances contenant des projets sensibles ou des pièces jointes critiques ;
instances connectées à des dépôts de code, annuaires ou outils de déploiement ;
instances anciennes avec plugins non maintenus ;
environnements de test oubliés mais accessibles.

Cette priorisation doit être complétée par une revue de surface :

l’application est-elle derrière un SSO ou un simple formulaire local ;
les journaux sont-ils centralisés ;
les sauvegardes sont-elles protégées ;
les secrets sont-ils externalisés ou stockés localement ;
le compte système Redmine a-t-il des droits excessifs ;
un plan de restauration propre existe-t-il en cas de compromission.

Redmine reste très présent en entreprise parce qu’il est stable, connu des équipes, simple à auto-héberger et souvent déjà intégré aux habitudes de travail. C’est précisément pour cette raison qu’il mérite une vigilance particulière : une application ancienne, utile, personnalisée et rarement remise à plat devient un actif à forte valeur pour un attaquant.

La référence principale à suivre est l’avis officiel du CERT-FR du 16 juin 2026, « Multiples vulnérabilités dans Redmine », ainsi que l’advisory de sécurité publié par l’éditeur Redmine. Les équipes qui administrent des plateformes auto-hébergées ont intérêt à traiter ce correctif comme une opération prioritaire, puis à profiter de la fenêtre de maintenance pour revoir le durcissement global, la journalisation et la réduction de surface. Pour aller plus loin sur l’hygiène de configuration, le cloisonnement et les bonnes pratiques de durcissement, voir aussi la catégorie /categorie/pratiques.