Instituto Nacional de ciberseguridad. Sección Incibe
Instituto Nacional de Ciberseguridad. Sección INCIBE-CERT

Vulnerabilidades

Con el objetivo de informar, advertir y ayudar a los profesionales sobre las últimas vulnerabilidades de seguridad en sistemas tecnológicos, ponemos a disposición de los usuarios interesados en esta información una base de datos con información en castellano sobre cada una de las últimas vulnerabilidades documentadas y conocidas.

Este repositorio con más de 75.000 registros esta basado en la información de NVD (National Vulnerability Database) – en función de un acuerdo de colaboración – por el cual desde INCIBE realizamos la traducción al castellano de la información incluida. En ocasiones este listado mostrará vulnerabilidades que aún no han sido traducidas debido a que se recogen en el transcurso del tiempo en el que el equipo de INCIBE realiza el proceso de traducción.

Se emplea el estándar de nomenclatura de vulnerabilidades CVE (Common Vulnerabilities and Exposures), con el fin de facilitar el intercambio de información entre diferentes bases de datos y herramientas. Cada una de las vulnerabilidades recogidas enlaza a diversas fuentes de información así como a parches disponibles o soluciones aportadas por los fabricantes y desarrolladores. Es posible realizar búsquedas avanzadas teniendo la opción de seleccionar diferentes criterios como el tipo de vulnerabilidad, fabricante, tipo de impacto entre otros, con el fin de acortar los resultados.

Mediante suscripción RSS o Boletines podemos estar informados diariamente de las últimas vulnerabilidades incorporadas al repositorio.

Vulnerabilidad en kernel de Linux (CVE-2024-50010)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: exec: no WARN para comprobación atrevida de path_noexec Tanto las comprobaciones i_mode como noexec envueltas en WARN_ON provienen de un artefacto de la implementación anterior. Solían comprobar legítimamente la condición, pero eso se movió hacia arriba en dos confirmaciones: 633fb6ac3980 ("exec: mover la comprobación S_ISREG() antes") 0fd338b2d2cd ("exec: mover la comprobación path_noexec() antes") En lugar de eliminarse, dichas comprobaciones se WARN_ON, lo que tiene algún valor de depuración. Sin embargo, la comprobación falsa path_noexec es atrevida, lo que resulta en advertencias injustificadas si alguien se apresura a configurar el indicador noexec. Se puede notar que hay más para comprobar si se permite execve y no se garantiza que ninguna de las condiciones siga siendo válida después de que se probaron. Además, esto no valida si la ruta del código realizó alguna verificación de permisos para comenzar; pasará si el inodo resulta ser regular. Mantenga la verificación redundante path_noexec() aunque sea una verificación sin sentido de garantía que no se proporciona, así que elimine la ADVERTENCIA. Reformule el comentario y haga pequeñas correcciones mientras esté aquí. [brauner: mantenga la verificación redundante path_noexec()]
Gravedad CVSS v3.1: MEDIA
Última modificación:
12/05/2026

Vulnerabilidad en kernel de Linux (CVE-2024-50015)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ext4: dax: se corrige el desbordamiento de extensiones más allá del tamaño del inodo al escribir parcialmente. Dax_iomap_rw() hace dos cosas en cada iteración: asigna bloques escritos y copia datos de usuario a bloques. Si el usuario finaliza el proceso (consulte el manejo de señales en dax_iomap_iter()), los datos copiados se devolverán y se agregarán al tamaño del inodo, lo que significa que la longitud de las extensiones escritas puede exceder el tamaño del inodo, entonces fsck fallará. Se proporciona un ejemplo como: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // ronda 1 ext4_iomap_begin ext4_iomap_alloc // asignar 0~2M de extensiones (bandera escrita) dax_iomap_iter // copiar 2M de datos iomap_iter // ronda 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // asignar 2~4M de extensiones (bandera escrita) dax_iomap_iter fatal_signal_pending hecho = iter->pos - iocb->ki_pos // hecho = 2M ext4_handle_inode_extension ext4_update_inode_size // tamaño de inodo = 2M fsck informa: Inodo 13, i_size es 2097152, debería ser 4194304. ¿Solución? Solucione el problema truncando las extensiones si la longitud escrita es menor a la esperada.
Gravedad CVSS v3.1: MEDIA
Última modificación:
12/05/2026

Vulnerabilidad en PHPGurukul Hospital Management System 4.0 (CVE-2024-46238)

