Redmine : l'ANSSI relaie des correctifs 6.1.5 et 7.0.2 (AVI-1245)

L'ANSSI relaie dans l'avis CERTFR-2026-AVI-1245 (1er octobre 2026) un lot de vulnérabilités corrigées dans Redmine, le gestionnaire de projets et de tickets très répandu dans les équipes de développement. Impacts annoncés : atteinte à la confidentialité des données et injection de code indirecte à distance (XSS). L'avis CERT-FR ne cite pas d'identifiants CVE ; le détail se trouve dans le bulletin de sécurité Redmine publié le même jour.

Versions affectées

Selon l'avis CERT-FR :

• Redmine 6.1.x antérieures à 6.1.5
• Redmine 7.x antérieures à 7.0.2

Correctifs disponibles en 6.1.5 et 7.0.2.

Ce que corrigent les bulletins Redmine

D'après les advisories publiés sur redmine.org, les correctifs couvrent notamment :

• Fuite de projets privés via l'API REST — les noms de projets privés et les affectations de rôles remontaient via GET /groups/<id>.json?include=memberships.
• Fuite de sujets de tickets privés — les sujets de tickets privés ou invisibles étaient exposés via le paramètre include=children de l'API REST.
• XSS basé sur le DOM — déclenché par un collage HTML depuis le presse-papiers (branche 7.0.x).
• Contournement d'autorisation sur les projets enfants — les mises à jour de inherit_members contournaient le contrôle d'accès à la gestion des membres.

Les deux fuites d'informations touchent l'API REST : si vous exposez l'API Redmine, elles sont exploitables par tout compte disposant d'un jeton valide, sans privilège d'administration.

État de l'exploitation

L'avis ne mentionne pas d'exploitation active ni de PoC public. La priorité tient à la surface : une instance Redmine est fréquemment exposée sur Internet ou sur un réseau interne large, et l'API REST y est souvent activée par défaut.

Que faire

1. Mettre à jour Redmine vers 6.1.5 ou 7.0.2 selon la branche en production.
2. Auditer l'exposition de l'API REST : si elle n'est pas nécessaire en externe, restreindre son accès au réseau de confiance.
3. Revoir les jetons d'API actifs — les deux fuites d'informations supposent un compte authentifié ; révoquer les jetons inutilisés.
4. Reconstruire les images embarquant Redmine plutôt que de patcher à chaud sur les parcs conteneurisés.

Contexte

Redmine est un cas classique d'outil interne « de confiance » exposé plus largement que prévu : instance partagée entre équipes, API ouverte pour l'intégration CI, comptes de service à jetons longue durée. Les deux fuites via l'API REST ne cassent pas l'authentification — elles contournent le cloisonnement entre projets, ce qui est précisément ce qu'une instance multi-équipes est censée garantir. La mise à jour est simple ; l'audit de l'exposition de l'API l'est moins, et c'est là que se joue le risque réel.