On 8 September 2026 Okta published three advisories for the Auth0 AD/LDAP Connector, the small on-premises service that lets Auth0 tenants authenticate users against Active Directory or another LDAP directory. The worst is a stored cross-site scripting bug in the connector's admin panel rated CVSS 9.0. A second exposes the connector's Active Directory service account password to any local process. All three are fixed in auth0/ad-ldap-connector 8.0.0.
What's affected
| CVE | Issue | CVSS 3.1 | Fixed in |
|---|---|---|---|
| CVE-2026-85982 | Stored XSS in admin panel search results and updater logs (CWE-79) | 9.0 | 8.0.0 |
| CVE-2026-85983 | Local privilege escalation via a startup configuration value (CWE-94) | 7.8 | 8.0.0 |
| CVE-2026-85981 | Unauthenticated admin panel on localhost (CWE-306) | 6.7 | 8.0.0 |
The CVE-2026-85981 advisory lists v6.5.0 and earlier as affected. The other two advisories give 8.0.0 as the fix without listing an affected range, so treat anything older than 8.0.0 as in scope.
CVE-2026-85981. The admin panel listens on the loopback interface with no authentication. Any local user or process that can open a connection to it can read the configuration, including the Active Directory service account credentials in plaintext, and change connector settings. It can't be reached remotely.
CVE-2026-85982. The admin panel didn't HTML-encode data shown in search results and updater log content. The precondition is either authenticated access to the directory with permission to change user-editable attributes, or a low-privileged local account on the host, and then an administrator viewing the affected page. That first precondition is the interesting one: an ordinary directory user who can edit their own profile attributes may be able to plant script that runs in an admin's browser.
CVE-2026-85983. A configuration value was processed unsafely at service startup. A low-privileged local user who can modify the configuration gets code execution as the connector's service account the next time the service restarts. GitHub advisory GHSA-3cg2-mjvj-wmg4.
How to check if you're exposed
Find the hosts. In the Auth0 dashboard, go to Authentication, Enterprise, Active Directory / LDAP, and open each connection. The connection page shows the connectors linked to it and their status.
On each Windows host, list installed programs and look for the connector and its version:
Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
Where-Object { $_.DisplayName -like "*LDAP*" } |
Select-Object DisplayName, DisplayVersion
Anything below 8.0.0 needs the upgrade.
Then ask who else can log on to those hosts. The two local bugs matter most where the connector shares a server with other services or other admins.
What to do now
- Upgrade to 8.0.0 or later on every connector host. If you run more than one connector for availability, upgrade them one at a time and confirm the connection stays online in the dashboard.
- Rotate the AD service account password used by the connector if any untrusted user or process had local access to a host on an affected version. CVE-2026-85981 exposed it in plaintext to anything local.
- Restrict who can log on to connector hosts. They hold a directory credential, so give them dedicated servers and admin-only interactive logon.
- Scope the service account. It needs read access to the users and groups that sign in, and nothing more. If it's a member of Domain Admins or has write rights, fix that now.
- Check directory attributes for script content if you suspect CVE-2026-85982 abuse. Look for script tags or javascript: URLs in user-editable attributes such as description, title and department.
- Review the updater log on each host for unexpected configuration changes before your upgrade.
Why it matters
Hybrid identity puts a small agent in your data centre that holds a credential for your directory and a trust relationship with your cloud IdP. These agents are easy to forget. They install once, work quietly, and rarely get the patch attention that the IdP itself gets.
The localhost admin panel bug is a familiar pattern. "It only listens on 127.0.0.1" is often treated as authentication. It isn't. On a shared host, every local process is on 127.0.0.1, including malware that arrived through some other service.
The XSS path through directory attributes is the other lesson. Data from a directory feels like trusted, internal data. But many attributes are user-editable by default, and anything a user can write should be encoded wherever an admin will view it.
Try it yourself
Inventory every identity agent you run on your own infrastructure: AD/LDAP connectors, RADIUS agents, provisioning agents, password sync agents. Record host, version and the service account each uses. Then send a review request to the owning vendor for each one, asking how they handle advisories. The demo below shows a structured way to run that kind of review.
Click through it at your own pace, or open it full screen.
Quick check
The admin panel only listens on localhost. Why does CVE-2026-85981 matter?
Because any local user or process can reach localhost. The panel had no authentication, so local access was enough to read the AD service account password in plaintext and change settings.
Can a normal directory user exploit the stored XSS?
Per the advisory, an attacker with permission to modify user-editable directory attributes meets the first precondition. An administrator then has to view the affected search results or update logs in the admin panel.
Is upgrading alone enough?
It closes the bugs. If an untrusted local user could reach the panel before you upgraded, rotate the AD service account password too.