Fecha de publicación:
21/10/2024
Idioma:
Español
Existen múltiples vulnerabilidades de Cross Site Scripting (XSS) en PHPGurukul Hospital Management System 4.0 a través del parámetro docname en /admin/add-doctor.php y /admin/edit-doctor.php
Gravedad CVSS v3.1: MEDIA
Última modificación:
31/03/2025

Vulnerabilidad en PHPGurukul Hospital Management System 4.0 (CVE-2024-46239)

Fecha de publicación:
21/10/2024
Idioma:
Español
Existen múltiples vulnerabilidades de Cross Site Scripting en PHPGurukul Hospital Management System 4.0 a través del parámetro docname en /doctor/edit-profile.php y el parámetro adminremark en /admin/query-details.php.
Gravedad CVSS v3.1: MEDIA
Última modificación:
31/03/2025

Vulnerabilidad en Cilium (CVE-2024-47825)

Fecha de publicación:
21/10/2024
Idioma:
Español
Cilium es una solución de redes, observabilidad y seguridad con un plano de datos basado en eBPF. A partir de la versión 1.14.0 y antes de las versiones 1.14.16 y 1.15.10, una regla de política que deniegue un prefijo más amplio que `/32` puede ignorarse si hay una regla de política que haga referencia a un prefijo más estrecho (`CIDRSet` o `toFQDN`) y esta regla de política más estrecha especifica `enableDefaultDeny: false` o `- toEntities: all`. Tenga en cuenta que una regla que especifique `toEntities: world` o `toEntities: 0.0.0.0/0` no es suficiente, debe ser para la entidad `all`. Este problema se ha corregido en Cilium v1.14.16 y v1.15.10. Como este problema solo afecta a las políticas que utilizan `enableDefaultDeny: false` o que establecen `toEntities` en `all`, hay algunas soluciones alternativas disponibles. Para los usuarios con políticas que utilizan `enableDefaultDeny: false`, elimine esta opción de configuración y defina explícitamente las reglas de permiso requeridas. Para los usuarios con políticas de salida que especifican explícitamente `toEntities: all`, utilice `toEntities: world`.
Gravedad CVSS v3.1: MEDIA
Última modificación:
19/12/2024

Vulnerabilidad en CodeAstro Membership Management System v1.0 (CVE-2024-46236)

Fecha de publicación:
21/10/2024
Idioma:
Español
CodeAstro Membership Management System v1.0 es vulnerable a Cross Site Scripting (XSS) a través del parámetro de dirección en add_members.php y edit_member.php.
Gravedad CVSS v3.1: MEDIA
Última modificación:
31/03/2025

Vulnerabilidad en CodeAstro Membership Management System v1.0 (CVE-2024-48709)

Fecha de publicación:
21/10/2024
Idioma:
Español
CodeAstro Membership Management System v1.0 es vulnerable a Cross Site Scripting (XSS) a través del parámetro membershipType en edit_type.php
Gravedad CVSS v3.1: MEDIA
Última modificación:
31/03/2025

Vulnerabilidad en kernel de Linux (CVE-2024-50000)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5e: Se ha corregido la desreferenciación NULL en mlx5e_tir_builder_alloc(). En mlx5e_tir_builder_alloc(), kvzalloc() puede devolver NULL, que se desreferencia en la siguiente línea en una referencia al campo de modificación. Encontrado por Linux Verification Center (linuxtesting.org) con SVACE.
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-50002)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: static_call: Manejar el error de inicialización del módulo correctamente en static_call_del_module() La inserción del módulo invoca static_call_add_module() para inicializar las llamadas estáticas en un módulo. static_call_add_module() invoca __static_call_init(), que asigna una estructura static_call_mod para encapsular los sitios de llamadas estáticas integrados de la clave asociada en ella para que se puedan agregar más módulos o para agregar el módulo a la cadena de módulos. Si esa asignación fallo, la función regresa con un código de error y el núcleo del módulo invoca static_call_del_module() para limpiar las entradas static_call_mod agregadas eventualmente. Esto funciona correctamente, cuando todas las claves utilizadas por el módulo se convirtieron a una cadena de módulos antes del error. Si no, static_call_del_module() causa un #GP ya que asume ciegamente que key::mods apunta a una estructura static_call_mod válida. El problema es que key::mods no es un miembro de estructura individual de struct static_call_key, es parte de una unión para ahorrar espacio: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites es un puntero a la lista de sitios de uso integrados de la llamada estática. El tipo del puntero se diferencia por el bit 0. Un puntero mods tiene el bit claro, el puntero sites tiene el bit establecido. Como static_call_del_module() asume ciegamente que el puntero es un tipo static_call_mod válido, no puede verificar este caso de fallo y desreferencia el puntero a la lista de sitios de llamada integrados, lo que obviamente es falso. Solucione esto verificando si la clave tiene un puntero sites o mods. Si es un puntero sites, entonces no se debe tocar la clave. Como los sitios se recorren en el mismo orden que en __static_call_init(), el recorrido del sitio puede terminarse porque el código de inicio no ha tocado todos los sitios posteriores debido a la salida de error. Si se convirtió antes de que fallara la asignación, entonces el bucle interno que busca una coincidencia de módulo no encontrará nada. un fallo en la segunda asignación en __static_call_init() es inofensiva y no requiere un tratamiento especial. La primera asignación tuvo éxito y convirtió la clave en una cadena de módulos. Esa primera entrada tiene mod::mod == NULL y mod::next == NULL, por lo que el bucle interno de static_call_del_module() no encontrará una coincidencia de módulo ni una cadena de módulos. El siguiente sitio en el recorrido ya se convirtió, pero no puede coincidir con el módulo, o saldrá del bucle externo porque tiene un puntero static_call_site y no un puntero static_call_mod.
Gravedad CVSS v3.1: MEDIA
Última modificación:
03/11/2025

