FreeIPA : un anonyme devient administrateur

Ce qui se passe

FreeIPA décide qui peut se connecter sur un domaine Linux, et conserve les identités dans une base 389 Directory Server interrogée en LDAP. Red Hat décrit une chaîne qui permet à un client jamais authentifié d'y écrire une identité Kerberos de son choix et de se retrouver dans le groupe des administrateurs.

Deux identifiants, deux moitiés :

• CVE-2026-76578 — côté FreeIPA, CVSS 9.8, note explicitement préliminaire et sujette à révision.
• CVE-2026-76560 — côté 389 Directory Server, CVSS 7.5.

Red Hat dit avoir reproduit la chaîne deux fois sur une installation par défaut, la dernière sur une machine sans aucun accès, contre une image conteneur FreeIPA 4.13.1, en vérifiant le résultat avec des commandes réservées aux administrateurs plutôt qu'en croyant la sortie de l'exploit.

Le mécanisme

FreeIPA livre une règle de contrôle d'accès — une ACI — qui laisse un utilisateur gérer son propre jeton à usage unique. Elle n'exige pas que le client se soit connecté, et ne limite pas ce qui peut être écrit à côté du jeton.

Cela ne devient dangereux qu'à cause de la seconde faille. 389 Directory Server possède un type de règle censé dire « 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. Or un client non authentifié a un nom vide, et le vide correspond à une valeur vide.

L'enchaînement tient donc en trois gestes : créer une entrée de jeton dont les champs de propriétaire restent blancs, passer le contrôle de propriété en n'étant personne, écrire à côté une identité Kerberos et son mot de passe.

Red Hat précise que le défaut est bien dans le moteur de contrôle d'accès : il l'a reproduit sur un 389-ds nu, sans FreeIPA, et un test témoin avec une valeur non vide a bien été refusé. Red Hat Directory Server ne livre aucune règle de cette forme par défaut ; FreeIPA, si — c'est pourquoi la chaîne fonctionne sur une installation intacte.

Un correctif antérieur, CVE-2026-13097 (FreeIPA 4.13.3), avait bloqué la technique d'origine, qui usurpait le compte admin par collision de nom. L'écriture non authentifiée, elle, était restée : l'attaque fonctionne aujourd'hui sous un nom choisi par l'attaquant, « pour le même résultat pratique ».

Où en sont les correctifs

En attendant un paquet corrigé, Red Hat donne deux mesures temporaires :

# 1. n'exposer LDAP qu'aux hôtes de confiance
firewall-cmd --permanent --new-zone=ldap-trusted
firewall-cmd --permanent --zone=ldap-trusted --add-port=389/tcp --add-port=636/tcp

# 2. vérifier si des binds anonymes sont réellement utilisés avant de les couper
ldapsearch -x -H ldap://ipa.example.test -b "" -s base

Une troisième faille, à part

CVE-2026-79678 (CVSS 8.1) n'a rien à voir avec la chaîne. La commande idp-add passe deux valeurs fournies par l'appelant — un nom d'organisation et une URL de base — dans un eval() Python, et cet appel se produit avant le contrôle de permission censé réserver la commande aux administrateurs de fournisseurs d'identité. Un motif interdisant les crochets empêche l'appel de fonctions : Red Hat affirme qu'« aucune exécution de code n'est possible ». Restent deux effets : lire les variables d'environnement du processus une par une en observant les erreurs renvoyées, et épuiser la mémoire avec une courte expression arithmétique.

L'image officielle prend souvent les mots de passe Directory Manager et administrateur en variables d'environnement au premier démarrage : sur un déploiement en conteneur, il faut vérifier qu'ils n'y sont plus.

À retenir

Aucun indicateur de compromission n'a été publié, et deux questions restent ouvertes dans les avis : une mise à jour de 389-ds seule suffit-elle à protéger un serveur dont les paquets ipa sont anciens, et un correctif supprime-t-il une identité créée avant. Les crédits vont à Gia Bui de Calif pour la chaîne, et à Calif travaillant avec Anthropic pour la faille idp-add.

Source : FreeIPA Flaw Chain Lets Anonymous Clients Create Reusable Administrator Credentials