Traccar : contournement de l'authentification LDAP par mot de passe vide (CVE-2026-126777)

En bref

• Traccar envoie un mot de passe LDAP vide à l'annuaire et traite la liaison non authentifiée qui en résulte comme une connexion réussie. VulnCheck a publié la faille sous CVE-2026-126777 le 11 novembre 2026.
• Toutes les versions de Traccar de 3.15 à 6.16.0 sont concernées lorsque l'authentification LDAP est activée et que l'annuaire accepte les liaisons non authentifiées.
• Le score est CVSS v4.0 9,1 Critique et CVSS v3.1 7,4 Élevé. Aucune exploitation n'est connue et la CVE n'est pas dans le catalogue KEV de la CISA au 12 novembre 2026.
• Mettez à niveau vers 6.17.0, publié le 1er novembre 2026. Si vous ne pouvez pas, désactivez l'authentification LDAP ou bloquez l'accès au point de terminaison de session jusqu'à la mise à jour.

Suis-je concerné ?

Vous êtes exposé si les quatre conditions suivantes sont réunies :

• Vous exploitez Traccar 3.15 à 6.16.0.
• L'authentification LDAP est configurée. Traccar crée son fournisseur LDAP lorsque le paramètre ldap.url est présent.
• L'annuaire LDAP accepte une liaison non authentifiée pour un nom de compte connu. Les annuaires qui rejettent un mot de passe de longueur nulle ne sont pas exploitables ainsi.
• L'attaquant connaît un nom de compte valide, par exemple une adresse électronique ou un identifiant.

La faille est dans le chemin de connexion : elle touche l'API web et tout client qui utilise l'authentification HTTP Basic. Elle ne dépend pas de l'interface web de Traccar. Un compte administrateur est aussi exposé qu'un autre compte.

Le réglage ldap.force détermine si toutes les connexions utilisent LDAP ou si LDAP est essayé en parallèle des comptes locaux. Un déploiement avec ldap.force désactivé peut toujours être attaqué via un nom de compte présent dans l'annuaire.

Le point de terminaison du serveur Traccar indique la version en cours sans authentification :

curl -s https://<traccar-host>/api/server | python3 -c "import json,sys; print(json.load(sys.stdin)['version'])"

Vérifiez que LDAP est activé dans le fichier de configuration du conteneur ou du répertoire d'installation :

docker exec traccar sh -c 'grep -n "ldap\." /opt/traccar/conf/traccar.xml'

Les mêmes paramètres figurent dans le fichier traccar.xml d'une installation par paquet. Un déploiement sans ldap.url n'utilise pas le fournisseur vulnérable.

Comment corriger ?

Mettez à niveau vers Traccar 6.17.0. La version contient le contrôle de trois lignes qui rejette un mot de passe nul ou vide avant le début de la liaison à l'annuaire.

1. Remplacez le tag de l'image dans votre fichier compose par traccar/traccar:6.17.0, puis tirez l'image et recréez le conteneur. Un fichier compose qui référence encore un autre tag laisse tourner l'image vulnérable : docker pull traccar/traccar:6.17.0 docker compose up -d
2. Confirmez la version en cours : curl -s https://<traccar-host>/api/server | python3 -c "import json,sys; print(json.load(sys.stdin)['version'])"
3. Pour une installation par paquet, téléchargez la version 6.17.0, arrêtez le service, remplacez les fichiers du programme et redémarrez-le.
4. Testez une connexion LDAP avec un mot de passe correct et une avec un mot de passe vide. La tentative avec mot de passe vide doit maintenant échouer.

Si vous ne pouvez pas mettre à jour immédiatement, réduisez l'exposition avec ces mesures. Aucune ne remplace le correctif.

1. Supprimez le paramètre ldap.url pour désactiver l'authentification LDAP, et conservez au moins un compte administrateur local utilisable. Traccar revient à son magasin d'utilisateurs local.
2. Restreignez /api/session et l'authentification HTTP Basic aux réseaux de confiance au proxy. Cela ferme le chemin de connexion distant mais ne corrige pas l'absence de contrôle du mot de passe.
3. Désactivez les comptes que LDAP authentifierait si vous n'en avez pas besoin pendant la fenêtre. L'attaquant a encore besoin d'un nom de compte valide, donc retirer le nom retire le chemin.

Quelle est la cause racine ?

LdapProvider.login() accepte n'importe quel mot de passe, y compris une chaîne vide, et utilise la réponse de l'annuaire comme preuve que le mot de passe était correct.

La méthode recherche d'abord le compte, puis se lie sous ce compte avec le mot de passe fourni :

    public boolean login(String username, String password) {
        try {
            SearchResult ldapUser = lookupUser(username);
            if (ldapUser != null) {
                auth(ldapUser.getNameInNamespace(), password).close();
                return true;
            }
        } catch (NamingException e) {
            return false;
        }
        return false;
    }

