CVE-2024-51482, la inyección SQL de ZoneMinder que sigue siendo importante en 2026

ZoneMinder existe desde hace tanto tiempo que muchos equipos lo tratan como una infraestructura más que como una aplicación web viva. Esa es exactamente la razón por la que CVE-2024-51482 merece más atención de la que se le prestó cuando apareció por primera vez. No se trata simplemente de otro fallo de base de datos en un panel de administración ordinario. Se encuentra dentro de una plataforma de gestión de videovigilancia que a menudo acaba gestionando flujos de trabajo operativos, registros de eventos, cuentas de usuario y revisión de incidentes. El registro oficial describe una inyección SQL basada en booleanos en web/ajax/event.php que afecta a la rama 1.37 hasta la 1.37.64, y la versión corregida autorizada es la 1.37.65. El aviso de GitHub le asigna una gravedad crítica, y el registro NVD conserva un importante historial de correcciones que muestra que la primera redacción pública apuntaba a 1.37.64 como la corrección antes de que se actualizara a 1.37.65. Esta corrección por sí sola hace que merezca la pena revisar esta CVE con cuidado. Esta corrección por sí sola hace que merezca la pena revisar esta CVE detenidamente. (NVD)

Lo que hace que esta vulnerabilidad sea especialmente práctica es lo fácil que es para los defensores ocupados colapsar el matiz de la versión en una falsa sensación de seguridad. Muchas organizaciones recuerdan que "ya aplicaron un parche a ZoneMinder el año pasado", o que cambiaron a una "versión 1.37 parcheada", y se detienen ahí. CVE-2024-51482 es el tipo de fallo que castiga ese atajo. Si su inventario interno de activos dice "ZoneMinder 1.37" sin preservar los detalles a nivel de parche, puede que no sea capaz de responder a la pregunta más importante: ¿está usted en una versión que es en realidad más allá de 1.37.64? La diferencia entre 1.37.61, 1.37.64 y 1.37.65 no es el papeleo. Es la diferencia entre seguir teniendo una inyección SQL crítica y realmente cerrarla. (NVD)

La respuesta limpia primero

Antes de entrar en el código, el historial de ramas y las implicaciones defensivas, es útil reducir el problema a lo que los equipos de seguridad realmente necesitan durante el triaje.

Cada línea de esa tabla procede directamente de los registros oficiales, no de una versión de terceros. El aviso de GitHub nombra el fallo, las versiones afectadas y la versión parcheada. La entrada del NVD repite la misma descripción y, lo que es más importante, muestra que la versión corregida se corrigió después de la publicación inicial. Este detalle es importante porque los resúmenes copiados, las notas de los escáneres y los comentarios internos de los tickets suelen durar más que la fuente corregida. (GitHub)

Si sólo se lleva una lección operativa de este artículo, que sea ésta: tratar 1.37.65 como el límite de parche significativo para esta CVE, no 1.37.64. El historial de cambios del NVD muestra explícitamente la corrección de "corregido en 1.37.64" a "corregido en 1.37.65". Esto no es especulación o interpretación. Está preservado en el propio registro. (NVD)

En qué consiste realmente el fallo

El aviso de seguridad oficial de GitHub describe el flujo vulnerable en términos inusualmente claros. En el quitar etiqueta caja interior web/ajax/event.phpZoneMinder aceptado $_REQUEST['tid']lo asignó directamente a $tagIdy, a continuación, creó una consulta SQL concatenando $tagId en la declaración:

$tagId = $_REQUEST['tid'];
$sql = "SELECT * FROM Events_Tags WHERE TagId = $tagId";
$rowCount = dbNumRows($sql);

