FreeIPA admin takeover from anonymous LDAP, plus a 9.9 in hawtio-operator

389 Directory Server's SELFDN ACI evaluator has a logic bug: it matches an anonymous (unauthenticated) client's empty bind DN against an empty attribute value and treats it as a pass. That means an anonymous LDAP client can add or modify directory entries that SELFDN-based ACIs were supposed to lock down to authenticated users only. This is the enabler bug for the FreeIPA admin-takeover in CVE-2026-76578.

Affected estate

Anyone running 389 Directory Server (389-ds-base), whether standalone or as part of FreeIPA / Red Hat IdM

How to check

Run 'rpm -q 389-ds-base' or 'dsctl <instance> healthcheck' to identify the installed version. Check for SELFDN ACIs with 'ldapsearch -b cn=config "(aci=*selfdn*)"'.

Included because

unauthenticated; network-reachable; CVSS 7.5; directly chains with CVE-2026-76578 for full admin compromise

Action

Patch 389-ds-base via your package manager and restart the directory service.

Why it matters

Without this fix, anonymous LDAP clients can bypass access controls meant to restrict writes to authenticated users, enabling the CVE-2026-76578 admin-takeover chain.

Source

Red Hat advisory / NVD

A missing NULL pointer check in 389 Directory Server's paged results code lets an unauthenticated remote attacker crash the LDAP service by sending a crafted search sequence with the USE_ONE_BACKEND control. The result is a full denial of service: your directory goes down, and anything that depends on it (authentication, DNS, sudo rules) stops working.

Affected estate

Anyone running 389 Directory Server (389-ds-base), standalone or as part of FreeIPA / Red Hat IdM

How to check

Run 'rpm -q 389-ds-base' to confirm the installed version against the advisory's fixed version.

Included because

unauthenticated; network-reachable; denial of service; CVSS 7.5; common infrastructure component

Action

Patch 389-ds-base and restart dirsrv. If immediate patching isn't possible, restrict network access to the LDAP port to trusted sources.

Why it matters

A single unauthenticated request can take down your directory server, breaking authentication and authorization for every connected service.

Source

Red Hat advisory / NVD

A heap buffer overflow in 389 Directory Server's SASL I/O layer lets an attacker who has completed a SASL bind (with integrity protection) send a specially crafted packet that causes a massive heap overwrite. The attacker controls the overflow content. This can crash the server and may allow remote code execution. You need valid credentials and a SASL bind with SSF > 0 to reach the vulnerable code path, which raises the bar somewhat, but any LDAP-authenticated user qualifies.

Affected estate

Anyone running 389 Directory Server (389-ds-base) with SASL authentication enabled, including FreeIPA / Red Hat IdM deployments that use GSSAPI

How to check

Run 'rpm -q 389-ds-base' and compare to the advisory's fixed version. Confirm SASL is enabled with 'dsconf <instance> config get nsslapd-sasl*'.

Included because

authenticated but low-privilege; heap overflow with RCE potential; CVSS 7.5; common infrastructure component

Action

Patch 389-ds-base and restart the directory. Verify the fix is distinct from the CVE-2026-11774 patch if you applied that one already.

Why it matters

Any authenticated LDAP user can trigger a heap overflow that crashes the directory or potentially gains code execution on the server.

Source

Red Hat advisory / NVD

The hawtio-operator reads the OpenShift Service CA's private signing key and uses it to mint client certificates with a CN the user controls via a Hawtio custom resource. Because the operator's ClusterRole gives edit-level users Hawtio CR permissions, anyone with edit access in any namespace can generate a Service-CA-signed certificate with any subject they want. That lets them impersonate any in-cluster service identity to anything that trusts the Service CA for client auth, including Jolokia agents and other internal components.

Affected estate

OpenShift clusters running hawtio-operator where users have edit or admin RBAC in any namespace

How to check

Run 'oc get csv -A | grep hawtio' to find installed operator versions. Check ClusterRole aggregation with 'oc get clusterrole -l rbac.authorization.k8s.io/aggregate-to-edit=true' for hawtio entries.

Included because

low-privilege authenticated; cluster-wide impact; CVSS 9.9; privilege escalation to arbitrary service identity

Action

Upgrade hawtio-operator. If a patched version isn't available, remove the aggregation labels from the hawtio ClusterRole and restrict who can create Hawtio CRs.

Why it matters

Any user with edit access in any namespace can forge client certificates trusted cluster-wide, enabling service impersonation across the entire cluster.

Source

Red Hat advisory / NVD