CVE-2026-76578 : un client LDAP anonyme est « personne », et « personne » suffit pour devenir admin FreeIPA

Rapport CTI technique du 9 septembre 2026

Résumé exécutif

Red Hat a publié le 8 septembre 2026 une chaîne de deux vulnérabilités qui permet à un client LDAP n'ayant jamais authentifié de créer une identité Kerberos de son choix dans un domaine FreeIPA, et de se retrouver membre du groupe des administrateurs. La faille FreeIPA, CVE-2026-76578, est notée critique avec un score CVSS provisoire de 9.8. Elle ne fonctionne qu'en combinaison avec CVE-2026-76560, un défaut du moteur de contrôle d'accès de 389 Directory Server noté 7.5. Red Hat indique avoir reproduit la chaîne deux fois sur une installation par défaut, la dernière fois depuis une machine sans aucun accès préalable. FreeIPA a corrigé sa moitié dans la version 4.13.4.

Le mécanisme est d'une simplicité qui devrait faire réfléchir toute équipe qui audite des ACL. 389-ds propose un type de règle censé signifier « seulement le propriétaire authentifié de cette entrée ». La comparaison se fait en texte brut entre le nom du client et une valeur stockée. Un client non authentifié a un nom vide. Une entrée créée avec un champ de propriété vide correspond donc à ce nom vide, et le contrôle passe. FreeIPA embarque par défaut une ACI de cette forme exacte, celle qui laisse un utilisateur gérer son propre jeton OTP, sans exiger d'authentification préalable et sans limiter ce qui peut être écrit à côté du jeton. Un attaquant écrit donc une identité Kerberos et un mot de passe dans la foulée. Aucune exploitation en conditions réelles n'a été signalée à ce jour, et aucun indicateur ni règle de détection n'a été publié.

Chronologie

Fiche vulnérabilité

CVE-2026-76578 | CVSS 9.8 (critique, score provisoire) | FreeIPA, distribué par Red Hat sous le nom Identity Management, paquet ipa

Écriture non authentifiée dans l'annuaire aboutissant à la création d'une identité Kerberos arbitraire et à l'appartenance au groupe des administrateurs. FreeIPA livre une ACI destinée à laisser un utilisateur gérer son propre jeton à usage unique. Cette règle n'exige pas que le client se soit authentifié, et elle ne restreint pas ce qui peut être écrit en même temps que le jeton.

Conditions d'exploitation : accès réseau au service LDAP de l'annuaire, ports 389 ou 636, et binds anonymes autorisés. Red Hat précise que l'identité injectée ne doit pas déjà exister. Le projet FreeIPA formule le résultat plus prudemment que Red Hat : le correctif de CVE-2026-13097 empêche la reprise de comptes existants, et l'attaque « peut être utilisée comme un tremplin » vers des privilèges administratifs. Red Hat, lui, parle d'appartenance réelle au groupe des administrateurs et d'identifiants administrateur réutilisables. La divergence porte sur la qualification, pas sur la primitive.

Pour les déploiements utilisant des identifiants de sécurité de type Windows, Red Hat indique que l'attaquant peut de surcroît obtenir un ticket Kerberos contenant les données d'autorisation, ce qui étend l'accès aux services HTTP et Dogtag du serveur. Dogtag est l'autorité de certification intégrée de FreeIPA : un accès à ce composant ouvre la voie à l'émission de certificats, donc à une persistance qui survit à une rotation de mots de passe.

PoC disponible : non publié. Red Hat indique avoir exécuté la chaîne contre une image conteneur FreeIPA en version 4.13.1 et avoir vérifié le résultat avec des commandes réservées aux administrateurs, plutôt qu'en se fiant à la sortie de l'exploit. Aucun code n'accompagne les advisories.

Patch : FreeIPA 4.13.4, qui corrige les deux failles FreeIPA. Les notes de version ne portent pas de date et n'indiquent pas quelles versions antérieures sont affectées.

CVE-2026-76560 | CVSS 7.5 | 389 Directory Server

Le moteur de contrôle d'accès compare le nom du client à une valeur stockée en texte brut. Un client non authentifié présente un nom vide, qui correspond à une valeur stockée vide. Red Hat a reproduit le défaut sur une compilation 389-ds simple, sans aucun composant FreeIPA installé, et un test de contrôle avec une valeur non vide a bien été refusé. Le défaut est donc dans le moteur d'ACL, pas dans ce que fait FreeIPA. Red Hat Directory Server ne livre par défaut aucune règle de cette forme : isolément, la faille ne concerne que les déploiements ayant écrit une telle règle. FreeIPA est exactement ce cas.