lookupUser utilise le compte de service. Il renvoie le nom distinctif du compte demandé. La liaison utilise ensuite le mot de passe fourni par l'attaquant :

    private InitialDirContext auth(String accountName, String password) throws NamingException {
        Hashtable<String, String> env = new Hashtable<>();
        env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
        env.put(Context.PROVIDER_URL, url);

        env.put(Context.SECURITY_AUTHENTICATION, "simple");
        env.put(Context.SECURITY_PRINCIPAL, accountName);
        env.put(Context.SECURITY_CREDENTIALS, password);

        return new InitialDirContext(env);
    }

JNDI de Java envoie une liaison simple avec le nom distinctif et le mot de passe. Quand le mot de passe est vide, la requête porte un justificatif de longueur nulle. La RFC 4513 définit cela comme une liaison non authentifiée, et un annuaire peut l'accepter et renvoyer un résultat de succès. Traccar ne vérifie jamais que le résultat provient d'une liaison authentifiée par mot de passe, donc il renvoie true.

La recherche rend l'attaque précise : l'attaquant n'a pas besoin de deviner un mot de passe ou un nom distinctif, seulement un nom de compte valide.

Comment la faille est-elle exploitée ?

1. L'attaquant envoie une demande de connexion à POST /api/session avec un nom de compte valide et un mot de passe vide.
2. Traccar appelle LdapProvider.login() avec ce nom et le mot de passe vide.
3. lookupUser() utilise le compte de service pour trouver le nom distinctif du compte dans l'annuaire.
4. auth() envoie une liaison simple avec ce nom distinctif et un mot de passe de longueur nulle.
5. Un annuaire qui autorise les liaisons non authentifiées renvoie un contexte. Traccar traite ce contexte comme une vérification réussie du mot de passe.
6. Traccar crée une session pour le compte, y compris un compte administrateur si le nom lui appartient.

Le même chemin est accessible avec l'authentification HTTP Basic, qui utilise le même service de connexion. Aucun code de preuve de concept public n'est publié, et la requête ne demande aucun outil particulier.

Comment se déroule l'attaque ?

Un nom de compte valide et un mot de passe vide atteignent une liaison LDAP que l'annuaire traite sans vérifier de mot de passe, et Traccar accepte cette réponse comme une connexion.

Que peut faire un attaquant ?

Un attaquant qui connaît le nom d'un compte administrateur obtient une session administrateur sans mot de passe. Un administrateur Traccar voit la position en direct, l'historique des trajets, les rapports d'événements et les dossiers de maintenance de tous les appareils, et peut lister et gérer tous les utilisateurs, appareils, géofences, notifications et rapports enregistrés. L'administrateur peut aussi envoyer des commandes aux appareils qui les prennent en charge, ce qui peut immobiliser un véhicule ou modifier sa configuration.

Une session pour un compte non administrateur donne accès aux appareils et positions de ce compte. Dans un déploiement de flotte, cela peut encore exposer les positions en direct de nombreux véhicules. Un compte opérateur en lecture seule expose le même historique de positions pour les appareils qu'il peut voir, ce qui reste une donnée de flotte sensible.

La faille ne donne pas d'exécution de code sur le serveur par elle-même. L'impact correspond aux permissions du compte, et le compte administrateur est celui qui compte. L'attaquant a besoin d'un accès réseau au point de terminaison de connexion et d'un nom de compte valide. Aucune interaction utilisateur n'est nécessaire.

Pourquoi le correctif fonctionne-t-il ?