Ese es casi el patrón de libro de texto sobre el que advierte OWASP: construcción dinámica de consultas con entrada no fiable. OWASP's SQL Injection Prevention Cheat Sheet explica el problema en los términos más amplios posibles: los atacantes tienen éxito cuando una aplicación construye dinámicamente consultas utilizando datos suministrados por el usuario, especialmente cuando se trata de concatenación de cadenas en lugar de parametrización. CVE-2024-51482 no es exótico. Es un fallo de categoría clásico que aparece en un flujo de trabajo del plano de gestión que debería haber sido más difícil de romper. (GitHub)

El parche es informativo porque no se limita a modificar el formato. Cambia la forma en que la aplicación trata el parámetro de solicitud. En el commit de fijación, $_REQUEST['tid'] se pasa a través de validCardinaly la subsiguiente ejecución SQL cambia de interpolación de cadenas sin procesar a consultas parametrizadas. La ruta de código vulnerable que realizaba SELECT * FROM Events_Tags WHERE TagId = $tagId se convierte en dbNumRows('SELECT * FROM Events_Tags WHERE TagId=?', [ $tagId ])y la ruta de eliminación se actualiza de forma similar para utilizar el valor desinfectado en una llamada parametrizada. En otras palabras, la solución es exactamente lo que los defensores esperarían después de leer OWASP: validar la entrada, luego parametrizar la consulta. (GitHub)

Ese parche es importante por otra razón. Nos dice que los mantenedores del proyecto y el informador de vulnerabilidades no estaban tratando con una vaga condición de "tal vez inyectable". Sabían qué parámetro era arriesgado, qué ruta de código era insegura y cómo debía ser el patrón de codificación seguro. Eso da a los defensores una base sólida para validar que su compilación local incluye realmente los cambios correctos en lugar de asumir que la etiqueta de un paquete cuenta toda la historia. (GitHub)

Por qué una inyección SQL basada en booleanos sigue teniendo peso real

Algunos equipos de seguridad todavía degradan mentalmente la inyección SQL si no ven inmediatamente "RCE no autenticado" o "wormable" en el aviso. Ese instinto es peligroso en este caso. La propia guía de inyección SQL de OWASP es contundente sobre las consecuencias: la confidencialidad, autenticación, autorización e integridad pueden verse afectadas cuando una entrada no fiable llega a la ejecución de la base de datos. Una inyección SQL exitosa no necesita convertirse en ejecución de código para ser operativamente grave. La lectura de registros sensibles, la alteración de pruebas, la eliminación de asociaciones o la manipulación del estado de la aplicación bastan para crear un incidente perjudicial. (Fundación OWASP)

En el caso de ZoneMinder, ese riesgo recae en una plataforma que a menudo actúa como superficie de control para eventos de vigilancia y flujos de trabajo administrativos. Incluso el nombre de la ruta de código vulnerable, quitar etiqueta, le indica que no se trata sólo de una consulta de juguete contra datos desechables. Las etiquetas, las vistas de eventos y los metadatos de eventos forman parte del modo en que los operadores clasifican, revisan y repasan lo sucedido. Esto significa que los problemas de integridad son tan importantes como los de confidencialidad. Si el despliegue circundante también almacena datos de usuario, credenciales o etiquetas operacionalmente significativas en la misma capa de base de datos, entonces el impacto se expande más allá de una estrecha narrativa de fuga de datos. (GitHub)

Los proveedores defensivos parecen estar de acuerdo en que el fallo merece un tratamiento de primera clase. FortiGuard publica una entrada de firma IPS específicamente para esta vulnerabilidad, nombrando a ZoneMinder anterior a 1.37.65 como afectado y describiendo probables resultados como añadir, ver, borrar o modificar datos. Check Point también tiene una advertencia de protección para "ZoneMinder SQL Injection", de nuevo mencionando las versiones 1.37 a 1.37.64 y afirmando que la explotación podría permitir la ejecución arbitraria de SQL en el sistema afectado. Estas entradas no demuestran una explotación masiva por sí solas, y los defensores no deberían exagerarlo. Pero sí demuestran que la vulnerabilidad ha madurado más allá de un aviso estático y se ha convertido en controles defensivos específicos. (Laboratorios FortiGuard)

