Traccar: elusión de la autenticación LDAP con contraseña vacía (CVE-2026-126777)

Resumen

• Traccar envía una contraseña LDAP vacía al directorio y trata la vinculación no autenticada resultante como un inicio de sesión correcto. VulnCheck publicó el fallo como CVE-2026-126777 el 11 de noviembre de 2026.
• Todas las versiones de Traccar desde 3.15 hasta 6.16.0 están afectadas cuando la autenticación LDAP está activada y el directorio acepta vinculaciones no autenticadas.
• La puntuación es CVSS v4.0 9.1 Crítica y CVSS v3.1 7.4 Alta. No se conoce explotación y la CVE no está en el catálogo KEV de CISA a 12 de noviembre de 2026.
• Actualice a 6.17.0, publicado el 1 de noviembre de 2026. Si no puede, desactive la autenticación LDAP o bloquee el acceso al endpoint de sesión hasta que pueda.

¿Estoy afectado?

Está expuesto si se cumplen estas cuatro condiciones:

• Ejecuta Traccar 3.15 a 6.16.0.
• La autenticación LDAP está configurada. Traccar crea su proveedor LDAP cuando existe el ajuste ldap.url.
• El directorio LDAP acepta una vinculación no autenticada para un nombre de cuenta conocido. Los directorios que rechazan una contraseña de longitud cero no son explotables de esta forma.
• El atacante conoce un nombre de cuenta válido, como una dirección de correo o un identificador.

El fallo está en la ruta de inicio de sesión, así que afecta a la API web y a cualquier cliente que use autenticación HTTP Basic. No depende de la interfaz web de Traccar. Una cuenta administradora está tan expuesta como cualquier otra.

El ajuste ldap.force decide si todos los inicios de sesión usan LDAP o si se prueba LDAP junto con las cuentas locales. Un despliegue con ldap.force desactivado todavía puede ser atacado mediante un nombre de cuenta que exista en el directorio.

El endpoint del servidor de Traccar informa la versión en ejecución sin autenticación:

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

Confirme que LDAP está activado en el archivo de configuración del contenedor o del directorio de instalación:

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

Los mismos ajustes aparecen en el archivo traccar.xml de una instalación por paquete. Un despliegue sin ldap.url no usa el proveedor vulnerable.

¿Cómo lo corrijo?

Actualice a Traccar 6.17.0. La versión contiene la comprobación de tres líneas que rechaza una contraseña nula o vacía antes de que empiece la vinculación con el directorio.

1. Cambie la etiqueta de la imagen en su archivo compose a traccar/traccar:6.17.0, luego descargue la imagen y recree el contenedor. Un archivo compose que siga apuntando a otra etiqueta mantiene en ejecución la imagen vulnerable: docker pull traccar/traccar:6.17.0 docker compose up -d
2. Confirme la versión en ejecución: curl -s https://<traccar-host>/api/server | python3 -c "import json,sys; print(json.load(sys.stdin)['version'])"
3. En una instalación por paquete, descargue la versión 6.17.0, detenga el servicio, sustituya los archivos del programa y vuelva a iniciarlo.
4. Pruebe un inicio de sesión LDAP con una contraseña correcta y otro con una contraseña vacía. El intento con contraseña vacía debe fallar ahora.

Si no puede actualizar de inmediato, reduzca la exposición con estas medidas. Ninguna sustituye al parche.

1. Elimine el ajuste ldap.url para desactivar la autenticación LDAP y conserve al menos una cuenta administradora local utilizable. Traccar vuelve a su almacén de usuarios local.
2. Restrinja /api/session y la autenticación HTTP Basic a redes de confianza en el proxy. Esto cierra la ruta de inicio de sesión remota, pero no corrige la falta de comprobación de la contraseña.
3. Desactive las cuentas que LDAP autenticaría si no las necesita durante la ventana. El atacante sigue necesitando un nombre de cuenta válido, así que quitar el nombre quita la ruta.

¿Cuál es la causa raíz?

LdapProvider.login() acepta cualquier contraseña, incluida una cadena vacía, y usa la respuesta del directorio como prueba de que la contraseña era correcta.

