
Dahua CVE-2026-29116
Tipo de aviso: Divulgación de seguridad coordinada con el proveedor
ID CVE: CVE-2026-29116
Proveedor: Dahua Technology
Publicado: 2026-06-10T06:16:34 UTC
Última modificación: 2026-06-10T06:16:34 UTC
Fuente: Centro de confianza de Dahua Product Security Incident (PSI)
Se ha identificado una vulnerabilidad de denegación de servicio remota no autenticada de alta gravedad en múltiples líneas de productos de seguridad y vigilancia Dahua. Un atacante en la red —incluyendo internet pública cuando los dispositivos están expuestos— puede enviar un paquete de red especialmente diseñado a un dispositivo vulnerable. El procesamiento de ese paquete desencadena una excepción no controlada (consistente con una aserción alcanzable o una ruta de error fatal), provocando que el dispositivo se reinicie inesperadamente.
Debido a que no se requieren credenciales y la complejidad del ataque es baja, esta vulnerabilidad es sencilla de explotar a gran escala. La explotación repetida puede producir cortes prolongados en cámaras, grabadores, terminales de intercomunicación e infraestructura relacionada. Si bien la falla no compromete directamente la confidencialidad o integridad de los datos almacenados, el impacto en la disponibilidad está calificado como Alto, lo que arroja una puntuación base CVSS 4.0 de 8.7 (ALTA).
Las organizaciones que operen hardware Dahua IPC, SD, NVR, XVR, EVS, VTO, VTH, ASI o TPC con versiones de firmware anteriores al 26 de marzo de 2026 deben tratar el parcheo o el aislamiento de red como una prioridad.
Nota sobre el etiquetado del aviso: Algunos índices de terceros listan este CVE bajo un título de "Cross-Site Scripting". La descripción oficial, el vector CVSS (
VA:Hsin impacto en confidencialidad o integridad) y la clasificación CWE-617 son consistentes con un bloqueo/reinicio (DoS) desencadenado por red no autenticado, no con una condición XSS basada en navegador. Este documento sigue la descripción y los datos de puntuación del proveedor.
Dahua ha informado de una vulnerabilidad de seguridad que afecta a un subconjunto de productos de su cartera de vigilancia y control de acceso. La falla reside en el software que enfrenta la red y que maneja el tráfico entrante sin validar adecuadamente o manejar de forma segura entradas malformadas o adversas.
Comportamiento observado:
Lo que esta vulnerabilidad no es (según las métricas CVSS):
UI:N).PR:N).VC:N, VI:N).SC:N, SI:N, SA:N).El riesgo principal es la pérdida de disponibilidad — las cámaras dejan de transmitir, los grabadores dejan de grabar, los intercomunicadores se desconectan y los flujos de trabajo automatizados que dependen de esos dispositivos fallan.
El texto público del proveedor no revela la función o el endpoint de protocolo exacto. Basándose en el CWE publicado y el comportamiento, las categorías de causa raíz más probables son:
| Categoría | Explicación |
|---|---|
| Aserción alcanzable | Un assert() de depuración o integridad (o equivalente) permanece habilitado en el firmware de producción y puede ser activado por una entrada malformada. |
Cualquiera de los anteriores puede derivar en un reinicio completo del dispositivo si la falla ocurre en un demonio crítico, el supervisor principal de la aplicación o un componente adyacente al núcleo sin recuperación controlada.
Debido a que el vector de ataque es Red y no se requieren privilegios, cualquier servicio accesible que analice entradas de red proporcionadas por el atacante en firmware afectado puede estar implicado. En implementaciones Dahua, esto incluye comúnmente — pero no se limita a —:
Importante: El aviso del proveedor no nombra un solo puerto o URI. Los defensores deben asumir cualquier listener de red expuesto en firmware vulnerable podría ser relevante hasta que se parchee.
Desde la perspectiva del operador, ambos resultados parecen "la cámara se desconectó", pero difieren operativamente:
| Resultado | Efecto visible para el operador | Registro |
|---|---|---|
| Reinicio de proceso | Breve interrupción en la transmisión; el dispositivo puede permanecer parcialmente activo | Registros de caída de aplicación |
| Reinicio completo del sistema | Ventana de desconexión total; sesiones activas perdidas | Secuencia de arranque, watchdog, rastros de pánico del núcleo |
La descripción del proveedor cita explícitamente reinicio inesperado del sistema, lo que implica un evento de disponibilidad a nivel de dispositivo en lugar de un reciclaje de un solo demonio no crítico.
Un reinicio de un solo disparo es disruptivo. Un desencadenante remoto repetible es peor:
| # | Proveedor | Familias de productos | Guía de versión / compilación |
|---|---|---|---|
| 1 | Dahua | IPC / SD / NVR / XVR / EVS / VTO / VTH / ASI / TPC | Afectados: versiones de firmware anteriores al 26 de marzo de 2026 (limitado a ciertos modelos dentro de cada familia) |
Totales: 1 proveedor afectado · 1 agrupación de productos afectada (multifamilia)
Dahua afirma que solo ciertos modelos dentro de las familias listadas están afectados. El aviso no es una afirmación universal de "todos los dispositivos Dahua". Los operadores deben cotejar:
| Puntuación | Versión | Gravedad | Vector |
|---|---|---|---|
| 8.7 | 4.0 | ALTA | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N |
Una puntuación de 8.7 en CVSS 4.0 coloca este problema en el rango ALTA. La puntuación está impulsada casi en su totalidad por un compromiso de disponibilidad remota no autenticado con baja complejidad. Los defensores no deben reducir el riesgo solo porque la confidencialidad y la integridad sean Ninguna — para los sistemas de seguridad física, la disponibilidad suele ser la propiedad crítica para el negocio.
Resumen visual de las posiciones de los selectores CVSS 4.0 publicados:
Attack Vector: [Network] Adjacent Local Physical Attack Complexity: [Low] High Attack Requirements: [None] Present Privileges Required: [None] Low High User Interaction: [None] Passive Active
### Impacto en el sistema vulnerable```
Vuln Confidentiality: [None] Low High
Vuln Integrity: [None] Low High
Vuln Availability: [High] Low None
Subseq Confidentiality: [None] Low High Subseq Integrity: [None] Low High Subseq Availability: [None] Low High
---
## Clasificación CWE
| # | ID CWE | Nombre | Relevancia |
|---|---|---|---|
| 1 | **CWE-617** | [Afirmación Alcanzable](https://cwe.mitre.org/data/definitions/617.html) | El código de producción expone una afirmación o comprobación fatal accesible por entrada no confiable, terminando el proceso o sistema |
### Por qué CWE-617 encaja
CWE-617 describe situaciones donde los desarrolladores dependen de afirmaciones para condiciones que **atacantes externos pueden forzar**. A diferencia del manejo de errores elegante (códigos de retorno, respuestas sanitizadas), una afirmación alcanzable a menudo termina en **terminación abrupta** — alineándose con el comportamiento de **bloqueo o reinicio** descrito por el proveedor.
---
## Prerrequisitos del Ataque
| Prerrequisito | ¿Requerido? | Notas |
|---|---|---|
| Credenciales válidas del dispositivo | **No** | Ataque no autenticado |
| Interacción del usuario víctima | **No** | Disparo de red completamente remoto |
| Compromiso previo de otro sistema | **No** | Explotación independiente |
| Accesibilidad de red al dispositivo | **Sí** | El vector de ataque es Red |
| Conocimiento del modelo del dispositivo | Útil, no estrictamente requerido | El paquete manipulado puede ser específico de la familia |
| Exposición a Internet | No requerido, pero aumenta el riesgo | La redirección de puertos WAN y la exposición de relevo en la nube son comunes en la práctica |
**Explotable Remotamente:** **Sí**
---
## Escenarios de Explotación
### Escenario 1 — Cámara Expuesta a Internet
Una IPC fija tiene redirección de puertos para visualización remota. Un atacante escanea el host, envía el paquete manipulado a un puerto de servicio abierto y fuerza un reinicio. La cámara se desconecta durante un incidente de seguridad activo, creando una brecha de grabación.
### Escenario 2 — VLAN CCTV Plana
Un atacante obtiene un punto de apoyo en un portátil corporativo (phishing, dispositivo de contratista, etc.) y apunta a cada host Dahua en la VLAN de vigilancia. Disparos secuenciales producen un evento de "todas las cámaras fuera de línea" en todo el sitio sin autenticarse nunca en el software VMS.
### Escenario 3 — Disrupción de Intercomunicador (VTO/VTH)
Una tienda minorista usa estaciones de puerta Dahua. Un atacante cerca de la red (o a través de WAN expuesta) reinicia repetidamente la estación exterior durante horas pico. La validación de entrada y la liberación remota de puerta fallan, causando un cierre operativo o procedimientos de derivación manual.
### Escenario 4 — Degradación Encadenada de Seguridad Física
El reinicio del NVR durante una intrusión activa retrasa la verificación de alarmas y el seguimiento PTZ. Si bien no es un CVE directo de "integridad" según CVSS, el **resultado de seguridad física** puede ser grave.
### Escenario 5 — Acoso Sostenido / Degradación del Servicio
La reproducción automatizada del disparo cada N minutos impide un tiempo de actividad estable incluso si el dispositivo se recupera rápidamente cada vez — un ataque de **bajo esfuerzo, alta disrupción** adecuado para abuso a escala de botnet contra huellas de firmware conocidas.
---
## Evaluación de Impacto
### Impacto Técnico
| Dominio | Calificación | Detalle |
|---|---|---|
| Confidencialidad | Ninguno (directo) | No se ha demostrado exfiltración de datos solo a través de esta falla |
| Integridad | Ninguno (directo) | No se ha demostrado manipulación de configuración o metraje solo a través de esta falla |
| Disponibilidad | **Alta** | Corte a nivel de reinicio; repetible |
### Impacto Empresarial (Contextual)
| Sector | Consecuencia Potencial |
|---|---|
| Minorista / Banca | Pérdida de video forense durante eventos de merma o fraude |
| Infraestructura crítica | Brechas en la verificación visual de alarmas |
| Residencial / PYME | Puntos ciegos de monitoreo del hogar durante allanamientos |
| Ciudad inteligente | Caída de cámaras de tráfico o seguridad pública |
| Integraciones de control de acceso | Puertas e intercomunicadores no disponibles en horas pico |
### Consideraciones a Nivel de Flota
Las organizaciones con **cientos o miles** de puntos finales Dahua deberían modelar:
- Tiempo medio de recuperación por reinicio
- Ruido de monitoreo central durante apagones masivos
- Incumplimientos de SLA con clientes de servicios gestionados
- Implicaciones de seguro o cumplimiento para la continuidad de grabación
---
## Detección e Indicadores de Compromiso
Debido a que el proveedor no ha publicado capturas de paquetes o firmas específicas de CVE, la detección debe centrarse en **indicadores de comportamiento**:
### Indicadores de Host / Dispositivo
- Reinicios inesperados sin actualizaciones iniciadas por administrador o eventos de energía
- Banderas de motivo de arranque que hacen referencia a pánico del kernel, reinicio por watchdog o reinicio anormal
- Registros de aplicación que muestran fallos de afirmación o errores fatales inmediatamente antes del tiempo de inactividad
- Tiempos de actividad cortos correlacionados con ráfagas de tráfico de red anómalo
### Indicadores de Red
- Ráfagas de fuente única o distribuidas de paquetes anómalos que preceden a eventos de dispositivo fuera de línea
- Nueva actividad de escaneo en puertos de servicio asociados a Dahua desde subredes no confiables
- Correlación entre patrones externos SYN/UDP/HTTP y marcas de tiempo de reinicio de syslog de cámara/NVR
### Correlaciones Operacionales
- Múltiples dispositivos fuera de línea simultáneamente sin falla del conmutador PoE
- Eventos fuera de línea **no** acompañados por errores de interfaz del conmutador (sugiriendo un bloqueo a nivel de punto final)
- Cortes recurrentes a intervalos fijos (posible ataque de reproducción automatizado)
### Registro Recomendado
- Centralizar **syslog** de cámaras, NVR e intercomunicadores
- Retener flujos de **firewall / borde** para segmentos que contengan equipos de vigilancia
- Alertar sobre eventos de **desconexión masiva de dispositivos** desde VMS dentro de ventanas de tiempo cortas
---
## Mitigación y Corrección
### Corrección Primaria — Actualización de Firmware
1. Inventariar todos los dispositivos Dahua con modelo, número de serie y **fecha de compilación del firmware**.
2. Identificar unidades con compilaciones **anteriores al 26 de marzo de 2026**.
3. Descargar el firmware aprobado por el proveedor desde el [Centro de Confianza PSI de Dahua](https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi) o canales de distribución autorizados.
4. Programar actualizaciones en una ventana de mantenimiento; validar la función de grabación e intercomunicador después del parche.
5. Volver a probar los servicios expuestos externamente solo después de la confirmación de la compilación corregida.
### Controles Compensatorios (Hasta que se Parchee)
| Control | Objetivo |
|---|---|
| **Segmentación de red** | Colocar cámaras/NVR en VLANs dedicadas con ACLs de denegación por defecto |
| **Eliminar redirección de puertos** | Eliminar la exposición directa a WAN; usar VPN o acceso de confianza cero en su lugar |
| **Restringir IPs de origen** | Permitir solo VMS, hosts de salto y subredes de operadores para alcanzar puertos de gestión del dispositivo |
| **Deshabilitar servicios no utilizados** | Reducir la superficie de ataque de protocolos (deshabilitar HTTP/ONVIF/PPPoE/etc. innecesarios) |
| **Filtrado de salida** | Limitar el comportamiento de relevo inesperado donde la política lo permita |
| **Repuestos físicos / conmutación por error** | Para tomas críticas, mantener cobertura superpuesta |
### Gestión de Cambios Empresarial
- Documentar versiones de firmware en CMDB
- Vincular el estado del parche a los flujos de trabajo de adquisición y RMA
- Incluir monitoreo de PSI de Dahua en la cadencia de revisión de riesgos del proveedor
---
## Soluciones Alternativas
No se conoce ninguna **solución alternativa solo de configuración** documentada por el proveedor que elimine completamente la vulnerabilidad sin actualizar a una compilación corregida. Hasta que se aplique el firmware, el **contenimiento a nivel de red** es la solución alternativa práctica:
1. Bloquear redes no confiables para que no alcancen puertos de gestión del dispositivo y puertos de servicio propietarios.
2. Monitorear patrones de reinicio repetidos y aislar fuentes ofensivas en el firewall de borde.
3. Donde esté disponible, colocar dispositivos detrás de concentradores VPN autenticados en lugar de exposición directa.
---
## Respuesta del Proveedor
Dahua publicó este problema a través de su programa **Product Security Incident (PSI)**. Recursos oficiales:
- **Trust Center / PSI:** https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi
Los operadores deben tratar el boletín del proveedor como la fuente autorizada para:
- Listas de afectados específicas por modelo
- Enlaces de descarga de firmware corregido
- Recomendaciones adicionales de endurecimiento
---
## Referencias
| Recurso | URL |
|---|---|
| Centro de Confianza PSI de Dahua | https://www.dahuasecurity.com/about-dahua/trust-center/dahua-psi |
| Entrada NVD | https://nvd.nist.gov/vuln/detail/CVE-2026-29116 |
| Registro CVE | https://www.cve.org/CVERecord?id=CVE-2026-29116 |
| Definición CWE-617 | https://cwe.mitre.org/data/definitions/617.html |
| Especificación CVSS 4.0 | https://www.first.org/cvss/v4.0/specification-document |
---
## Descargo de Responsabilidad
Este documento es un **aviso de seguridad informativo** compilado a partir de metadatos CVE disponibles públicamente y declaraciones del proveedor. Está destinado a ayudar a defensores, integradores e investigadores a comprender el riesgo de **CVE-2026-29116** y priorizar la corrección.
- Este README **no** proporciona código de explotación, plantillas de paquetes manipulados o instrucciones de ataque paso a paso.
- Las secciones de análisis técnico marcadas como *inferido* son interpretaciones razonables de datos públicos, no divulgación de causa raíz confirmada por el proveedor.
- La determinación del modelo afectado **debe** verificarse contra el boletín PSI oficial de Dahua y la fecha de compilación del firmware de su dispositivo.
- Los autores no se hacen responsables por acciones tomadas basadas en este documento. Parchee, pruebe e implemente de acuerdo con las políticas de gestión de cambios de su organización.
**Uso responsable:** Reporte hallazgos adicionales a través de canales de divulgación coordinados (PSI del proveedor, CERT nacional o programas de recompensas por errores establecidos donde corresponda).
---
## Historial de Revisión del Documento
| Versión | Fecha | Cambios |
|---|---|---|
| 1.0 | 2026-07-11 | README de aviso integral inicial basado en datos de publicación de CVE-2026-29116 |
---
<p align="center">
<sub>CVE-2026-29116 · Dahua Technology · CVSS 4.0 8.7 ALTA · CWE-617</sub>
</p>
| Campo | Valor |
|---|
| ID CVE | CVE-2026-29116 |
| Proveedor | Dahua Technology |
| Tipo de vulnerabilidad | Denegación de servicio (reinicio inesperado) |
| Vector de ataque | Red |
| Autenticación requerida | No |
| Interacción del usuario requerida | No |
| Privilegios requeridos | Ninguno |
| Versión de CVSS | 4.0 |
| Puntuación base CVSS | 8.7 — ALTA |
| Vector CVSS | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N |
| CWE | CWE-617 (Aserción alcanzable) |
| Remotamente explotable | Sí |
| Fecha de publicación | 2026-06-10 |
| Disponibilidad de parche | Versiones de firmware a partir del 26 de marzo de 2026 (según la guía del proveedor) |
| Fecha | Evento |
|---|
| ≤ 2026-03-26 | Versiones de firmware vulnerables en distribución activa |
| 2026-03-26 | Corte de la corrección del proveedor: las versiones producidas en esta fecha o después están fuera del rango afectado (según el aviso) |
| 2026-06-10T06:16:34 UTC | Publicación de CVE-2026-29116 |
| 2026-06-10T06:16:34 UTC | Última modificación del registro de NVD |
| 2026-06-10 | Publicación del aviso del Centro de confianza PSI de Dahua |
| En curso | Los operadores deben inventariar, parchear y segmentar los activos afectados |
| Excepción fatal no capturada | El analizador o la máquina de estados de sesión lanza/colapsa ante valores de campo, longitudes o estados de protocolo inesperados. |
| Manejo inadecuado de recursos o límites | El paquete diseñado provoca un acceso fuera de límites o una operación de memoria inválida detectada en tiempo de ejecución, terminando el proceso o la ruta del núcleo. |
| Familia | Rol típico | Ejemplo de impacto operativo |
|---|
| IPC | Cámaras IP | Pérdida de visión en vivo, brechas de grabación, caída de eventos inteligentes |
| SD | Domos de velocidad / PTZ | Pérdida de seguimiento, fallos de presets, interrupción de patrullaje |
| NVR | Grabadores de video en red | Caída de ingesta multicanal si el equipo se reinicia |
| XVR | DVR/NVR híbridos | Interrupción de grabación de canales locales + IP |
| EVS | Almacenamiento de video empresarial | Interrupción de ingesta de archivo a gran escala |
| VTO | Estaciones exteriores de videoportero | Las llamadas de entrada fallan; liberación de puerta no disponible |
| VTH | Monitores interiores de videoportero | Pérdida de comunicación a nivel de unidad |
| ASI | Interfaces de acceso/seguridad | Los flujos de trabajo integrados de puerta y alarma se detienen |
| TPC | Plataformas térmicas / especiales | Puntos ciegos de monitoreo de seguridad |
| Métrica | Valor | Significado para este CVE |
|---|
| AV (Vector de ataque) | Red (N) | La explotación ocurre a través de una ruta de red; los atacantes remotos califican cuando los dispositivos son accesibles |
| AC (Complejidad del ataque) | Baja (L) | No se requieren condiciones especiales de sincronización, carrera o entorno |
| AT (Requisitos de ataque) | Ninguno (N) | No hay condiciones previas específicas de implementación más allá de la accesibilidad de red |
| PR (Privilegios requeridos) | Ninguno (N) | Atacante no autenticado |
| UI (Interacción del usuario) | Ninguna (N) | No se necesita acción del usuario víctima (por ejemplo, abrir un enlace) |
| VC (Confidencialidad del sistema vulnerable) | Ninguna (N) | No se demuestra pérdida directa de confidencialidad en el dispositivo |
| VI (Integridad del sistema vulnerable) | Ninguna (N) | No se demuestra pérdida directa de integridad en el dispositivo |
| VA (Disponibilidad del sistema vulnerable) | Alta (H) | El dispositivo deja de estar disponible; impacto de tipo reinicio |
| SC (Confidencialidad subsiguiente) | Ninguna (N) | Sin impacto puntuado en confidencialidad descendente |
| SI (Integridad subsiguiente) | Ninguna (N) | Sin impacto puntuado en integridad descendente |
| SA (Disponibilidad subsiguiente) | Ninguna (N) | Sin impacto puntuado en disponibilidad descendente |