CVE-2026-79678 | CVSS 8.1 (important) | FreeIPA, commande idp-add

Faille séparée, sans lien avec la chaîne ci-dessus. La commande idp-add passe deux valeurs fournies par l'appelant, un nom d'organisation et une URL de base, dans un appel eval() Python. Cet appel s'exécute avant le contrôle de permission censé réserver la commande aux administrateurs de fournisseurs d'identité : n'importe quel compte du serveur peut donc l'atteindre, quels que soient ses privilèges.

L'appel est bridé par un motif qui interdit les crochets, ce qui empêche tout appel de fonction. Red Hat conclut qu'« aucune exécution de code n'est possible ». Restent deux primitives : lire une à une les variables d'environnement du processus serveur en observant l'erreur renvoyée, et épuiser la mémoire du serveur avec une expression arithmétique courte. La portée dépend du mode d'installation. Sur une installation par paquets, l'environnement du processus ne contient que des chemins et réglages documentés. Sur une installation en conteneur, l'image officielle du serveur FreeIPA reçoit fréquemment les mots de passe Directory Manager et administrateur sous forme de variables d'environnement au premier démarrage : si elles subsistent après la fin de l'installation, elles sont lisibles.

Red Hat crédite Gia Bui de Calif pour la chaîne FreeIPA et le défaut du serveur d'annuaire, et Calif en collaboration avec Anthropic pour la faille idp-add.

Diagramme de la chaîne d'attaque

Chaîne reconstituée à partir des advisories Red Hat du 8 septembre 2026 et des notes de version FreeIPA 4.13.3 et 4.13.4. Le lien entre les deux moitiés, l'ACI FreeIPA par défaut qui a exactement la forme piégée par le défaut 389-ds, est explicitement présenté par The Hacker News comme sa propre lecture de deux advisories qui décrivent les moitiés séparément.

Analyse technique

Étape 1 : le contrôle d'accès qui compare des chaînes

Une ACI 389-ds s'écrit sous une forme déclarative. Le type de règle en cause exprime l'idée « le propriétaire authentifié de cette entrée », et son implémentation compare le DN lié de la connexion à une valeur stockée dans l'entrée cible. Le bug tient en une ligne de logique : la comparaison ne distingue pas l'absence d'authentification d'une authentification réussie sous un nom vide.

Connexion anonyme : bindDN = "" (aucun bind, ou bind anonyme)
Entrée créée par l'attaquant : ownerDN = "" (champ laissé vide)
Vérification ACL : "" == "" donc autorisé

Le motif est connu ailleurs : contournements JWT à alg: none, comparaisons de hash sur NULL, contrôles if (user == owner) où les deux côtés valent une chaîne vide. Dès qu'une décision d'autorisation repose sur une égalité de chaînes, la question à poser en audit est ce que vaut chaque côté quand rien n'a été renseigné.

Étape 2 : l'ACI FreeIPA qui laisse écrire à côté du jeton

Le second ingrédient est l'ACI livrée par défaut avec FreeIPA pour la gestion des jetons OTP. Deux propriétés en font un vecteur. Elle ne demande pas au client d'être authentifié, ce qui est le comportement souhaité pour un enrôlement initial de jeton. Et elle ne restreint pas les attributs qui peuvent être écrits dans la même opération que le jeton.

L'attaquant crée donc une entrée de jeton avec les champs de propriété laissés vides, franchit le contrôle de propriété en n'étant personne, puis écrit dans la même opération un principal Kerberos et un mot de passe. À la sortie, il possède une identité authentifiable dans le domaine.

Étape 3 : de l'identité créée à l'appartenance administrateur

C'est le point où Red Hat et le projet FreeIPA ne décrivent pas le résultat de la même façon. Red Hat parle d'appartenance réelle au groupe des administrateurs et d'identifiants administrateur réutilisables, et dit avoir vérifié le résultat par des commandes réservées aux administrateurs. FreeIPA parle d'un tremplin. Pour un opérateur offensif, la distinction est mince : une identité authentifiable dans un domaine Kerberos, obtenue sans credentials, ouvre l'énumération complète du domaine, qui suffit rarement seule mais échoue rarement à trouver un chemin.

Étape 4 : la variante contournée du correctif précédent