El método busca primero la cuenta y después se vincula como esa cuenta con la contraseña recibida:

    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 se ejecuta con la cuenta de servicio. Devuelve el nombre distinguido de la cuenta solicitada. La vinculación usa después la contraseña enviada por el atacante:

    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 envía una vinculación simple con el nombre distinguido y la contraseña. Cuando la contraseña está vacía, la petición lleva una credencial de longitud cero. La RFC 4513 define esto como una vinculación no autenticada, y un directorio puede aceptarla y devolver un resultado correcto. Traccar nunca comprueba que el resultado venga de una vinculación autenticada con contraseña, así que devuelve true.

La búsqueda es lo que hace precisa el ataque: el atacante no necesita adivinar una contraseña ni un nombre distinguido, solo un nombre de cuenta válido.

¿Cómo se explota?

1. El atacante envía una petición de inicio de sesión a POST /api/session con un nombre de cuenta válido y una contraseña vacía.
2. Traccar llama a LdapProvider.login() con ese nombre y la contraseña vacía.
3. lookupUser() usa la cuenta de servicio para encontrar el nombre distinguido de la cuenta en el directorio.
4. auth() envía una vinculación simple con ese nombre distinguido y una contraseña de longitud cero.
5. Un directorio que permite vinculaciones no autenticadas devuelve un contexto. Traccar trata el contexto como una comprobación correcta de la contraseña.
6. Traccar crea una sesión para la cuenta, incluida una cuenta administradora si el nombre pertenece a una.

La misma ruta es accesible con autenticación HTTP Basic, que usa el mismo servicio de inicio de sesión. No hay código de prueba de concepto público y la petición no necesita herramientas especiales.

¿Cómo se desarrolla el ataque?

Un nombre de cuenta válido y una contraseña vacía llegan a una vinculación LDAP que el directorio responde sin comprobar una contraseña, y Traccar acepta esa respuesta como un inicio de sesión.

¿Qué puede hacer un atacante?

Un atacante que conoce el nombre de una cuenta administradora obtiene una sesión de administrador sin contraseña. Un administrador de Traccar ve la posición en vivo, el historial de rutas, los informes de eventos y los registros de mantenimiento de todos los dispositivos, y puede listar y gestionar todos los usuarios, dispositivos, geocercas, notificaciones e informes guardados. El administrador también puede enviar comandos a los dispositivos que los admiten, lo que puede inmovilizar un vehículo o cambiar su configuración.

Una sesión para una cuenta no administradora da acceso a los dispositivos y posiciones de esa cuenta. En un despliegue de flota, eso todavía puede exponer la ubicación en vivo de muchos vehículos. Una cuenta de operador de solo lectura expone el mismo historial de posiciones de los dispositivos que puede ver, lo que sigue siendo un dato sensible de la flota.

El fallo no da ejecución de código en el servidor por sí mismo. El impacto son los permisos de la cuenta, y la cuenta administradora es la que importa. El atacante necesita acceso de red al endpoint de inicio de sesión y un nombre de cuenta válido. No se requiere interacción del usuario.

¿Por qué funciona la corrección?

La corrección rechaza una contraseña nula o vacía antes de cualquier búsqueda o vinculación:

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

La comprobación se ejecuta antes de lookupUser, así que una contraseña vacía no puede llegar al directorio. Una contraseña no vacía sigue la ruta normal de vinculación simple. El directorio decide entonces si la credencial es correcta, y Traccar solo acepta un contexto que el directorio devolvió para esa credencial.

La corrección es completa para esta ruta. Traccar usa el mismo método auth() para sus búsquedas de cuenta de servicio, y esas llamadas envían una contraseña de servicio configurada. Un despliegue que defina una contraseña de servicio vacía seguiría realizando una vinculación de servicio no autenticada, así que mantenga ese ajuste no vacío también.

¿Cómo compruebo si estuve comprometido?

No hay indicadores publicados para esta CVE. Revise el directorio y los registros de acceso de Traccar para el patrón:

• Vinculaciones simples desde el host del servicio Traccar con una contraseña de longitud cero.
• Sesiones correctas de cuentas administradoras desde direcciones que no coinciden con las ubicaciones habituales del operador.
• Peticiones POST /api/session en el registro de acceso del proxy inverso desde direcciones de cliente fuera de sus rangos de confianza. Los registros de acceso guardan la ruta y la dirección del cliente, no el cuerpo de la petición, así que el campo de contraseña no es visible.

Un directorio que acepta vinculaciones no autenticadas puede registrarlas como anónimas o como una vinculación normal, según su configuración. Un intento fallido puede no dejar ninguna entrada. Trate una sesión de administrador inesperada como un compromiso y rote la contraseña de la cuenta y los tokens de API a los que tenga acceso.