El límite de la versión es donde muchos equipos se queman

El dato más útil de todo el historial del CVE no es la puntuación. Es el historial de correcciones.

NVD muestra que cuando el CVE se añadió por primera vez el 31 de octubre de 2024, la descripción decía que el problema estaba solucionado en 1.37.64. El 5 de noviembre de 2024, GitHub modificó el registro de CVE para que la misma descripción diga ahora que se solucionó en 1.37.65. Esa corrección de una sola línea es la diferencia entre una historia de remediación completa y un cierre falso. (NVD)

Este es exactamente el tipo de cosas que causan una deriva operativa real. Un ingeniero copia el resumen inicial en un gestor de incidencias interno. Otra persona construye un memo de parche a partir de una fuente de escáner que almacenó en caché el texto inicial. Una tercera persona comprueba sólo la rama y asume que "ya estamos en la 1.37.64, así que estamos bien". Meses después, todo el mundo piensa que el problema se ha cerrado. El registro NVD dice lo contrario. (NVD)

Esta corrección también adquiere mayor importancia cuando se observan otras vulnerabilidades recientes de ZoneMinder en la misma rama. CVE-2024-43360, otro problema de inyección SQL, se corrige en 1.37.61. CVE-2024-43359, un fallo XSS en montagereviewtambién está solucionado en 1.37.61. Un equipo que actualizó a 1.37.61 después de esos avisos 2024 puede haber creído razonablemente que había solucionado los principales problemas del plano web para esa línea. CVE-2024-51482 rompe esa suposición, porque sigue presente en 1.37.64 y sólo se soluciona en 1.37.65. (NVD)

El mapa de la versión práctica tiene este aspecto:

Esta tabla no pretende sustituir a las directrices del proveedor. Pretende detener un modo de fallo familiar: pensar en términos de "una rama parcheada" en lugar de "la compilación exacta que cierra el problema exacto". En la gestión de vulnerabilidades, la precisión a nivel de parche es aburrida hasta que te salva de una mala suposición. CVE-2024-51482 es uno de esos casos. (NVD)

No se trata de un fallo aislado en una superficie por lo demás tranquila

El argumento más sólido para tomarse en serio CVE-2024-51482 no es sólo la puntuación CVSS o la etiqueta de inyección SQL. Es la historia más amplia de la misma superficie del producto.

En 2023, NVD documentó CVE-2023-26035 como un fallo de ejecución remota de código no autenticado en ZoneMinder causado por la falta de autorización en torno a la acción de instantánea. La descripción señala que no había comprobaciones de permisos en el flujo de instantáneas, y que TriggerOn finalmente alcanzó shell_exec con entrada controlada por el atacante. Este problema afectaba a las versiones anteriores a la 1.36.33 y 1.37.33 y tenía una puntuación CVSS v3 de 9,8 en NVD. Este no es el perfil de un producto cuyo plano de gestión debería exponerse casualmente o supervisarse a la ligera. (NVD)

También en 2023, CVE-2023-26038 afectó a web/ajax/modal.php y permitió que una ruta de archivo PHP arbitraria fuera pasada y cargada, lo que NVD describe como un problema de estilo de inclusión de archivo local. Eso significa que la superficie administrativa orientada a AJAX ya había mostrado debilidad en la lógica de manejo de archivos antes de que aterrizara la ola de inyecciones SQL de 2024. (NVD)

Después, 2024 trajo al menos dos problemas web más notables antes de CVE-2024-51482. CVE-2024-43360 es una vulnerabilidad de inyección SQL basada en el tiempo corregida en 1.36.34 y 1.37.61, y CVE-2024-43359 es un problema de XSS en montagereviewcorregido también en las versiones 1.36.34 y 1.37.61. Para cuando llegó CVE-2024-51482, los defensores ya tenían pruebas suficientes para dejar de tratar a ZoneMinder como "un simple software de cámara" y empezar a tratarlo como una aplicación web operativa privilegiada con un historial no trivial de defectos en la gestión de entradas. (NVD)

