CVE-2026-13097: 
NixOS 취약성 분석 및 완화

CVE-2026-13097 is a privilege escalation flaw in FreeIPA caused by improper uniqueness enforcement on Kerberos principal name attributes in the 389-ds directory server. The flaw allows a user with sufficient LDAP write privileges to create a service principal that impersonates an existing privileged one by exploiting equivalent representations of the same principal name (e.g., omitting the REALM component). It affects FreeIPA 4.12.2 and Red Hat Enterprise Linux versions 7, 8, 9, and 10. The vulnerability was reported by Vladislav Plyatsok (rd01f), disclosed on August 20, 2026, and carries a CVSS v3.1 base score of 9.1 (Critical) (Red Hat Advisory, GitHub Advisory).

The root cause is classified as CWE-706 (Use of Incorrectly-Resolved Name or Reference): the 389-ds LDAP directory server enforces uniqueness on Kerberos principal names without accounting for semantically equivalent representations — specifically, a principal name specified without a REALM component can bypass the uniqueness check and collide with an existing privileged principal. An attacker with LDAP write access (e.g., a computer account or an account with broad directory write rights) can create a new service entry with a krbCanonicalName value matching a privileged service (such as host/ipa.example.com, ldap/ipa.example.com, or krbtgt/) without specifying the REALM, then request Kerberos service tickets for those sensitive services. The Bugzilla report includes a concrete LDAP add payload demonstrating the technique, including setting an open ACI and using ipa-getkeytab to obtain a keytab for the impersonating principal (Red Hat Bugzilla, Red Hat Advisory).

Successful exploitation allows an attacker with LDAP write privileges to acquire valid Kerberos service tickets for sensitive services such as LDAP, HTTP, and host principals — effectively enabling full domain compromise. The changed scope in the CVSS rating reflects that the impact extends beyond the FreeIPA/389-ds component to the entire Kerberos realm, including all services and hosts enrolled in the domain. Confidentiality, integrity, and availability are all rated High, as an attacker could read sensitive directory data, modify directory entries, and disrupt authentication services across the domain (Red Hat Advisory, GitHub Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at this time (Red Hat Advisory). The EPSS score is approximately 0.34%, indicating a low near-term exploitation probability (GitHub Advisory). The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high privileges (LDAP write access), which limits the attacker pool, though the Bugzilla report notes that computer accounts or accounts with broad directory write rights qualify — a realistic scenario in enterprise FreeIPA deployments (Red Hat Bugzilla). Detection plugins are available from Nessus (plugin 338271) and Qualys (plugin 363537).

1. Obtain LDAP write privileges: Compromise or control a computer account (e.g., host/debi.red.corp) or any account with write access to the FreeIPA LDAP directory, which grants the necessary privileges to add service entries.
2. Authenticate to Kerberos: Use the compromised account's keytab to obtain a Kerberos ticket: kinit -k -t /etc/krb5.keytab host/debi.red.corp.
3. Create a malicious service principal: Use ldapadd to create a new service entry in the LDAP directory with a krbCanonicalName value matching a privileged service but omitting the REALM (e.g., krbCanonicalName: host/ipa.red.corp). Include an open ACI granting all access to anyone to facilitate subsequent steps.
4. Obtain a keytab for the impersonating principal: Run ipa-getkeytab -p pwn/debi.red.corp -k ./pwn.keytab --mech=GSSAPI to retrieve a keytab for the newly created principal.
5. Authenticate as the impersonating principal: Use kinit -k -t pwn.keytab pwn/debi.red.corp to obtain a Kerberos TGT.
6. Request service tickets for privileged services: Use kvno HTTP/ipa.red.corp and kvno ldap/ipa.red.corp to acquire valid Kerberos service tickets for sensitive services, which the KDC issues because the krbCanonicalName resolves to the privileged principal.
7. Achieve domain compromise: Use the acquired service tickets to authenticate to and control sensitive services (LDAP, HTTP, host) across the domain (Red Hat Bugzilla).

• LDAP Logs: Unexpected ldapadd operations creating new entries under cn=services,cn=accounts with krbCanonicalName values matching existing privileged principals (e.g., host/ipa.<domain>, ldap/ipa.<domain>, krbtgt/).
• LDAP Logs: New service entries containing overly permissive ACIs such as allow (all) userdn = "ldap:///anyone".
• Kerberos Logs (KDC): Service ticket requests (kvno) for privileged services (HTTP, LDAP, host) originating from unexpected or newly created service principals.
• File System: Unexpected keytab files (e.g., pwn.keytab) created on enrolled hosts, particularly in non-standard directories.
• Process: Execution of ipa-getkeytab for service principals not provisioned through standard IPA management workflows.
• Network: GSSAPI/Kerberos authentication attempts to sensitive services (LDAP, HTTP) from principals not previously observed in normal operations (Red Hat Bugzilla).

Red Hat has acknowledged the vulnerability but states that no mitigation meeting their criteria for ease of use, deployment, and stability is currently available (Red Hat Advisory). A patch is tracked and expected; organizations should monitor Red Hat errata for updates to the ipa package. In the interim, administrators should: (1) restrict LDAP write privileges to only trusted administrators and audit existing service principals for unauthorized entries with suspicious krbCanonicalName values; (2) review and tighten ACIs in the FreeIPA LDAP directory; (3) monitor Kerberos service ticket requests for anomalies, particularly for privileged services like LDAP, HTTP, and host principals; and (4) audit computer accounts and other accounts with broad directory write access (Red Hat Advisory, Red Hat Bugzilla).

The vulnerability was reported by researcher Vladislav Plyatsok (rd01f) and acknowledged by Red Hat Product Security (Red Hat Advisory). Coverage appeared on security aggregation sites including SecurityOnline.info and pro-linux.de shortly after disclosure. Social media activity was noted on Mastodon via @thehackerwire and @stemshop. The vulnerability has been indexed by Amazon Linux Security (ALAS2-2026-3877) and detected by Tenable Nessus and Qualys scanners, indicating broad industry awareness and tooling support for detection.