A Red Hat szerint a FreeIPA egyik hibája lehetővé teszi, hogy egy olyan kliens, amely még soha nem jelentkezett be, tetszőlegesen választott Kerberos-identitást hozzon létre a directoryban, és végül bekerüljön az administrators csoportba.

A FreeIPA határozza meg, ki léphet be egy Linux tartományba, és a 389 Directory Server adatbázisában tartja nyilván az összes identitást, amelyet LDAP-on keresztül érnek el. A támadáshoz szükség van egy második hibára is ebben az adatbázis-szoftverben.

A FreeIPA projekt már kijavította a saját oldalát a 4.13.4-es verzióban. A Red Hat szerint a láncot kétszer is sikerült reprodukálni egy alapértelmezett telepítésen, legutóbb egy olyan gépen, amelynek egyáltalán nem volt hozzáférése.

A Red Hat a FreeIPA hibát CVE-2026-76578 azonosítóval követi, és kritikusnak minősíti, 9,8-as CVSS pontszámmal. Ugyanazon az oldalon jelzik, hogy ez az érték előzetes, és felülvizsgálhatják.

A Red Hat az Identity Management termék részeként szállítja a FreeIPA-t, ahol a csomag neve ipa.

A FreeIPA egy ACI-nek nevezett hozzáférés-vezérlési szabályt is tartalmaz, amely lehetővé teszi, hogy a felhasználó a saját egyszer használatos jelszó tokenjét kezelje. A szabály nem követeli meg, hogy a kliens be legyen jelentkezve, és nem korlátozza, mi mást lehet a token mellé beírni.

Ez csak a második hiba miatt válik veszélyessé. A 389 Directory Serverben van egy olyan szabálytípus, amelynek az a célja, hogy „csak a bejelentkezett tulajdonos férjen hozzá ehhez a bejegyzéshez”. A rendszer egyszerű szövegként hasonlítja össze a kliens nevét egy eltárolt értékkel, és egy be nem jelentkezett kliens neve üres, ami egyezik az üresen hagyott tárolt értékkel.

Így egy névtelen kliens létrehozhat egy token bejegyzést üresen hagyott tulajdonosi mezőkkel, átmehet a tulajdonosi ellenőrzésen azzal, hogy „senki”, és a token mellé Kerberos-identitást és jelszót írhat.

A Red Hat a directory-server hibát, CVE-2026-76560 azonosítóval, 7,5 pontra értékeli, és azt mondja, hogy a Red Hat Directory Server alapértelmezés szerint nem szállít ilyen formájú szabályt. Önmagában ez a hiba csak ott számít, ahol a telepítés során ilyen szabályt hoztak létre.

A FreeIPA ilyen telepítés. Az általa szállított alapértelmezett szabály pontosan ilyen felépítésű, ezért működik a lánc egy érintetlen telepítés ellen is. Ezt a kapcsolatot két olyan biztonsági közleményből olvashatjuk ki, amelyek külön-külön írják le a lánc két felét.

A Red Hat a directory-server hibát önmagában is reprodukálta egy sima 389-ds builden, FreeIPA komponensek nélkül, és egy kontrolltesztben egy nem üres értéket helyesen elutasított a rendszer. Ez alapján a hiba a hozzáférés-vezérlő motorban van, nem pedig a FreeIPA működésében.

A Red Hathez bejelentett első technika a valódi admin fiók megszemélyesítésére épített, olyan Kerberos nevet hozva létre, amely megegyezett azzal. A CVE-2026-13097-re kiadott korábbi javítás megakadályozta ezt az ütközést, de maga a hitelesítés nélküli írási lehetőség megmaradt. A támadás most egy, a támadó által választott névvel működik, a Red Hat szerint „ugyanarra a gyakorlati eredményre jutva”.

A korábbi hibát, amelyet a FreeIPA 4.13.3 kiadásban javítottak, egy másik probléma okozta. A Kerberos-nevek egyediségét ellenőrző mechanizmus nem vette figyelembe, hogy ugyanazt a nevet többféleképpen is le lehet írni. Így egy írási jogosultsággal rendelkező felhasználó olyan szolgáltatás-identitást hozhatott létre, amely egy meglévő, kiemelt jogosultságú identitást személyesített meg.

A két projekt eltérően írja le az eredményt. A Red Hat valódi administrators csoporttagságról és újrahasznosítható adminisztrátori hitelesítő adatokról beszél.

A FreeIPA projekt szűkebben fogalmaz: szerintük a befecskendezett identitásnak nem szabad már léteznie, a CVE-2026-13097 javítás megakadályozza a meglévő fiókok átvételét, és a támadás „ugródeszkaként használható” adminisztrátori jogosultságok megszerzéséhez.

A Red Hat szerint a láncot egy alapértelmezett FreeIPA container image-en futtatták, amely a 4.13.1-es verziót használta, és az eredményt szabványos, csak adminisztrátorok számára elérhető parancsokkal ellenőrizték, nem bíztak meg pusztán az exploit kimenetében. Egyik közlemény vagy hibajelentés sem említi, hogy a hibát valódi támadásban kihasználták volna.

Azoknál a telepítéseknél, ahol Windows-stílusú security identifier-eket használnak, a Red Hat szerint a támadó Kerberos ticketet is szerezhet, amely tartalmazza a jogosultsági adatokat. Így kiterjesztheti a hozzáférését a szerver HTTP és Dogtag szolgáltatásaira. A Dogtag a FreeIPA beépített hitelesítésszolgáltatója.