El patrón importa más que las etiquetas. Un XSS aislado en una vista de nicho es una cosa. Una serie de inyecciones SQL, XSS, inclusión de archivos locales y RCE sin autorización en versiones adyacentes cuenta una historia diferente: la superficie de ataque merece una revisión repetible. Esto no significa que ZoneMinder sea imprudente en comparación con cualquier otra plataforma web de código abierto. Significa que los defensores deberían dejar de darle el pase suave que a menudo se concede a las "herramientas de instalación". Vive demasiado cerca de las operaciones, las pruebas y la supervisión física para esa mentalidad. (NVD)

El código de explotación público cambia el debate sobre los riesgos prácticos

El aviso oficial de GitHub incluye un concepto de PoC e incluso referencias al uso de sqlmap contra el flujo de peticiones vulnerable. Más recientemente, varios repositorios públicos de GitHub y páginas de seguimiento de CVE han sacado a la luz herramientas de prueba de concepto y escritos de explotación relacionados con CVE-2024-51482, incluidos proyectos publicados en marzo de 2026 que se centran en pruebas de vulnerabilidad, descubrimiento de bases de datos y volcado de tablas contra compilaciones vulnerables de ZoneMinder. Esto no significa automáticamente un compromiso generalizado en el mundo real. Significa que la barrera del conocimiento ha caído, y que los defensores deberían tratar la "explotabilidad pública" como una preocupación práctica más que como una posibilidad abstracta. (GitHub)

La respuesta adecuada a este hecho no es el pánico ni el lenguaje teatral. Es priorizar. Una vez que una vulnerabilidad es fácil de entender y de reproducir, el retraso del parche se hace más difícil de defender. Esto es especialmente cierto para el software que los administradores a menudo exponen por conveniencia, publican detrás de sólo controles básicos, o dejan correr con paquetes obsoletos porque es operativamente molesto actualizar. (Laboratorios FortiGuard)

Lo que los defensores deben verificar ahora mismo

El primer paso es obvio y sigue siendo necesario: verificar la versión exacta en ejecución y pasar a 1.37.65 o posterior si se encuentra en la línea 1.37 afectada. No confíe en la memoria, las etiquetas de rama o las primeras copias de aviso. Compare el paquete instalado o la revisión fuente con el registro NVD corregido y, si es necesario, inspeccione si el parche lógico del commit 9e7d318 está presente. (NVD)

El segundo paso es la disciplina de exposición. Un plano de gestión de vigilancia no debería estar disponible casualmente en Internet abierto. Esto no es sólo una recomendación de CVE-2024-51482; es lo que implica el amplio historial de vulnerabilidades de ZoneMinder. Si la interfaz es accesible a través de Internet, colóquela detrás de controles más estrictos, como el acceso VPN, un agente de confianza cero o restricciones estrictas de IP de origen, y asuma que cada ruta web autenticada o semiautenticada merece un escrutinio. La gravedad y la adyacencia de las vulnerabilidades anteriores justifican una postura más conservadora que "tiene una página de inicio de sesión, así que está bien". (NVD)

El tercer paso es revisar los registros del flujo de peticiones vulnerable. Usted está buscando el uso inesperado de la ruta de solicitud vinculada a view=request&request=event&action=removetag y anormal tid especialmente si el registro conserva las cadenas de consulta sin procesar. Incluso sin una firma perfecta, este tipo de revisión ayuda a separar "parcheado en teoría" de "posiblemente atacado antes de parchear". Las entradas del proveedor IPS de FortiGuard y Check Point refuerzan que el patrón de solicitud es lo suficientemente concreto como para detectarlo. (GitHub)