Cronología

• 2026-10-31: El commit de corrección 552c31f2 añade la comprobación de contraseña vacía.
• 2026-11-01: Se publica Traccar 6.17.0 con la corrección.
• 2026-11-11: VulnCheck publica CVE-2026-126777 a las 18:41 UTC.

El commit de corrección es 11 días anterior al registro CVE: un día del commit a la versión, y 10 días de la versión a la divulgación.

Preguntas frecuentes

¿Afecta a todos los despliegues de Traccar?

No. El despliegue debe usar autenticación LDAP y el directorio debe aceptar una vinculación no autenticada para el nombre de cuenta. Una instancia de Traccar solo con cuentas locales no está afectada.

¿Puedo probar mi directorio de forma segura?

Sí, con una cuenta de prueba y un cliente controlado. Envíe una vinculación simple con un nombre distinguido válido y una contraseña de longitud cero, y compruebe si el directorio devuelve un resultado correcto. No lo pruebe con una cuenta administradora de producción.

¿Por qué una contraseña vacía cuenta como inicio de sesión?

LDAP define una vinculación con un nombre y una contraseña de longitud cero como una vinculación no autenticada. Algunos directorios la aceptan para permitir un acceso de tipo anónimo. Traccar no distinguía ese resultado de una vinculación autenticada con contraseña.

¿Se necesita la interfaz web?

No. El mismo servicio de inicio de sesión gestiona la interfaz web, POST /api/session y la autenticación HTTP Basic. Cualquier cliente que alcance el endpoint de inicio de sesión puede usar el fallo.

¿El ajuste ldap.force cambia la exposición?

No. El ajuste cambia qué cuentas usan LDAP, no si se acepta la vinculación con contraseña vacía. Una cuenta que existe en el directorio puede usarse por la ruta LDAP incluso cuando el inicio de sesión local también está activado.

¿6.17.0 cambia algo más?

La versión 6.17.0 contiene la comprobación de contraseña vacía y su conjunto habitual de funciones y correcciones. El cambio relevante para la seguridad es la guarda de tres líneas en LdapProvider.login().

¿La corrección rompe los inicios de sesión LDAP normales?

No. Una contraseña no vacía sigue la misma vinculación simple contra el directorio. La corrección solo rechaza una contraseña nula o vacía antes de la vinculación, así que los usuarios que escriben una contraseña no ven ningún cambio.

¿Debo rotar las contraseñas?

Sí, si se pudo crear una sesión de administrador sin contraseña. Rote la contraseña de la cuenta afectada y revise sus acciones recientes. Un directorio que aceptó una vinculación no autenticada no verificó al atacante, así que la contraseña no se expuso, pero la sesión sí.

Referencias

• Aviso de VulnCheck para CVE-2026-126777, https://www.vulncheck.com/advisories/traccar-3.15-before-6.17.0-authentication-bypass-via-empty-ldap-password (comprobado el 12 de noviembre de 2026).
• Registro CVE-2026-126777, https://www.cve.org/CVERecord?id=CVE-2026-126777 (comprobado el 12 de noviembre de 2026).
• Commit de corrección de Traccar 552c31f2, https://github.com/traccar/traccar/commit/552c31f2097dbed9edef7cfe174c50b16febdc21 (comprobado el 12 de noviembre de 2026).
• Versión Traccar 6.17.0, https://github.com/traccar/traccar/releases/tag/v6.17.0 (comprobada el 12 de noviembre de 2026).
• Código de Traccar v6.16.0, LdapProvider.java, https://github.com/traccar/traccar/blob/v6.16.0/src/main/java/org/traccar/database/LdapProvider.java (comprobado el 12 de noviembre de 2026).
• Código de Traccar v6.17.0, LdapProvider.java, https://github.com/traccar/traccar/blob/v6.17.0/src/main/java/org/traccar/database/LdapProvider.java (comprobado el 12 de noviembre de 2026).
• RFC 4513, sección 5.1.2, Unauthenticated Bind Operation, https://www.rfc-editor.org/rfc/rfc4513#section-5.1.2 (comprobada el 12 de noviembre de 2026).
• Repositorio de Traccar, https://github.com/traccar/traccar (comprobado el 12 de noviembre de 2026).
• Catálogo de vulnerabilidades explotadas de CISA, https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 12 de noviembre de 2026).