CVE-2026-55106: authentik Information Disclosure Flaw

CVE-2026-55106 Overview

CVE-2026-55106 is a missing authorization vulnerability [CWE-862] in authentik, an open-source identity provider. The diagnostic action on the LDAP Source API does not enforce the object-level read-authorization filter applied elsewhere in the API. Any client that can reach the API, including unauthenticated ones, can invoke the diagnostic action against a configured LDAP Source. The server connects to the upstream directory using the source's configured bind credentials and returns a bounded set of directory entries. The response exposes distinguished names and attribute names, revealing directory structure, naming conventions, and the existence of specific accounts and groups. Attribute values are not exposed. Deployments without a configured LDAP Source are unaffected.

Critical Impact
An unauthenticated network attacker can enumerate distinguished names, account names, and group names from any LDAP directory configured as an authentik source.

Affected Products

authentik versions prior to 2026.2.6
authentik versions prior to 2026.5.5 in the 2026.5.x branch
Deployments with at least one configured LDAP Source

Discovery Timeline

2026-08-18 - CVE-2026-55106 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-55106

Vulnerability Analysis

The vulnerability resides in the LDAP Source API's debug action, implemented in authentik/sources/ldap/api.py and authentik/sources/ldap/api/sources.py. The action is decorated with an empty filter_backends=[] list, which removes the object-level authorization filter (ObjectFilter) that the rest of the API enforces. As a result, the endpoint bypasses authorization checks that other API actions apply to LDAP source objects.

When invoked, the action calls self.get_object() to load a configured LDAP Source, then binds to the upstream directory using the stored service credentials. It returns a bounded set of entries containing distinguished names (DNs) and attribute names. Attribute values are excluded from the response, but structural metadata is sufficient to map an organization's directory tree and enumerate user and group objects.

The disclosed information supports downstream attacks including targeted credential stuffing, phishing against specific accounts, and reconnaissance for later privilege escalation attempts. The EPSS score is 0.252%.

Root Cause

The debug viewset action was registered without the ObjectFilter filter backend that authentik uses to enforce per-object read authorization. This is a classic missing authorization defect [CWE-862] rather than a broken authentication flow — the endpoint simply does not consult the authorization layer before returning data.

Attack Vector

The attack requires network reachability to the authentik API and knowledge or guessing of a configured LDAP Source slug. No authentication, user interaction, or elevated privileges are required. An attacker sends a GET request to the LDAP source debug endpoint with a valid slug and receives directory metadata in the response.

python

            ),
        }
    )
-    @action(methods=["GET"], detail=True, pagination_class=None, filter_backends=[])
+    @action(methods=["GET"], detail=True, pagination_class=None, filter_backends=[ObjectFilter])
    def debug(self, request: Request, slug: str) -> Response:
        """Get raw LDAP data to debug"""
        source = self.get_object()

Source: GitHub Commit e638de2 and GitHub Commit fc336da. The patch reintroduces the ObjectFilter filter backend on the debug action so authorization is evaluated before the LDAP bind executes.

Detection Methods for CVE-2026-55106

Indicators of Compromise

Unauthenticated or unexpected GET requests to /api/v3/sources/ldap/{slug}/debug/ in authentik access logs
Outbound LDAP bind operations from the authentik host that do not correlate with a scheduled sync or authenticated administrator session
Repeated requests iterating LDAP source slugs from a single source IP

Detection Strategies

Alert on any request to the LDAP source debug endpoint originating from clients without an authenticated session cookie or valid API token
Correlate authentik application logs with directory server logs to identify LDAP binds that lack a corresponding authorized user action
Baseline normal callers of the LDAP source API and flag deviations from expected administrative IP ranges

Monitoring Recommendations

Ship authentik logs to a centralized log platform and retain request URLs, source IPs, and authentication state for the /api/v3/sources/ldap/ path
Monitor upstream LDAP or Active Directory servers for unexpected bind sources and enumeration-style traffic from the authentik service account
Track authentik release versions across environments to confirm remediated builds are deployed

How to Mitigate CVE-2026-55106

Immediate Actions Required

Upgrade authentik to version 2026.2.6 or 2026.5.5, matching your current release branch
Restrict network access to the authentik API to trusted administrative networks using an ingress controller, WAF, or reverse proxy ACL
Rotate the bind credentials configured on each LDAP Source if unauthorized debug calls appear in historical logs

Patch Information

The fix is available in authentik 2026.2.6 and 2026.5.5. Details are published in GHSA-h8ff-c3h7-2gf8 and delivered by Pull Request #24055 and Pull Request #24060. The patch adds the ObjectFilter filter backend to the debug viewset action so object-level read authorization is enforced consistently across the LDAP Source API.

Workarounds

Block external access to /api/v3/sources/ldap/{slug}/debug/ at the reverse proxy or ingress layer until the patch is applied
Temporarily remove non-essential LDAP Source configurations, since deployments without a configured LDAP Source are not affected
Restrict the authentik API to authenticated administrator networks via IP allowlisting on the fronting proxy

bash

# Example nginx snippet to block the vulnerable endpoint until patched
location ~ ^/api/v3/sources/ldap/[^/]+/debug/?$ {
    deny all;
    return 403;
}