Een FreeIPA kwetsbaarheid blijkt ernstiger dan je op basis van één bug zou verwachten. Red Hat meldt een aanvalsketen waarbij een client die nooit eerder heeft ingelogd, binnen de directory een Kerberos-identiteit kan aanmaken die vervolgens in de beheerdersgroep terechtkomt. Daarmee kunnen aanvallers toegang opbouwen die in de praktijk neerkomt op herbruikbare administrator-credentials.
Wat het extra lastig maakt: de keten werkt alleen als twee afzonderlijke problemen samenkomen—één bij FreeIPA zelf en één bij de onderliggende 389 Directory Server-toegangscontrole. In dit artikel zetten we de kern op een rij: wat er precies wordt misbruikt, welke CVE’s horen erbij en welke stappen beheerders nu al kunnen nemen.
Wat is FreeIPA en waarom is dit domein-achtig misbruik gevaarlijk?
FreeIPA is het identity-management systeem voor Linux-domeinen. Het bepaalt wie mag inloggen en beheert identiteiten in een database die via LDAP wordt benaderd. De identiteit en authenticatie lopen vervolgens via Kerberos.
Juist daarom is een probleem in dit soort omgevingen zo ingrijpend: als iemand de directory kan beïnvloeden met verkeerde eigenaar- of rechteninformatie, kan dat direct doorwerken naar authenticatie en autorisatie.
De aanval werkt als een keten: client + toegangscontrole + identiteit
Red Hat beschrijft de aanval als een keten van twee afzonderlijke tekortkomingen.
- De FreeIPA-kant (geregistreerd als CVE-2026-76578) stelt een client die niet heeft ingelogd in staat om een Kerberos-identiteit te creëren “van zijn eigen keuze” in de directory.
- De directoryserver-kant (geregistreerd als CVE-2026-76560) gaat over een toegangscontrolelogica in 389 Directory Server. Die logica kan misleid worden door een controle die een naam vergelijkt als platte tekst.
Het resultaat is dat de opgegeven identiteit in bepaalde situaties niet wordt geblokkeerd, maar juist mag worden weggeschreven met velden die normaal gesproken zouden moeten verifiëren wie de eigenaar is.
Waar zit de kernfout: “ownership” check op basis van lege naam
Volgens de melding is de toegangscontrole bedoeld om alleen de “authenticated owner” van een entry toegang te geven. De vergelijking gebruikt de naam van de client (als tekst) tegenover een opgeslagen waarde.
Een client die nog nooit heeft ingelogd, heeft volgens Red Hat een lege naam in deze context. Als diezelfde “lege waarde” ook is opgeslagen, kan de eigendom-check worden gepasseerd. Met dat voordeel kan een aanvaller een token-entry aanmaken en vervolgens Kerberos-gegevens toevoegen die later als beheerdersrelevant worden gezien.
Waarom werkt het op een standaard FreeIPA-installatie?
De directoryserverfout (CVE-2026-76560) is volgens Red Hat op zichzelf alleen riskant wanneer een deployment een specifieke access-control regel heeft gebruikt die precies in dat patroon past. FreeIPA wordt standaard geleverd met zo’n rule (een ACI-regel).
Daarom lukte de keten op een “out-of-the-box” installatie van FreeIPA, aldus Red Hat. Ook wordt beschreven dat Red Hat de keten twee keer kon reproduceren op een default installatie, inclusief een scenario waarin de machine geen relevante toegang had—met andere woorden: de reproductie was niet afhankelijk van specifieke extra omstandigheden.
Wat levert de keten op? Administrator-group membership en herbruikbare credentials
Red Hat stelt dat de keten kan leiden tot “echte” lidmaatschap van de administratorgroep en dat het om herbruikbare administrator-credentials kan gaan. FreeIPA zelf beschrijft het nauwer: de geïnjecteerde identiteit moet niet al bestaan, en een eerder fix (bij CVE-2026-13097) voorkomt dat bestaande accounts worden overgenomen op een bepaalde manier.
Belangrijk detail: Red Hat meldt dat de eerder gerapporteerde bot-rondes rond Kerberos-naamcollisies de aanvallen niet volledig hadden afgekapt. De huidige techniek omzeilt dat door te werken onder een naam die de aanvaller kiest, met hetzelfde praktische effect.
Door Red Hat gescoorde impact en status van de beoordeling
Red Hat beoordeelt de FreeIPA-kant als kritiek met CVE-2026-76578 en een CVSS-score van 9.8. Die score wordt tegelijk als voorlopig aangeduid; Red Hat geeft aan dat de score nog kan worden herzien.
Voor de directoryserverfout geldt CVE-2026-76560 met een score van 7.5. Opnieuw: de daadwerkelijke exploitbaarheid hangt samen met hoe access control in jouw FreeIPA/389-configuratie is ingericht.
Kan dit ook zonder echte admin-actie? Noodmaatregelen voor nu
Red Hat geeft beheerders twee tijdelijke stappen voor de keten, zolang er geen volledig toepasbare patch beschikbaar is voor het pakket dat jij gebruikt.
- Beperk toegang tot LDAP: sta alleen hosts toe die je vertrouwt via firewallregels of netwerksegmentatie, typisch voor poorten 389 en 636.
- Schakel anonymous LDAP binds uit: Red Hat stelt dat dit deze route blokkeert. Controleer wel vooraf of jouw deployment dit wel degelijk niet nodig heeft.
Red Hat benadrukt dat deze maatregelen tijdelijk zijn; voor echte bescherming is een fixed package nodig.
Extra kwetsbaarheid: idp-add via eval() (CVE-2026-79678)
Naast de keten noemt Red Hat nog een andere FreeIPA kwetsbaarheid: CVE-2026-79678. Die heeft geen directe relatie met de administrator-keten hierboven.
Het probleem zit in de opdracht idp-add, die door een Python eval()-aanroep twee door de caller aangeleverde waarden verwerkt: een organisatie-naam en een basis-URL. Red Hat stelt dat de eval()-uitvoering gebeurt vóórdat de beveiligingscheck plaatsvindt die de opdracht normaal beperkt tot identity-provider administrators.
Hoewel Red Hat stelt dat er geen code execution mogelijk is door een beperking op toegestane patronen (zoals het blokkeren van haakjes die functies oproepen zouden moeten verhinderen), kan een aanvaller wel informatie of resources beïnvloeden:
- De fout kan het mogelijk maken om één voor één omgevingsvariabelen van het serverproces uit te lezen via foutobservatie.
- Daarnaast kan de aanvaller servergeheugen opmaken met een korte rekenexpressie.
Voor dit onderdeel is er volgens Red Hat geenzelfde soort configuratie-optie om toegang af te sluiten. Beheerders moeten dus uitgaan van patching.
Let extra op bij containerinstallaties
Red Hat merkt op dat de impact afhankelijk is van de installatiemethode. Bij containerimages kan het gebeuren dat de Directory Manager- en beheerderswachtwoorden bij eerste opstart als omgevingsvariabelen beschikbaar worden gemaakt. Als die waarden na de setup blijven hangen in het draaiende proces, vergroot dat het risico van blootstelling via de fout.
Controleer daarom bij containergebruik of de wachtwoorden die tijdens first boot worden gezet, niet nog zichtbaar zijn in de runtime-omgeving.
Wat je nu kunt doen als beheerder
De situatie vraagt om twee sporen: patchbeheer én het beperken van de aanvalsvectoren.
1) Patch je FreeIPA en 389 Directory Server zodra dat kan
Red Hat zegt dat FreeIPA op zijn kant al is gefixt in versie 4.13.4. Het exacte moment en de beschikbaarheid van fixes kunnen verschillen per component en per platformrelease. Het is dus zaak om jouw huidige versies, distributie en updatekanalen te vergelijken met de relevante advisories.
2) Segmentatie en LDAP-binds aanscherpen
Totdat de vaste pakketten beschikbaar zijn, kun je de keten temperen door LDAP alleen bereikbaar te maken vanuit vertrouwde hosts en door anonymous binds uit te schakelen.
Dat sluit bovendien aan op bredere best practices voor cloud en identity: veel incidenten ontstaan doordat standaard open poorten of ongecontroleerde toegang vergeten worden.
Detectie en “wat is er al ingebracht?” blijft onduidelijk
De publicaties waar Red Hat naar verwijst laten twee belangrijke vragen open. Ten eerste wordt niet expliciet uitgelegd of 389 Directory Server-updates op zichzelf de FreeIPA-aanval stoppen wanneer de ipa-pakketten nog verouderd zijn.
Ten tweede wordt niet helder beschreven of het toepassen van een fix eerder aangemaakte identiteiten ongedaan maakt. Ook ontbreken indicatoren of detectieregels waarmee je kunt achterhalen of een aanvaller al een entry heeft gecreëerd.
Dit maakt het extra belangrijk om naast patching ook te kijken naar toegangslogs, directorywijzigingen en Kerberos-gerelateerde activiteiten binnen je omgeving.
Vergelijkbare risico’s: wees alert op identity- en authorization chains
Hoewel dit artikel specifiek over FreeIPA en 389 Directory Server gaat, past het in een breder patroon: aanvallen die beginnen met een schijnbaar “beperkte” stap in identity of toegangscontrole kunnen uitgroeien tot beheerderstoegang zodra rechtenchecks niet volledig kloppen of wanneer configuraties het verkeerde pad openzetten.
Wil je meer voorbeelden van hoe kwetsbaarheden ketens kunnen vormen richting account- of systeemrechten? Lees dan ook MikroTik SSH-hijack: zo bescherm je je routers voor een illustratie van hoe omzeiling van toegang kan leiden tot grotere impact.
Conclusie
De FreeIPA kwetsbaarheid die Red Hat beschrijft, draait niet om één simpele bug, maar om een aanvalsketen die werkt wanneer FreeIPA’s standaard access control regels en een toegangscontrole-eigenschap in 389 Directory Server samenkomen. Daardoor kan een anonieme client Kerberos-identiteiten aanmaken die in de beheerdersgroep belanden, met herbruikbare administrator-credentials als gevolg.
Beheerders doen er verstandig aan om snel te patchen (FreeIPA’s fix in 4.13.4 wordt genoemd) en in de tussentijd LDAP-toegang te beperken en anonymous binds te blokkeren. Omdat detectie- en “rollback”-informatie ontbreekt, is proactief inventariseren en monitoren minstens zo belangrijk als het toepassen van updates.
Bron: https://thehackernews.com/2026/09/freeipa-flaw-chain-lets-anonymous.html