Második, önálló sebezhetőség

A Red Hat a fentiekkel együtt egy második FreeIPA sebezhetőséget is nyilvánosságra hozott, CVE-2026-79678 azonosítóval, amelynek semmi köze az előző lánchoz. Ezt fontos besorolással, 8,1-es pontszámmal értékelték.

Az idp-add parancs két, a hívó által megadott értéket – egy szervezetnevet és egy bázis URL-t – ad át egy Python eval() hívásnak. Ez a hívás még azelőtt lefut, hogy a rendszer ellenőrizné, valóban csak az identity-provider adminisztrátorok használhatják-e a parancsot, így a szerveren bármelyik fiók elérheti, jogosultságtól függetlenül.

A hívást egy olyan minta korlátozza, amely tiltja a zárójeleket, így nem lehet függvényeket meghívni. A Red Hat szerint „nem lehetséges kódfuttatás”.

A támadó viszont el tudja olvasni a szerverfolyamat környezeti változóit, egyenként, a szerver által visszaadott hibák alapján, és egy rövid aritmetikai kifejezéssel fel tudja zabálni a szerver memóriáját.

Hogy ez mennyire súlyos, attól függ, hogyan telepítették a FreeIPA-t – mondja a Red Hat. Egy hagyományos, csomagokra épülő telepítésnél a folyamat környezete csak dokumentált elérési utakat és beállításokat tartalmaz. A container alapú telepítések mások.

Az hivatalos FreeIPA szerver image gyakran környezeti változókból veszi át a Directory Manager és az adminisztrátor jelszavát az első induláskor, és ezek a jelszavak kiszivároghatnak, ha a beállítás befejezése után is megmaradnak.

A Red Hat a FreeIPA lánc és a directory-server sebezhetőség bejelentését Gia Bui-nak (Calif) tulajdonítja, az idp-add hibát pedig a Calif és az Anthropic közös munkájának.

Mit tehetnek most a rendszergazdák

A javítás három különböző helyen, három különböző időpontban jelent meg, ezért a teendők attól függnek, melyik szoftverkomponenst frissíted.

Component Mit kell telepíteni Állapot az ellenőrzéskor FreeIPA, a projekttől FreeIPA 4.13.4 Mindkét FreeIPA hibát javítja. A kiadási megjegyzések nem tartalmaznak dátumot, és nem derül ki belőlük, mely korábbi verziók érintettek. 389-ds-base Red Hat Enterprise Linuxon és Red Hat Directory ServerenAz adott kiadáshoz tartozó figyelmeztetés Szeptember 8-án 01:56 és 05:07 UTC között tizennégy figyelmeztetést tettek közzé, ezek listája a 389-ds hibajegyen található. RHSA-2026:64785 a Red Hat Enterprise Linux 10-re vonatkozik, 389-ds-base-3.2.0-10.el10_2 csomaggal. A figyelmeztetés minősítése kritikus, és a most tárgyalt hibán kívül még négy 389-ds sebezhetőséget fed le. ipa csomagok Red Hat Enterprise Linuxon Még nincs listázvaA két FreeIPA hibához tartozó Red Hat hibajegyek szeptember 8-án még nem mutattak javított verziót vagy figyelmeztetést. 389-ds-base FedoránA frissítés még tesztelés alatt A Fedora követő állapota ON_QA volt szeptember 8-án.

A tizennégy figyelmeztetés között nem szerepelt külön figyelmeztetés a sima Red Hat Enterprise Linux 9-hez. Ez a hibajegy szeptember 8-i állapota, nem pedig annak kijelentése, hogy ehhez a kiadáshoz nem érkezik javítás.

Amíg nem jelenik meg javított csomag, Red Hat két átmeneti lépést javasol a lánc ellen:

• Korlátozd az LDAP szolgáltatáshoz (jellemzően a 389-es és 636-os porthoz) való hozzáférést megbízható gépekre, tűzfal-szabályokkal vagy hálózati szegmentálással.
• Az anonim LDAP bind letiltása lezárja ezt a konkrét támadási útvonalat – írja a Red Hat –, de előtte ellenőrizd, hogy a környezetedben semmi más nem igényli ezt a funkciót.

Az idp-add hibánál nincs hasonló kerülőút. A Red Hat szerint nincs olyan konfigurációs beállítás, amely egy egyszerű, hitelesített felhasználói fiókot távol tartana ettől a kódtól, ezért mindenképpen javított csomagra van szükség. Azt is hozzáteszik, hogy a container alapú telepítéseknél érdemes ellenőrizni, hogy az első induláskor beállított jelszó már ne szerepeljen a futó folyamat környezeti változói között.

A nyilvánosan elérhető információk két kérdést nyitva hagynak. Sem a Red Hat, sem a FreeIPA projekt nem mondja ki egyértelműen, hogy önmagában a 389-ds frissítése megállítja-e a FreeIPA elleni támadást egy olyan szerveren, ahol az ipa csomagok még elavultak.

Arra sem térnek ki, hogy a javítás telepítése eltávolítja-e azokat az identitásokat, amelyeket a támadó korábban hozott létre, illetve hogy a rendszergazdának pontosan mit érdemes keresnie, ha ezt fel akarja deríteni.

Sem a figyelmeztetések, sem a hibajegyek nem tartalmaznak észlelési szabályokat vagy indikátorokat.