Vulnerabilidad en kernel de Linux (CVE-2024-50001)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net/mlx5: Corregir ruta de error en transmisión WQE de paquetes múltiples Eliminar la desasignación errónea en caso de que no se haya establecido una asignación DMA El código de transmisión WQE de paquetes múltiples intenta obtener una asignación DMA para el skb. Esto podría fallar, por ejemplo, bajo presión de memoria, cuando el controlador IOMMU simplemente no puede asignar más memoria para las tablas de páginas. Si bien el código intenta manejar esto en la ruta debajo de la etiqueta err_unmap, desasigna erróneamente una entrada de la lista FIFO de asignaciones activas del sq. Dado que el intento de asignación actual falló, esta desasignación está eliminando alguna asignación DMA aleatoria que aún podría ser necesaria. Si la función PCI ahora presenta ese IOVA, el IOMMU puede asumir un acceso DMA no autorizado y, por ejemplo, en s390 pone la función PCI en estado de error. El comportamiento erróneo se observó en un entorno de prueba de estrés que creó presión de memoria.
Gravedad CVSS v3.1: MEDIA
Última modificación:
12/05/2026

Vulnerabilidad en kernel de Linux (CVE-2024-49987)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpftool: corrige comportamiento indefinido en qsort(NULL, 0, ...) Cuando netfilter no tiene ninguna entrada para mostrar, se llama a qsort con qsort(NULL, 0, ...). Esto da como resultado un comportamiento indefinido, como informa UBSan: net.c:827:2: error en tiempo de ejecución: puntero nulo pasado como argumento 1, que se declara que nunca será nulo Aunque el estándar C no indica explícitamente si llamar a qsort con un puntero NULL cuando el tamaño es 0 constituye un comportamiento indefinido, la Sección 7.1.4 del estándar C (Uso de funciones de librería) menciona: "Cada una de las siguientes afirmaciones se aplica a menos que se indique explícitamente lo contrario en las descripciones detalladas que siguen: si un argumento de una función tiene un valor no válido (como un valor fuera del dominio de la función, o un puntero fuera del espacio de direcciones del programa, o un puntero nulo, o un puntero a almacenamiento no modificable cuando el parámetro correspondiente no está calificado como constante) o un tipo (después de la promoción) no esperado por una función con un número variable de argumentos, el comportamiento es indefinido". Para evitar esto, agregue un retorno temprano cuando nf_link_info sea NULL para evitar llamar a qsort con un puntero NULL.
Gravedad CVSS v3.1: MEDIA
Última modificación:
28/10/2024

Vulnerabilidad en kernel de Linux (CVE-2024-49988)

Fecha de publicación:
21/10/2024
Idioma:
Español
En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ksmbd: agregar refcnt a la estructura ksmbd_conn Al enviar una solicitud de interrupción de oplock, se utiliza opinfo->conn, pero freed ->conn se puede utilizar en multicanal. Este parche agrega un recuento de referencia a la estructura ksmbd_conn para que se pueda liberar cuando ya no se utiliza.
Gravedad CVSS v3.1: MEDIA
Última modificación:
28/10/2024