FreeIPA-hull med CVSS 9.8 lar en anonym klient lage sin egen administrator

Red Hat rangerer feilen, CVE-2026-76578, som kritisk med CVSS-score 9.8, og understreker selv at scoren er foreløpig og kan bli revidert. Red Hat sier de reproduserte kjeden to ganger på en standardinstallasjon, sist på en maskin uten tilgang i det hele tatt, mot et uendret FreeIPA-container-image med versjon 4.13.1. Ingen av varslene eller feilrapportene beskriver at feilen er brukt i et faktisk angrep.

Mekanismen er to halvdeler som hver for seg ser ufarlige ut. FreeIPA leveres med en tilgangsregel, en ACI, som lar en bruker forvalte sin egen engangspassord-token. Regelen krever ikke at klienten har logget inn, og den begrenser ikke hva annet som kan skrives ved siden av tokenet. Den andre halvdelen ligger i 389 Directory Server, der FreeIPA lagrer identitetene sine: en regeltype som skal bety «kun den autentiserte eieren av denne oppføringen» sammenligner klientens navn med en lagret verdi som ren tekst. En klient som ikke har logget inn har tomt navn, og tomt matcher tomt. Dermed kan en anonym klient opprette en token-oppføring med tomme eierfelt, passere eierskapssjekken ved å være ingen, og skrive inn en Kerberos-identitet med passord ved siden av.

De to prosjektene beskriver utfallet ulikt. Red Hat kaller det ekte medlemskap i administratorgruppa og gjenbrukbare administratorlegitimasjoner. FreeIPA-prosjektet formulerer seg smalere og sier at den injiserte identiteten ikke kan finnes fra før, og at angrepet «may be used as a stepping stone» til administratorrettigheter.

Katalogserver-feilen, CVE-2026-76560, scorer 7.5, og Red Hat sier Red Hat Directory Server ikke leverer noen regel av den formen som standard. FreeIPA gjør nettopp det, og det er derfor kjeden virker mot en urørt installasjon. En tredje og urelatert feil, CVE-2026-79678 med score 8.1, sender to verdier fra idp-add inn i et Python-eval-kall før rettighetssjekken som skulle begrense kommandoen, slik at enhver konto på serveren kan lese serverprosessens miljøvariabler én om gangen ut fra feilmeldingene. På container-installasjoner kan det bety Directory Manager-passordet.

Hva bør du gjøre?

1. Sjekk versjonen. FreeIPA 4.13.4 fra prosjektet fikser begge FreeIPA-feilene. Red Hats ipa-pakker for RHEL hadde ingen rettet versjon oppført 8. september, og Fedoras 389-ds-oppdatering sto fortsatt på testing.
2. Begrens LDAP-portene 389 og 636 til verter du stoler på, med brannmurregler eller nettverkssegmentering. Å slå av anonyme LDAP-bind blokkerer denne veien, men sjekk først at ingenting annet i oppsettet trenger dem.
3. Kjører du FreeIPA i container: verifiser at passordet som ble satt ved første oppstart ikke fortsatt ligger i den kjørende prosessens miljø. For idp-add-feilen finnes ingen konfigurasjonsvei rundt, bare en rettet pakke.

Verken Red Hat eller FreeIPA-prosjektet har publisert deteksjonsregler eller indikatorer, og ingen av dem sier om en oppdatering fjerner en identitet en angriper allerede har opprettet.