He aquí un sencillo ejemplo de caza de troncos que puede utilizarse con seguridad como punto de partida durante la revisión de incidentes:

grep -R "request=event&action=removetag" /var/log/apache2 /var/log/nginx 2>/dev/null

grep -R "view=request" /var/log/apache2 /var/log/nginx 2>/dev/null | grep "action=removetag"

No se trata de una estrategia de detección completa, pero es una comprobación operativa rápida. Si encuentra solicitudes coincidentes alrededor del momento en que se expuso una compilación vulnerable, pivotee en los registros de respuesta, registros de autenticación y cualquier rastro de auditoría de base de datos que conserve. El objetivo es responder a tres preguntas: si se podía acceder a la ruta vulnerable, si se utilizó de forma inusual y si la aplicación o la base de datos mostraron anomalías posteriores. La naturaleza de la inyección SQL hace que las anomalías posteriores sean tan importantes como la solicitud desencadenante. (Fundación OWASP)

El cuarto paso es asumir que el ámbito de la base de datos importa. Las directrices de OWASP dejan claro que el mínimo privilegio forma parte de la defensa contra inyecciones SQL, no sólo la codificación segura. Si la cuenta de base de datos detrás de ZoneMinder tiene derechos excesivos, el radio de explosión de cualquier vulnerabilidad de inyección crece rápidamente. Incluso después de aplicar los parches, merece la pena validar esto. Pregúntese si la aplicación realmente necesita amplias capacidades de escritura, borrado o administración en cada tabla que toca. En sistemas operativos antiguos, la respuesta suele ser "menos de lo que le concedimos". (Serie de hojas de trucos de OWASP)

El quinto paso consiste en pensar más allá de los límites del CVE y en la higiene de las credenciales. Las pruebas públicas de código y los debates sobre exploits suelen hacer hincapié en la enumeración de bases de datos y la recuperación de datos relacionados con el usuario. Si tiene una instalación vulnerable en Internet, no siempre basta con aplicar parches. Revise las cuentas de usuario de ZoneMinder, restablezca las credenciales de alto valor cuando proceda y compruebe si se reutilizan credenciales en otras partes de su entorno. Incluso si la ruta de inyección SQL no se convirtió en una brecha dramática, el material de usuario expuesto silenciosamente todavía puede convertirse en un punto de inflexión más adelante. (GitHub)

Lista de comprobación práctica para la validación de parches

Gran parte del trabajo posterior al asesoramiento fracasa porque los equipos parchean una vez y nunca validan. Para CVE-2024-51482, la validación del parche debería ser sencilla.

Cada línea de esa lista de comprobación se corresponde con la corrección oficial, el modelo defensivo de OWASP o las lecciones operativas de las CVE de ZoneMinder relacionadas. Así es como se ve una buena validación: no "se reinició después de la actualización", sino "el comportamiento de riesgo real cambió". (GitHub)

Si mantiene ZoneMinder desde el código fuente, el propio parche le proporciona el artefacto de verificación más concreto:

// Antes
$tagId = $_REQUEST['tid'];
$sql = "SELECT * FROM Events_Tags WHERE TagId = $tagId";
$rowCount = dbNumRows($sql);

// Después
$tagId = validCardinal($_REQUEST['tid']);
$rowCount = dbNumRows('SELECT * FROM Events_Tags WHERE TagId=?', [ $tagId ]);

Ese diff compacto cuenta toda la historia del defecto y de la corrección. También es el tipo de prueba a nivel de código que facilita la revisión de seguridad durante el control de cambios. (GitHub)

Controles defensivos que tienen sentido en torno a este fallo

Ningún control perimetral debe considerarse un sustituto de la aplicación de parches. Sin embargo, una vez que se conoce una vulnerabilidad y es fácil identificarla, las defensas en capas son importantes.

Una regla básica de proxy inverso puede reducir el abuso obvio contra la ruta de acción vulnerable mientras verifica las actualizaciones:

