Traccar Let an Empty Password Become a Valid LDAP Login

Traccar is an open-source fleet-tracking platform. CVE-2026-126777 affects versions 3.15 through 6.16.0 when LDAP authentication is enabled. The login handler does not reject an empty password, and the directory may interpret the resulting operation as an unauthenticated bind.

The public advisory says an attacker who knows a valid username can use POST /api/session or HTTP Basic authentication with an empty password. If the LDAP server permits unauthenticated binds, the attacker can obtain a session for that account, including an administrator account.

LDAP has two different meanings for an empty password

In many LDAP implementations, an empty password in a simple bind can be treated as an unauthenticated bind. That is a protocol behavior, not proof that the user supplied the correct password. An application that passes the empty value to the directory and checks only whether the bind succeeded can mistake directory reachability for user authentication.

The application should reject empty or missing passwords before the LDAP call. The directory should also be configured to reject unauthenticated binds where they are not deliberately supported. CVE-2026-126777 sits at the boundary between those two controls.

The advisory does not say that every LDAP server accepts this behavior. The exploit condition includes a directory that permits unauthenticated binds and a username that already exists. That limitation matters for triage.

Fleet data and control

A Traccar administrator may see vehicle locations, device identifiers, users, reports and integration settings. An attacker with an administrator session could change devices, users and configuration, or use the platform's data to learn about fleet operations.

The impact is not limited to the login page. Tracking data can reveal routes, depot activity and operational patterns. Alerts and sharing settings may also expose information to additional accounts.

Upgrade and test

Traccar 6.17.0 is the fixed release. Upgrade the application and confirm that LDAP authentication still works with a valid password. Then test an empty password against a non-production account and verify that the request is rejected before the application creates a session.

Restrict LDAP access to the Traccar service account and remove anonymous or unauthenticated bind permissions unless a documented dependency requires them. Use TLS for the directory connection and avoid sending credentials over an untrusted path.

If the deployment cannot be upgraded immediately, disable LDAP login or place the application behind a trusted authentication proxy. A network restriction alone does not fix the application's empty-password decision.

Investigate account use

Review authentication logs for successful sessions whose LDAP bind had an empty password or no credential. Check for administrator logins from unusual source addresses, device changes, user creation and report exports.

Preserve directory logs and Traccar application records. Rotate passwords and session material for accounts that may have been accessed. A successful bind does not show who supplied the password, so the investigation should combine the directory event with the application session and later actions.

The fix is a boundary, not a directory setting

The application must reject empty credentials on its own. The directory should also be hardened, but relying on server configuration alone leaves the application dependent on an external policy that may differ across environments.

For any LDAP-backed application, test the empty-password case during deployment. A login form that looks correct can still pass a protocol edge case through to the identity provider.

References

• VulnCheck advisory for CVE-2026-126777