¿Qué es la inyección LDAP?
La inyección LDAP es un ataque del lado del servidor que explota aplicaciones web que construyen consultas del Protocolo Ligero de Acceso a Directorios a partir de entradas de usuario no saneadas. Cuando su aplicación no neutraliza correctamente los caracteres especiales antes de incorporarlos en las consultas LDAP, los atacantes pueden manipular esas consultas para eludir la autenticación, extraer datos sensibles del directorio o modificar entradas dentro del árbol LDAP.
Los directorios LDAP están en el núcleo de la infraestructura de identidad empresarial. Almacenan credenciales de usuario, membresías de grupos, listas de control de acceso, estructuras organizativas y detalles de cuentas de servicio. Un solo ataque exitoso de inyección LDAP puede exponer este repositorio, otorgando a un atacante las llaves de su infraestructura de autenticación.
MITRE clasifica esta vulnerabilidad como MITRE CWE-90: Neutralización incorrecta de elementos especiales utilizados en una consulta LDAP. OWASP la incluye bajo OWASP Injection y la categoría actualizada de OWASP Injection. La vulnerabilidad comparte su causa raíz con la inyección SQL, pero apunta a un sistema fundamentalmente diferente y, a menudo, más crítico: el servicio de directorio que gobierna quién puede acceder a qué en toda su organización.
Comprender cómo funciona la inyección LDAP requiere conocer la sintaxis de consulta que los atacantes explotan.
.jpg)
¿Cómo funciona la inyección LDAP?
Los filtros de búsqueda LDAP siguen una gramática específica definida en la sintaxis LDAP. Los filtros usan notación polaca (notación prefija), donde una consulta de autenticación simple se ve así:
El operador & realiza un AND booleano. Los paréntesis agrupan condiciones. El comodín * coincide con cualquier valor. Estos metacaracteres, junto con | (OR), ! (NOT), =, ~=, >=, <=, y () operadores de agrupación, forman la superficie de inyección.
Cuando un desarrollador construye un filtro concatenando directamente la entrada del usuario en la cadena de consulta, esos metacaracteres se convierten en armas. Si un formulario de inicio de sesión inserta el nombre de usuario directamente en un filtro como (&(uid=INPUT)(userPassword=HASH)), un atacante que envía metacaracteres manipulados puede cambiar completamente la lógica del filtro: eludir la autenticación, devolver todas las entradas del directorio o extraer datos carácter por carácter.
La técnica específica que utiliza un atacante depende del tipo de inyección LDAP.
Tipos de inyección LDAP
La inyección LDAP adopta varias formas distintas, cada una dirigida a un aspecto diferente de cómo las aplicaciones interactúan con el directorio. El tipo que utiliza un atacante depende del comportamiento de la aplicación, el contexto de la consulta y lo que el atacante puede observar en la respuesta.
| Tipo | Técnica | Consecuencia |
| Inyección de filtro de búsqueda | Manipulación de filtro basada en comodines u OR | Enumeración completa del directorio |
| Elusión de autenticación | Inyección de filtro siempre verdadero | Inicio de sesión no autorizado como cualquier usuario |
| Inyección LDAP ciega | Análisis diferencial carácter por carácter | Extracción silenciosa de datos |
| Manipulación de DN | Contexto de escape incorrecto aplicado a campos DN | Inyección en componentes de consulta no basados en filtros |
Inyección de filtro de búsqueda
Considere este código Java vulnerable:
Si un atacante envía user=*, el filtro resultante se convierte en (cn=*), que coincide con cada objeto en el directorio con un atributo cn. Su aplicación devuelve todo el directorio de usuarios en lugar de un solo registro.
Elusión de autenticación
Los flujos de autenticación LDAP representan el objetivo de inyección de mayor consecuencia. Un filtro de inicio de sesión vulnerable como este:
Este filtro puede ser eludido inyectando )(uid=))(|(uid=* como nombre de usuario. El filtro resultante se evalúa como siempre verdadero, otorgando al atacante estado autenticado como el primer usuario en el árbol LDAP, a menudo una cuenta de administrador. La guía de pruebas documenta esto como el análogo directo a las técnicas de elusión de autenticación por inyección SQL.
Inyección LDAP ciega
Cuando las aplicaciones no muestran directamente los resultados de la consulta, los atacantes usan respuestas diferenciales para extraer datos. Al inyectar condiciones de filtro como (attribute=a*), (attribute=b*) y observar si la aplicación devuelve un resultado o una página vacía, extraen valores de atributos carácter por carácter. La investigación presentada en el artículo de Black Hat demostró que los filtros del lado del cliente que limitan la información mostrada no previenen las técnicas de inyección ciega.
Manipulación de Distinguished Name
LDAP tiene contextos de escape distintos, y confundirlos crea vectores de inyección. Los filtros de búsqueda requieren escape según RFC 4515 (*→\2a, (→\28, )→\29). Los Distinguished Names (DN) requieren escape según RFC 2253 (\, #, +, <, >, ,, ;, ", =). Aplicar el contexto de escape incorrecto al campo incorrecto deja su aplicación vulnerable incluso cuando cree haber resuelto el problema.
Estos tipos de ataque comparten causas raíz comunes que van más allá de la sintaxis.
Causas de la inyección LDAP
Las vulnerabilidades de inyección LDAP provienen de una combinación de prácticas de codificación, limitaciones de bibliotecas y configuraciones incorrectas de infraestructura. Cada causa raíz crea un camino independiente hacia la explotación.
- Concatenación directa de cadenas. La causa inmediata en casi todas las vulnerabilidades de inyección LDAP es la concatenación de datos controlados por el usuario directamente en cadenas de filtro LDAP en la capa de aplicación. Las bibliotecas LDAP históricamente carecen de soporte integrado para consultas parametrizadas, lo que requiere que los desarrolladores sigan la guía manual para la construcción segura de consultas. Existen interfaces parametrizadas pero requieren adopción deliberada.
- Manejo incorrecto de caracteres especiales. Las aplicaciones que intentan validar la entrada a menudo implementan listas de denegación incompletas que omiten caracteres peligrosos. Una lista de denegación que bloquea * y ( pero omite ) o bytes NUL aún deja una brecha explotable. MITRE CWE-90 identifica la inyección LDAP como resultado de este fallo, lo que significa que la vulnerabilidad de inyección surge directamente de la gestión incorrecta de caracteres especiales.
- Confusión de contexto de escape. La hoja de referencia LDAP documenta que aplicar el escape de filtro de búsqueda a campos DN, o el escape de DN a campos de filtro de búsqueda, crea vectores de inyección por selección incorrecta de contexto. Si sus desarrolladores saben que deben escapar pero eligen la función incorrecta, su aplicación sigue siendo vulnerable.
- Configuraciones de bind anónimo y no autenticado. Los servidores LDAP configurados para permitir bind anónimo permiten a los atacantes eludir la autenticación de bind por completo.
- Uso generalizado de LDAP para autenticación. El papel de LDAP como columna vertebral de autenticación en entornos empresariales significa que la inyección contra flujos de inicio de sesión produce el resultado de mayor consecuencia: acceso autenticado a recursos empresariales. La superficie de ataque es de alcance empresarial por diseño arquitectónico.
Estas causas se combinan para crear riesgos que van mucho más allá de una sola consulta comprometida.
Impacto y riesgo de la inyección LDAP
Los ataques de inyección LDAP pueden producir varias categorías de impacto empresarial, cada una aumentando en gravedad.
Elusión de autenticación
Una inyección de filtro siempre verdadero otorga acceso autenticado inmediato. CVE-2023-4501 en OpenText Enterprise Server permitía que la autenticación tuviera éxito con cualquier nombre de usuario válido independientemente de si la contraseña era correcta, y también podía tener éxito con un nombre de usuario inválido y cualquier contraseña. Esto afectó entornos empresariales de desarrollo y ejecución COBOL desplegados en servicios financieros, seguros y gobierno.
Exfiltración de datos sensibles
Los directorios LDAP contienen credenciales de usuario, hashes de contraseñas, direcciones de correo electrónico, jerarquías organizativas, membresías de grupos, ACLs, cuentas de computadoras y identificadores de seguridad. Un aviso de CISA documentó una sola consulta LDAP que recuperaba información sobre usuarios, computadoras, grupos, ACLs, OUs y GPOs de un directorio empresarial.
Escalada de privilegios
Una inyección exitosa puede otorgar permisos para consultas no autorizadas y permitir la modificación de contenido dentro del árbol LDAP. CVE-2026-31828 en Parse Server permitía a usuarios autenticados de bajo privilegio escalar a cualquier grupo restringido mediante inyección de filtro LDAP.
Denegación de servicio
CVE-2025-12764 (pgAdmin) demostró la inyección LDAP utilizada para forzar al servidor y cliente DC/LDAP a procesar una cantidad inusual de datos, causando una denegación de servicio contra la infraestructura de directorio con fallos de autenticación en cascada.
Habilitación de movimiento lateral
La enumeración LDAP alimenta el reconocimiento de Active Directory. El aviso del equipo rojo de CISA documentó que los datos LDAP permitieron el mapeo de usuarios, computadoras, grupos, ACLs, OUs y GPOs, todos los cuales sirven como insumos para la planificación de movimiento lateral. La empresa evaluada no tenía visibilidad para esta actividad.
OWASP califica la explotabilidad de la inyección en 3 (Fácil) y el impacto técnico en 3 (Grave) en su marco OWASP. La inyección LDAP también conlleva consecuencias directas de cumplimiento: PCI DSS 6.5.1 nombra explícitamente la inyección LDAP junto con la inyección SQL y XPath como objetivo de evaluación obligatoria.
Comprender el impacto le ayuda a priorizar defensas, pero también necesita saber exactamente cómo los atacantes encuentran y aprovechan estas fallas.
Cómo explotan los atacantes la inyección LDAP
Los atacantes siguen una metodología estructurada para encontrar y explotar vulnerabilidades de inyección LDAP, avanzando desde el reconocimiento hasta la extracción completa de credenciales.
Paso 1: Identificar puntos de entrada integrados con LDAP
El atacante identifica funciones de la aplicación que probablemente consulten un backend LDAP. Según el blog LDAP de SANS, LDAP puede usarse para gestión, autenticación y consulta de objetos de una base de datos de directorio. Formularios de inicio de sesión, páginas de búsqueda de usuarios, flujos de restablecimiento de contraseña, búsquedas de directorio corporativo y portales de VPN son todas superficies candidatas.
Paso 2: Sondear puntos de inyección
La prueba LDAP de OWASP instruye a los evaluadores a insertar caracteres (, |, &, * para comprobar respuestas diferenciales. Mensajes de error, conjuntos de resultados vacíos o cambios en el comportamiento de la aplicación confirman un parámetro vulnerable.
Paso 3: Inferir la estructura del filtro
Sin código fuente, los atacantes infieren la estructura del filtro LDAP mediante fuzzing. SANS señala: "Es poco probable durante una prueba de penetración que tenga el código fuente para ver estas sentencias. En estas situaciones, puede ser necesario emplear fuzzing y reconocimiento."
Paso 4: Crear cargas útiles de inyección
Las cargas útiles comunes incluyen:
- Inyección de comodín
(*)para recuperar todas las entradas del directorio - Filtros siempre verdaderos
()(uid=))(|(uid=*)para eludir la autenticación - Inyección de atributo basada en OR ()(department=it)(|(cn=) para recolectar credenciales en múltiples atributos
- Terminación de clase de objeto nula
(*)(objectClass=*))(& (objectClass=void)para establecer un oráculo booleano confiable para extracción ciega
La carga útil específica depende de la estructura del filtro que el atacante ha inferido durante el reconocimiento.
Paso 5: Escalar mediante cadenas de ataque
Una cadena de ataque típica documentada en fuentes de OWASP y MITRE ATT&CK sigue esta progresión:
- Eludir el inicio de sesión usando un filtro siempre verdadero
- Extraer credenciales de dominio mediante inyección basada en OR
- Crear cuentas de dominio mediante ldapmodify (ATT&CK T1136.002)
- Volcar NTDS.dit para descifrado de credenciales fuera de línea (ATT&CK T1003.003)
La inyección LDAP ciega permite una cadena paralela donde los atacantes enumeran atributos de esquema usando sondas (attribute=*) y luego extraen valores carácter por carácter, incluidos hashes de contraseñas, membresías de grupos e identificadores de seguridad.
Estos patrones de explotación afectan a una amplia gama de organizaciones y tipos de aplicaciones.
¿Quiénes se ven afectados por la inyección LDAP?
Cualquier organización que dependa de autenticación respaldada por LDAP enfrenta una exposición estructural a esta vulnerabilidad. OWASP señala que las vulnerabilidades de inyección son "muy prevalentes particularmente en código heredado."
Tipos de aplicaciones con mayor exposición incluyen:
- Aplicaciones web con autenticación respaldada por LDAP (portales de inicio de sesión, sistemas SSO)
- Aplicaciones empresariales heredadas que usan consultas LDAP concatenadas como cadenas
- Portales de restablecimiento de contraseña de autoservicio y directorios de empleados
- Portales de VPN y acceso remoto
- Plataformas de gestión de sistemas de control industrial
- Aplicaciones de escritorio (OWASP Desktop App Security Top 10 enumera la inyección LDAP bajo DA1 Injections)
Industrias con riesgo concentrado incluyen:
- Salud: Los sistemas EHR y clínicos respaldados por LDAP enfrentan cumplimiento HIPAA por vulnerabilidades no corregidas, con HHS documentando datos de brechas de HHS en grandes incidentes entre 2018 y 2022.
- Servicios financieros: La inyección sigue siendo una superficie de ataque relevante para sistemas empresariales vinculados a identidad en este sector.
- Gobierno e Infraestructura Crítica: CISA ha documentado explotación activa en entornos gubernamentales y plataformas ICS del sector energético.
- Software y Tecnología: Backends de código abierto, herramientas de bases de datos y plataformas de desarrollo continúan produciendo nuevos CVEs de inyección LDAP.
La inyección LDAP afecta a una amplia gama de software, abarcando entornos COBOL empresariales, herramientas de administración de bases de datos, plataformas del sector energético y backends de código abierto. Estos no son riesgos hipotéticos; incidentes recientes los confirman.
Ejemplos reales de inyección LDAP
Los siguientes casos ilustran cómo la inyección LDAP se manifiesta en redes gubernamentales, plataformas empresariales y herramientas de código abierto.
CISA Red Team: Empresa sin visibilidad LDAP (2024)
Una evaluación de CISA encontró que la empresa evaluada "no tenía monitoreo para tráfico LDAP anómalo." El equipo consultó LDAPS para recopilar información sobre usuarios, computadoras, grupos, ACLs, OUs y GPOs. CISA declaró explícitamente que un usuario no privilegiado consultando LDAP desde un host de dominio Linux "debería haber alertado a los defensores de la red."
OpenText Enterprise Server: Elusión completa de autenticación (CVE-2023-4501)
Esta vulnerabilidad permitía que la autenticación tuviera éxito con cualquier nombre de usuario válido independientemente de la contraseña, y también podía tener éxito con un nombre de usuario inválido. Afectó entornos empresariales de desarrollo y ejecución COBOL desplegados en servicios financieros, seguros e integración de mainframe gubernamental.
Ivanti EPMM: Actores de amenazas extraen credenciales LDAP (2025)
Tras la publicación de una prueba de concepto en mayo de 2025, actores de amenazas obtuvieron acceso a un servidor Ivanti EPMM y extrajeron credenciales LDAP. CISA añadió las vulnerabilidades subyacentes al catálogo KEV el 19 de mayo de 2025.
Redash: Inyección LDAP que permite Password Spraying (CVE-2020-36144)
GitHub Security Lab documentó que el campo de correo electrónico en la autenticación LDAP de Redash formateaba una cadena de consulta LDAP sin escape, permitiendo a un atacante no autenticado forzar contraseñas de todos los usuarios con una sola solicitud.
Estos incidentes abarcan décadas de desafíos de seguridad LDAP.
Línea de tiempo e historia de la inyección LDAP
La inyección LDAP ha sido una clase de vulnerabilidad conocida durante más de dos décadas, con clasificación formal y divulgaciones continuas de CVE desde finales de los años noventa hasta la actualidad.
- Orígenes del protocolo. El Protocolo de Acceso a Directorios X.500 (DAP) fue desarrollado por ITU-T. LDAP v1 apareció en RFC 1487, v2 en RFC 1777 y v3 en RFC 2251, que sigue siendo la versión en uso empresarial hoy.
- Primer problema documentado. CVE-1999-0895 documentó un problema temprano de seguridad de autenticación LDAP en Checkpoint FireWall-1 V4.0.
- Clasificación formal. OWASP documentó formalmente la inyección LDAP como una clase de ataque distinta. El OWASP Top 10 de 2007 la mapeó bajo A2, Fallos de Inyección.
- Investigación de inyección ciega. Alonso et al. presentaron investigación sistemática de inyección LDAP ciega en Black Hat Europe, demostrando extracción de datos carácter por carácter.
- Pico de prioridad OWASP. OWASP Top 10 2017 clasificó la Inyección como A1, el principal riesgo de aplicaciones web, nombrando explícitamente la inyección LDAP.
- Objetivo ICS. CVE-2018-14805 (ABB eSOMS) llevó la inyección LDAP al espacio ICS del sector energético.
- Objetivo de plataformas empresariales. ForgeRock OpenAM, OpenLDAP y OpenText Enterprise Server demostraron impacto empresarial continuo.
- Divulgación reciente. Nuevos CVEs en los últimos años afectan a Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax y pgAdmin.
Siguen apareciendo nuevos CVEs, lo que hace que el monitoreo continuo sea un requisito práctico.
Cómo detectar la inyección LDAP
Necesita monitoreo en capas a través de los niveles de aplicación, directorio y red.
Indicadores a nivel de aplicación
Monitoree los campos de entrada de usuario en busca de metacaracteres LDAP: *, (, ), \ y bytes NUL en parámetros de autenticación y búsqueda. Observe conjuntos de resultados LDAP anormalmente grandes que sugieran inyección de comodín devolviendo todas las entradas del directorio. El éxito de autenticación inmediatamente después de una consulta malformada indica un patrón de elusión de autenticación.
Indicadores a nivel de servidor LDAP
Busque estructuras de filtro que contengan secuencias )( o |(, que indican manipulación de grupos de filtros. Consultas que devuelven todas las entradas mediante (objectClass=*) o (cn=*) sugieren enumeración por comodín. El bind anónimo seguido de operaciones de búsqueda amplias indica intentos de reconocimiento no autenticado.
Monitoreo de SIEM y registros de eventos
Para entornos Active Directory, dos IDs de evento de Windows son críticos:
- ID de evento 4662: Operaciones realizadas sobre objetos de AD. Monitoree acciones Write Property, Control Access, DELETE, WRITE_DAC y WRITE_OWNER.
- ID de evento 1644: Consultas LDAP costosas o ineficientes, que los intentos de inyección suelen producir.
Según la guía de NCC Group: "Busque filtros de búsqueda inusuales en los registros. Los atacantes suelen usar filtros específicos para enumerar usuarios, grupos y computadoras."
Patrones de correlación de comportamiento
Correlacione entre fuentes de datos para encontrar campañas de inyección:
- Alto volumen de consultas LDAP desde una sola IP de origen (herramientas de inyección)
- Enumeración secuencial de atributos:
uid=a*, uid=b*(extracción por inyección ciega) - Contraseña fallida seguida de éxito inmediato de inicio de sesión (confirmación de elusión de autenticación)
- Host de dominio Linux no privilegiado realizando consultas LDAP masivas (el patrón exacto documentado por CISA como no detectado)
Correlacionar estas señales entre fuentes le da una imagen más clara de campañas activas de inyección que cualquier indicador individual.
Monitoreo a nivel WAF
OWASP ModSecurity Core Rule Set incluye la Regla ID 921200 en REQUEST-921-PROTOCOL-ATTACK.conf, que apunta a la inyección LDAP con severidad CRITICAL y Paranoia Level 1 (habilitado por defecto). La regla inspecciona cookies de solicitud, nombres de argumentos, valores de argumentos y cuerpos XML en busca de patrones de metacaracteres de filtro LDAP.
Encontrar actividad sospechosa es insuficiente sin controles de prevención adecuados.
Cómo prevenir la inyección LDAP
La prevención requiere un enfoque de defensa en profundidad que abarque los niveles de código, configuración e infraestructura.
Defensas a nivel de código
- Utilice consultas LDAP parametrizadas. La defensa más eficaz es pasar la entrada del usuario como parámetros en lugar de concatenarla en cadenas de filtro:
- Aplique escape apropiado al contexto. Utilice la función de escape correcta para el contexto LDAP adecuado. Para filtros de búsqueda (RFC 4515), escape *→
\2a, (→\28, )→\29, \→\5c, NUL→\00. Para Distinguished Names (RFC 2253), escape\, #, +, <, >, ,, ;, ", =y espacios iniciales/finales.
Las implementaciones específicas por lenguaje incluyen:
| Lenguaje | Escape de filtro de búsqueda | Escape de DN |
| Java | OWASP ESAPI encodeForLDAP() | OWASP ESAPI encodeForDN() |
| .NET | Encoder.LdapFilterEncode() | Encoder.LdapDistinguishedNameEncode() |
| Perl | Net::LDAP::Util::escape_filter_value() | Manual según RFC 2253 |
- Implemente validación por lista de permitidos. Valide la entrada contra patrones esperados antes de cualquier operación LDAP. Rechace entradas que contengan metacaracteres no esperados en el campo. Normalice la entrada (canalización Unicode) antes de la validación según la hoja de referencia OWASP.
Endurecimiento de infraestructura
- Deshabilite el bind anónimo y no autenticado. Esta sola acción elimina la causa raíz detrás de múltiples vulnerabilidades críticas.
- Utilice LDAPS (puerto 636). Deshabilite LDAP en texto claro (puerto 389) según NIST SP 1800-16.
- Aplique ACLs de mínimo privilegio a las cuentas de servicio de bind LDAP. Restringirlas solo a las operaciones y subárboles de directorio requeridos.
- Segmente la infraestructura LDAP del acceso general a la red según NIST SP 1800-18B.
Estos controles reducen la superficie de ataque disponible para un atacante que accede a su infraestructura LDAP.
Integración en la canalización CI/CD
Integre análisis estático (SAST) y análisis dinámico (DAST) en su canal de desarrollo. El OWASP Top 10 recomienda incluir herramientas SAST, DAST e IAST para identificar fallos de inyección antes del despliegue en producción. El modo de análisis de taint de Semgrep puede rastrear la entrada no confiable desde fuentes hasta sumideros sin saneamiento usando reglas personalizadas dirigidas a la construcción de consultas LDAP.
Estas medidas de prevención funcionan mejor cuando se respaldan con las herramientas adecuadas.
Herramientas para detección y prevención
La defensa efectiva contra la inyección LDAP requiere una combinación de herramientas de escaneo, monitoreo y protección en tiempo de ejecución.
- OWASP ZAP proporciona escaneo activo para inyección LDAP mediante la Alerta ZAP 40015 (CWE-90, WASC-29). Instale a través de las reglas de escaneo Alpha del Marketplace de ZAP y configure el targeting tecnológico para incluir Protocolo / LDAP en aplicaciones con integración LDAP.
- OWASP ModSecurity CRS ofrece protección a nivel de WAF mediante la Regla CRS 921200, que se ejecuta en Paranoia Level 1 por defecto. La regla inspecciona cookies, argumentos y cargas XML en busca de firmas de manipulación de filtros LDAP. Las cargas de prueba de regresión CRS de CRS Issue 276 proporcionan una lista de palabras de fuzzing lista para validación WAF.
- Semgrep admite análisis estático de taint mediante reglas mode: taint que rastrean datos no confiables desde fuentes de entrada hasta sumideros de consulta LDAP, señalando rutas de inyección antes de que el código llegue a producción.
- Plataformas SIEM con reglas de identificación personalizadas pueden monitorear los IDs de evento de Windows 4662 y 1644, correlacionar patrones anómalos de consulta LDAP y alertar sobre indicadores de comportamiento como enumeración secuencial de atributos o consultas masivas desde hosts no privilegiados.
Estas herramientas abordan capas individuales del problema. Un enfoque de plataforma las integra.
Reduzca el riesgo de identidad en toda su organización
Detecte y responda a los ataques en tiempo real con soluciones integrales para Active Directory y Entra ID.
DemostraciónVulnerabilidades relacionadas
Varias clases de vulnerabilidad comparten este patrón con la inyección LDAP:
- Inyección SQL (CWE-89): El análogo más cercano. Ambas explotan entrada no saneada en lenguajes de consulta, y la elusión de autenticación es posible mediante técnicas similares. La sintaxis y los sistemas objetivo difieren significativamente.
- Inyección de comandos del SO (CWE-78): Comparte el mismo Software Fault Pattern (SFP24, "Entrada contaminada a comando") con CWE-90 según MITRE. Apunta al sistema operativo anfitrión en lugar de servicios de directorio.
- Inyección XPath (CWE-643): La prueba LDAP de OWASP agrupa explícitamente la inyección XPath junto con la inyección LDAP como técnicas análogas de elusión de autenticación dirigidas a almacenes de datos basados en XML.
- Neutralización incorrecta de elementos especiales (CWE-77): La debilidad principal de CWE-90 en la jerarquía de MITRE. Todos los tipos de inyección descienden de este fallo generalizado de neutralizar caracteres significativos para el intérprete.
- Codificación o escape incorrecto de la salida (CWE-116): Documenta la cadena directa desde el fallo de escape hasta la inyección. CVE-2021-41232 demuestra la cadena CWE-116 → CWE-90 donde un fallo de escape en una aplicación Go permitió directamente la inyección LDAP.
- Validación incorrecta de entrada (CWE-20): La causa raíz cuando las aplicaciones no validan el formato de entrada antes de construir consultas LDAP.
Revisar estos tipos de debilidades relacionadas le ayuda a aplicar los mismos principios defensivos en toda su base de código, no solo en rutas de código específicas de LDAP.
CVEs relacionados
| ID CVE | Descripción | Severidad | Producto afectado | Año |
| La inyección LDAP en SuiteCRM permite a atacantes no autenticados manipular filtros de búsqueda, habilitando elusión de autenticación o divulgación de información | Crítica (9.8) | SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2 | 2026 | |
| WeKan incorpora nombres de usuario no saneados en filtros de búsqueda LDAP y valores DN, permitiendo a atacantes remotos no autenticados manipular consultas LDAP durante la autenticación | Crítica (9.8) | WeKan Project WeKan <8.19 | 2026 | |
| Parse Server interpola authData.id proporcionado por el usuario directamente en Distinguished Names LDAP y filtros de búsqueda de grupos, habilitando escalada de privilegios | Alta (8.8) | Parse Platform parse-server <8.6.26 | 2026 | |
| La inyección LDAP en WatchGuard Fireware OS permite a atacantes remotos no autenticados recuperar información sensible de un servidor LDAP conectado | Alta (7.0) | WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15 | 2026 | |
| Kanboard sustituye la entrada de usuario no saneada directamente en filtros de búsqueda LDAP, permitiendo a atacantes no autenticados enumerar usuarios LDAP y descubrir atributos sensibles | Media (5.3) | Kanboard Kanboard ≤1.2.48 | 2026 | |
| El formulario de inicio de sesión habilitado para LDAP de Teedy permite inyección LDAP no autenticada a través del campo de nombre de usuario, permitiendo creación arbitraria de cuentas y password spraying | Crítica (9.8) | Sismics Teedy 1.9–1.12 | 2025 | |
| La inyección LDAP en Apache HertzBeat permite a un atacante autenticado crear comandos que resultan en ejecución arbitraria de scripts | Alta (8.8) | Apache Software Foundation Apache HertzBeat ≤1.7.2 | 2025 | |
| La inyección de caracteres especiales LDAP en el campo de nombre de usuario de pgAdmin 4 hace que el servidor y cliente LDAP procesen datos excesivos, resultando en denegación de servicio | Alta (7.5) | PostgreSQL Global Development Group pgAdmin 4 <9.10 | 2025 | |
| El formulario de autenticación LDAP de GLPI puede ser usado para realizar inyección LDAP por atacantes no autenticados, corregido en la versión 10.0.12 | Alta (8.1) | GLPI Project GLPI 0.70–<10.0.12 | 2024 | |
| Usuarios privilegiados pueden inyectar cadenas de filtro LDAP en el proveedor opcional de contactos LDAP de OX App Suite, accediendo a contenido de directorio fuera de la jerarquía prevista | Alta (~8.0) | Open-Xchange OX App Suite <7.10.6 | 2024 | |
| NVIDIA DGX A100 BMC contiene una vulnerabilidad de inyección de usuario LDAP explotable por atacantes no autenticados en red adyacente, lo que lleva a divulgación de información | Media (~6.5) | NVIDIA DGX A100 BMC | 2024 | |
| La consulta de inicio de sesión LDAP de Mastodon es insegura, permitiendo a atacantes autenticados filtrar atributos arbitrarios del directorio LDAP | Alta (7.7) | Mastodon Mastodon 2.5.0–4.1.1 | 2023 | |
| Un nombre de usuario manipulado elude la autenticación LDAP en Apache Derby, permitiendo potencialmente agotamiento de disco, ejecución de malware y acceso no autorizado a la base de datos | Crítica (9.8) | Apache Software Foundation Apache Derby ≤10.16.1.1 | 2022 | |
| libsss_certmap de SSSD no sanea los datos de certificados usados en filtros LDAP, permitiendo a un atacante autenticado inyectar elementos de consulta LDAP y obtener acceso no autorizado | Alta (8.8) | Red Hat / SSSD Project SSSD | 2022 | |
| Apache ManifoldCF pasa nombres de usuario y cadenas de dominio a consultas de búsqueda LDAP sin validación en sus conectores de autoridad ActiveDirectory | Media (5.3) | Apache Software Foundation Apache ManifoldCF 0–2.23 | 2022 | |
| Thunderdome Planning Poker no escapa los nombres de usuario antes de las consultas LDAP cuando la autenticación LDAP está habilitada, permitiendo inyección LDAP no autenticada | Crítica (9.8) | Thunderdome Planning Poker <1.16.3 | 2021 | |
| La función ldapRegistry-3.0 de IBM Open Liberty contiene una vulnerabilidad de inyección LDAP | Alta (7.5) | IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1) | 2021 | |
| ForgeRock OpenAM permite inyección LDAP vía el protocolo Webfinger, habilitando la recuperación carácter por carácter de hashes de contraseñas o tokens de sesión por atacantes no autenticados | Alta (est.) | ForgeRock OpenAM <13.5.1 | 2021 |
Conclusión
La inyección LDAP da a los atacantes una forma de convertir entrada no confiable en control sobre los sistemas de directorio de los que depende su entorno para autenticación y acceso. Para usted, eso significa que el riesgo rara vez se limita a una consulta o una aplicación.
Si construye consultas de forma segura, escapa valores en el contexto correcto, restringe permisos de bind y monitorea de cerca la actividad LDAP, reduce tanto la exposición como el margen de maniobra de los atacantes.
Preguntas frecuentes
LDAP injection es una falla en el manejo de entradas en software que construye consultas LDAP a partir de datos no confiables. Un atacante puede cambiar cómo el directorio interpreta una consulta, convirtiendo una verificación de inicio de sesión en una condición siempre verdadera, ampliando una búsqueda limitada a una enumeración completa del directorio o abusando de las operaciones de agregar y modificar dentro del árbol LDAP.
Sí. LDAP injection se incluye dentro de la categoría más amplia de Inyección de OWASP en lugar de figurar como una entrada independiente en el Top 10. En la práctica, esto significa que debe revisar el código respaldado por LDAP con el mismo rigor que aplica a SQL injection, ya que ambas fallas provienen de la entrada no confiable que llega a un intérprete.
Sí. Si su formulario de inicio de sesión expuesto a la web, página de búsqueda, portal o interfaz de administración pasa la entrada del usuario a un backend LDAP, un atacante puede iniciar la explotación a través de la red.
En muchos casos, no necesitan credenciales válidas para comenzar a buscar manipulación de filtros.
Las aplicaciones de mayor riesgo son aquellas que utilizan LDAP para decisiones de identidad: portales de inicio de sesión y sistemas SSO, herramientas de restablecimiento de contraseñas y búsqueda en directorios, gateways VPN y portales de acceso remoto, y aplicaciones empresariales heredadas que construyen consultas LDAP mediante concatenación de cadenas.
Los atacantes suelen comenzar con pruebas simples. Envían metacaracteres LDAP como (, |, & y *, luego observan cambios en las respuestas, errores o recuentos de resultados inusuales.
Una vez que infieren la estructura del filtro, pasan a cargas útiles de extracción por comodín, basadas en OR o ciegas.
Los primeros indicios suelen incluir metacaracteres en los campos de autenticación o búsqueda, conjuntos de resultados LDAP inusualmente amplios, patrones )( o |( en los filtros, un inicio de sesión fallido seguido inmediatamente de éxito y consultas LDAP masivas desde un host sin privilegios.
Es grave porque LDAP suele controlar la autenticación y autorización más allá de una sola aplicación. Una inyección exitosa puede exponer datos del directorio, evadir controles de inicio de sesión o facilitar la movilidad lateral en todo el entorno.
Esa amplitud hace que el impacto empresarial sea mayor que muchas fallas solo de aplicación.
Sí, especialmente como paso inicial en una cadena de ataque de identidad más amplia. Un atacante puede pasar de evadir el inicio de sesión o enumerar el directorio a recolectar credenciales, crear cuentas, volcar NTDS.dit y mantener acceso persistente usando cuentas válidas.
La inyección suele ser el punto de entrada, no el objetivo final.
Las herramientas ayudan, pero no resuelven el problema por sí solas. Los escáneres y las reglas WAF pueden encontrar casos evidentes, mientras que la inyección ciega y el registro débil de LDAP siguen siendo más difíciles de detectar.
Si carece de visibilidad sobre el tráfico LDAP y el comportamiento de las consultas, puede pasar por alto la actividad incluso cuando la explotación ya está en curso.
Las industrias con dependencia centralizada de identidad presentan la mayor concentración de riesgo. El artículo destaca los sectores de salud, servicios financieros, gobierno, infraestructura crítica y plataformas de software.
Lo que las une es la dependencia de la autenticación respaldada por LDAP para usuarios, sistemas y flujos administrativos de alto valor.