ubicación /zm/index.php {
    if ($arg_view = "request") {
        if ($arg_request = "evento") {
            if ($arg_action = "removetag") {
                return 403;
            }
        }
    }
}

Este ejemplo es intencionadamente contundente. No es una solución permanente para la aplicación y puede interferir con el flujo de trabajo legítimo, por lo que debe utilizarse con cautela. No se trata de que todo el mundo deba desplegar exactamente este fragmento. El punto es que la ruta de acción vulnerable es lo suficientemente estrecha como para soportar la contención temporal dirigida si necesita espacio para respirar durante la remediación de emergencia. (GitHub)

Una simple idea de ModSecurity sigue la misma lógica:

SecRule REQUEST_URI "@contiene /zm/index.php" \
    "id:5148201,phase:2,deny,status:403,chain,msg:'Possible CVE-2024-51482 probe'"
    SecRule ARGS:view "solicitud @streq" "cadena"
    SecRule ARGS:request "@streq evento" "cadena"
    SecRule ARGS:action "@streq removetag" "cadena"

No se trata de una firma certificada por el proveedor. Es un parche práctico que muestra cuán específico es el patrón de solicitud. El hecho de que tanto FortiGuard como Check Point ofrezcan protecciones con nombre para este problema refuerza el mismo punto operativo: la vulnerabilidad se presta para la detección y el bloqueo enfocados del lado de la red mientras usted completa la remediación de la aplicación. (Laboratorios FortiGuard)

Qué dice esta CVE sobre el riesgo del software de vigilancia

CVE-2024-51482 es fácil de descartar si sólo lo lees como "inyección SQL autenticada en un producto de CCTV de nicho". Ese encuadre se pierde la lección más grande.

Las plataformas de vigilancia y NVR ocupan a menudo un lugar incómodo en la cultura de seguridad empresarial. Son lo suficientemente potentes como para afectar a las operaciones, las investigaciones y la supervisión física, pero no siempre son propiedad de equipos que gestionan la seguridad de las aplicaciones principales con el mismo rigor que aplican a las pilas SaaS centrales o a los sistemas de identidad. Como resultado, estas plataformas pueden terminar expuestas a Internet, con parches insuficientes, y sólo ligeramente revisadas hasta que un aviso de alta gravedad obliga a prestarles atención. El reciente historial de vulnerabilidades de ZoneMinder sugiere que esta categoría merece una línea de base más madura: control de exposición más estricto, verificación de versiones frecuente, registro de aplicaciones y revisión de seguridad repetible de la superficie de administración. (NVD)

Aquí también se pone de manifiesto la importancia de la precisión de los límites de los parches. Cuando un software tiene varios problemas adyacentes en la misma línea menor, "hemos parcheado uno de los errores 2024" no es una estrategia. Es un recuerdo. Los defensores necesitan la verdad exacta de la versión, no comodidad a nivel de rama. CVE-2024-51482 es un buen recordatorio de que la gestión de vulnerabilidades tiene que ver tanto con la verificación disciplinada como con los avisos. (NVD)

Dónde puede ayudar, naturalmente, un flujo de trabajo de pentest asistido por IA

Para los equipos que gestionan una combinación de aplicaciones web internas, herramientas operativas y plataformas autoalojadas, lo más difícil no suele ser entender un CVE. Es convertir esa comprensión en un flujo de trabajo de verificación repetible. Una vulnerabilidad como la CVE-2024-51482 necesita que se hagan bien varias cosas: descubrimiento de activos, confirmación de la versión, comprobación de la ruta de acceso consciente del inicio de sesión, revisión de la exposición, validación del parche y comprobación posterior a la corrección. Estos pasos son tediosos cuando se realizan ad hoc y fáciles de omitir cuando el equipo está ocupado.