L'historique mérite attention. La technique initialement signalée usurpait le vrai compte admin en créant un nom Kerberos identique. Le correctif de CVE-2026-13097, livré dans FreeIPA 4.13.3, a bloqué la collision : la vérification d'unicité des noms Kerberos ne tenait pas compte des différentes façons d'écrire un même nom, ce qui permettait à un utilisateur disposant d'un accès en écriture de créer une identité de service usurpant une identité privilégiée existante. Mais ce correctif n'a pas touché l'écriture non authentifiée sous-jacente. L'attaque fonctionne aujourd'hui sous un nom choisi par l'attaquant, pour « aboutir au même résultat pratique », selon Red Hat.

Le correctif a donc traité le symptôme observé, pas la primitive. Quand un advisory décrit une exploitation qui repose sur deux conditions, il vaut la peine de vérifier laquelle le patch supprime réellement.

Étape 5 : idp-add, ou la permission vérifiée trop tard

La faille idp-add illustre un défaut d'ordonnancement plus qu'un défaut d'assainissement. Le code évalue une expression construite à partir d'entrées utilisateur avant d'exécuter le contrôle d'autorisation qui devait limiter la commande aux administrateurs IdP. La ligne de défense restante, un motif interdisant les crochets, empêche l'appel de fonction mais pas l'évaluation arithmétique ni le déclenchement d'erreurs différenciées.

L'oracle d'erreur est la partie exploitable : en soumettant des expressions qui référencent des variables d'environnement, l'attaquant distingue les cas d'existence par le message renvoyé, et reconstruit le contenu variable par variable. Sur une installation en conteneur mal nettoyée, la cible est explicite : le mot de passe Directory Manager.

Indicateurs de compromission

Ni les advisories ni les rapports de bogue ne publient de règles de détection ou d'indicateurs. Le tableau ci-dessus est une liste de recherches à construire, pas une liste fournie par l'éditeur.

MITRE ATT&CK

Aucune cartographie officielle n'accompagne ces advisories. La lecture ci-dessous est la nôtre.

Remédiation : checklist opérationnelle

1. Installer FreeIPA 4.13.4 si vous consommez le projet en amont. Cette version corrige les deux failles FreeIPA.
2. Sur RHEL, appliquer l'advisory 389-ds-base correspondant à votre version. Quatorze advisories ont été publiées le 8 septembre. RHSA-2026:64785 couvre RHEL 10 avec 389-ds-base-3.2.0-10.el10_2 et corrige quatre autres failles 389-ds en plus de celle-ci. Aucune advisory pour RHEL 9 simple n'apparaissait dans cette liste au 8 septembre, ce qui ne signifie pas qu'aucune n'est prévue.
3. Ne pas considérer la mise à jour 389-ds comme suffisante. Ni Red Hat ni le projet FreeIPA n'indiquent si les mises à jour du serveur d'annuaire, seules, bloquent l'attaque FreeIPA sur un serveur dont les paquets ipa restent obsolètes. Traiter les deux composants.
4. En attendant un paquet corrigé, restreindre l'accès au service LDAP, ports 389 et 636, aux hôtes de confiance par règles de pare-feu ou segmentation réseau.
5. Désactiver les binds LDAP anonymes, ce qui bloque ce chemin précis, après avoir vérifié qu'aucun autre composant du déploiement n'en dépend.
6. Pour idp-add, aucun contournement de configuration n'existe. Red Hat indique qu'aucun réglage ne tient un compte authentifié ordinaire à l'écart de ce code : le paquet corrigé est obligatoire.
7. Sur les installations en conteneur, vérifier que les mots de passe Directory Manager et administrateur définis au premier démarrage ne sont plus présents dans l'environnement du processus en cours d'exécution.
8. Auditer manuellement les principaux Kerberos et l'appartenance au groupe admins. Aucun advisory n'indique si l'application d'un correctif supprime une identité créée auparavant, ni ce qu'un administrateur doit chercher pour le savoir. Partez du principe que le nettoyage est à votre charge.
9. Auditer les certificats émis par Dogtag sur la période où le serveur était vulnérable et exposé, un certificat émis à un principal illégitime survivant à toute rotation de mots de passe.

Sources

• FreeIPA Flaw Chain Lets Anonymous Clients Create Reusable Administrator Credentials, The Hacker News
• CVE-2026-76578, Red Hat Security
• CVE-2026-76560, Red Hat Security
• CVE-2026-79678, Red Hat Security
• RHSA-2026:64785, Red Hat Errata
• FreeIPA 4.13.4 release notes
• FreeIPA 4.13.3 release notes
• Bugzilla 2519522, FreeIPA
• Bugzilla 2519521, 389-ds