authentik CVE-2026-55106

The target authentik deployment must have at least one LDAP Source configured; deployments without any LDAP Source are completely unaffected regardless of version. The CVSS vector (PR:N, AV:N, AC:L, UI:N) confirms no authentication is required and no complex setup must be in place beyond network reachability to the authentik API. The attacker must know or discover the slug identifier of a configured LDAP Source; slugs are not secret by design and may be enumerable from other API endpoints or predictable from organizational naming conventions. Exploitation impact is bounded: only distinguished names and attribute names are returned - attribute values (passwords, email addresses, phone numbers) are never disclosed, and the attacker does not obtain the LDAP bind credentials used by the server to perform the lookup. The limiting factors for defenders to assess realistic risk are: (1) an LDAP Source must be actively configured, (2) the attacker must obtain a valid source slug, and (3) the information exposure is directory metadata only, not full attribute data or credentials.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N scores 5.3 Medium, reflecting unauthenticated network exploitation with limited confidentiality impact. The exposure is narrowly bounded - distinguished names and attribute names are returned, not attribute values - which meaningfully constrains the direct breach impact compared to a full credential or PII disclosure. From a reconnaissance perspective, however, the leaked metadata (account naming conventions, group structures, OU layouts) provides an attacker with an organizational map of the LDAP directory, which can facilitate targeted phishing or credential stuffing against known account names. No EPSS score was included in the source intelligence and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The attack is technically trivial to automate - a single unauthenticated GET request - but the payoff for mass scanning campaigns is modest, limiting broad exploitation incentive. Even a mid-sized municipal IT team in bytom running authentik with Active Directory integration should plan an upgrade on a normal patch cycle rather than treating this as an emergency requiring off-hours maintenance. The critical scope limiter is deployment configuration: organizations not using the LDAP Source feature are entirely unaffected, which constrains the true vulnerable population to a subset of the authentik install base.

An unauthenticated external attacker with network access to the authentik API discovers or guesses the slug of a configured LDAP Source - potentially through API enumeration or knowledge of the organization's naming conventions - and issues a single HTTP GET request to /api/v3/sources/ldap/<slug>/debug/. The authentik server responds by connecting to the upstream LDAP directory using its stored bind credentials and returning a set of directory entries that expose account distinguished names, OU structure, and the names of attributes present on those entries, giving the attacker a map of the directory suitable for targeted follow-on attacks. No public proof-of-concept code has been identified, but the attack requires no specialized tooling beyond a standard HTTP client.