Ahí es donde una plataforma de pruebas de penetración asistida por IA como Penligent puede encajar de forma natural en el flujo de trabajo. El papel útil no es el descubrimiento mágico de vulnerabilidades por sí mismo. Es reducir la fricción de hacer el trabajo aburrido pero de alto valor de manera consistente: encontrar activos relevantes, comprobar si las instancias de ZoneMinder son accesibles externamente, validar rutas autenticadas de forma segura, organizar artefactos de verificación y producir un registro de remediación que se pueda compartir con ingeniería u operaciones sin reescribir todo desde cero. (Penligente)

En la práctica, el valor es mayor cuando el aviso ya es público. Los equipos de seguridad no necesitan otro panel que repita "inyección SQL crítica". Necesitan una forma de responder: qué instancias están afectadas, cuáles son accesibles, qué credenciales o roles pueden tocar la ruta vulnerable, si la corrección está realmente desplegada y si el problema ha desaparecido tras el control de cambios. Este es el tipo de flujo de trabajo en el que la automatización y la validación guiada por IA resultan más útiles. (Penligente)

La lección más profunda detrás de CVE-2024-51482

Lo más útil no es que ZoneMinder tuviera una inyección SQL más. Hay muchos productos con fallos aislados. La lección más importante es que los planos de gestión vinculados a las operaciones y a la supervisión física siguen siendo tratados con demasiada frecuencia como sistemas de baja presión hasta que una vulnerabilidad obliga a reevaluarlos.

CVE-2024-51482 importa porque el límite de corrección era fácil de malinterpretar si se copiaba el primer resumen en lugar de comprobar el registro corregido. Importa porque el código vulnerable era lo suficientemente simple como para que el fallo de codificación segura sea obvio en retrospectiva. Importa porque el material PoC público redujo la barrera al abuso práctico. E importa porque se encuentra dentro de un historial más amplio de ZoneMinder que ya incluye inyección SQL, XSS, inclusión de archivos locales y RCE sin autenticación en versiones cercanas. Leídos en conjunto, esos hechos cuentan una historia clara: defender el producto como un plano de gestión, no como una utilidad desechable. (NVD)

Si su equipo utiliza ZoneMinder en la actualidad, la respuesta inmediata es sencilla. Verifique la versión exacta. Cambie a la versión 1.37.65 o posterior. Revise la exposición. Cace la ruta de solicitud en los registros. Reevalúe los privilegios de la base de datos. Trate las suposiciones anteriores sobre "ya parcheado" como no fiables hasta que pueda probarlas. Para una vulnerabilidad tan sencilla, la verificación disciplinada es la diferencia entre la corrección real y el optimismo administrativo. (NVD)

Para saber más

• Registro NVD para CVE-2024-51482, incluyendo el límite de corrección corregido y el historial de cambios. (NVD)
• Aviso oficial de GitHub para GHSA-qm8h-3xvf-m7j3. (GitHub)
• Confirmación oficial del parche que muestra el paso de la interpolación bruta a las consultas validadas y parametrizadas. (GitHub)
• OWASP SQL Injection Prevention Cheat Sheet. (Serie de hojas de trucos de OWASP)
• Entrada NVD para CVE-2024-43360, la anterior inyección SQL de ZoneMinder de 2024. (NVD)
• Entrada NVD para CVE-2024-43359, el problema XSS relacionado con 2024. (NVD)
• Entrada NVD para CVE-2023-26035, el problema RCE no autenticado en versiones anteriores. (NVD)
• Entrada NVD para CVE-2023-26038, el problema de inclusión local de archivos en versiones anteriores. (NVD)
• Entrada de FortiGuard IPS para inyección SQL de ZoneMinder. (Laboratorios FortiGuard)
• Aviso de Check Point sobre la inyección SQL en ZoneMinder, CVE-2024-51482. (Software Check Point)
• Artículo de Penligent sobre CVE-2024-51482. (Penligente)
• Artículo de Penligent sobre la postura de seguridad más amplia de ZoneMinder. (Penligente)