Le correctif rejette un mot de passe nul ou vide avant toute recherche ou liaison :

     public boolean login(String username, String password) {
+        if (password == null || password.isEmpty()) {
+            return false;
+        }
         try {
             SearchResult ldapUser = lookupUser(username);
             if (ldapUser != null) {

Le contrôle s'exécute avant lookupUser, donc un mot de passe vide ne peut pas atteindre l'annuaire. Un mot de passe non vide suit toujours le chemin de liaison simple normal. L'annuaire décide alors si le justificatif est correct, et Traccar n'accepte qu'un contexte renvoyé par l'annuaire pour ce justificatif.

Le correctif est complet pour ce chemin. Traccar utilise la même méthode auth() pour ses recherches de compte de service, et ces appels transmettent un mot de passe de service configuré. Un déploiement qui définit un mot de passe de service vide effectuerait encore une liaison de service non authentifiée, donc gardez ce paramètre non vide également.

Comment vérifier si j'ai été compromis ?

Il n'existe aucun indicateur publié pour cette CVE. Vérifiez l'annuaire et les journaux d'accès de Traccar pour le schéma suivant :

• Liaisons simples depuis l'hôte du service Traccar avec un mot de passe de longueur nulle.
• Sessions réussies pour des comptes administrateur depuis des adresses qui ne correspondent pas aux emplacements habituels de l'opérateur.
• Requêtes POST /api/session dans le journal d'accès du proxy inverse provenant d'adresses clientes hors de vos plages de confiance. Les journaux d'accès enregistrent le chemin et l'adresse du client, pas le corps de la requête : le champ de mot de passe n'y est donc pas visible.

Un annuaire qui accepte les liaisons non authentifiées peut les journaliser comme anonymes ou comme une liaison normale, selon sa configuration. Une tentative échouée peut ne laisser aucune entrée. Traitez une session administrateur inattendue comme une compromission et faites tourner le mot de passe du compte et les jetons d'API auxquels il a accès.

Chronologie

• 2026-10-31 : Le commit de correction 552c31f2 ajoute le contrôle du mot de passe vide.
• 2026-11-01 : Traccar 6.17.0 est publié avec le correctif.
• 2026-11-11 : VulnCheck publie CVE-2026-126777 à 18:41 UTC.

Le correctif a été commité 11 jours avant l'enregistrement CVE : un jour du commit à la version, et 10 jours de la version à la divulgation.

FAQ

Tous les déploiements Traccar sont-ils concernés ?

Non. Le déploiement doit utiliser l'authentification LDAP, et l'annuaire doit accepter une liaison non authentifiée pour le nom de compte. Une instance Traccar avec uniquement des comptes locaux n'est pas concernée.

Puis-je tester mon annuaire sans risque ?

Oui, avec un compte de test et un client contrôlé. Envoyez une liaison simple avec un nom distinctif valide et un mot de passe de longueur nulle, puis vérifiez si l'annuaire renvoie un succès. Ne testez pas avec un compte administrateur de production.

Pourquoi un mot de passe vide compte-t-il comme une connexion ?

LDAP définit une liaison avec un nom et un mot de passe de longueur nulle comme une liaison non authentifiée. Certains annuaires l'acceptent pour prendre en charge un accès de type anonyme. Traccar ne distinguait pas ce résultat d'une liaison authentifiée par mot de passe.

L'interface web est-elle nécessaire ?

Non. Le même service de connexion gère l'interface web, POST /api/session et l'authentification HTTP Basic. Tout client qui atteint le point de terminaison de connexion peut utiliser la faille.

Le réglage ldap.force change-t-il l'exposition ?

Non. Le réglage change quels comptes utilisent LDAP, pas si la liaison avec mot de passe vide est acceptée. Un compte présent dans l'annuaire peut être utilisé via le chemin LDAP même lorsque la connexion locale est aussi activée.

6.17.0 change-t-il autre chose ?

La version 6.17.0 contient le contrôle du mot de passe vide et son ensemble habituel de fonctionnalités et de corrections. Le changement lié à la sécurité est la garde de trois lignes dans LdapProvider.login().

Le correctif casse-t-il les connexions LDAP normales ?

Non. Un mot de passe non vide suit toujours la même liaison simple auprès de l'annuaire. Le correctif rejette seulement un mot de passe nul ou vide avant la liaison, donc les utilisateurs qui saisissent un mot de passe ne voient aucun changement.

Dois-je faire tourner les mots de passe ?

Oui, si une session administrateur a pu être créée sans mot de passe. Faites tourner le mot de passe du compte concerné et examinez ses actions récentes. Un annuaire qui a accepté une liaison non authentifiée n'a pas vérifié l'attaquant, donc le mot de passe lui-même n'a pas été exposé, mais la session l'a été.

Références

• Avis VulnCheck pour CVE-2026-126777, https://www.vulncheck.com/advisories/traccar-3.15-before-6.17.0-authentication-bypass-via-empty-ldap-password (vérifié le 12 novembre 2026).
• Enregistrement CVE-2026-126777, https://www.cve.org/CVERecord?id=CVE-2026-126777 (vérifié le 12 novembre 2026).
• Commit de correction Traccar 552c31f2, https://github.com/traccar/traccar/commit/552c31f2097dbed9edef7cfe174c50b16febdc21 (vérifié le 12 novembre 2026).
• Version Traccar 6.17.0, https://github.com/traccar/traccar/releases/tag/v6.17.0 (vérifiée le 12 novembre 2026).
• Source Traccar v6.16.0, LdapProvider.java, https://github.com/traccar/traccar/blob/v6.16.0/src/main/java/org/traccar/database/LdapProvider.java (vérifiée le 12 novembre 2026).
• Source Traccar v6.17.0, LdapProvider.java, https://github.com/traccar/traccar/blob/v6.17.0/src/main/java/org/traccar/database/LdapProvider.java (vérifiée le 12 novembre 2026).
• RFC 4513, section 5.1.2, Unauthenticated Bind Operation, https://www.rfc-editor.org/rfc/rfc4513#section-5.1.2 (vérifiée le 12 novembre 2026).
• Dépôt Traccar, https://github.com/traccar/traccar (vérifié le 12 novembre 2026).
• Catalogue des vulnérabilités exploitées de la CISA, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 12 novembre 2026).