Instituto Nacional de ciberseguridad. Sección Incibe

Boletín de vulnerabilidades

Vulnerabilidades con productos recientemente documentados:

No hay vulnerabilidades nuevas para los productos a los que está suscrito.



Otras vulnerabilidades de los productos a los que usted está suscrito, y cuya información ha sido actualizada recientemente:

  • Vulnerabilidad en Grafana (CVE-2023-5123)
    Severidad: ALTA
    Fecha de publicación: 14/02/2024
    Fecha de última actualización: 06/01/2026
    El complemento de fuente de datos JSON (https://grafana.com/grafana/plugins/marcusolsson-json-datasource/ https://grafana.com/grafana/plugins/marcusolsson-json-datasource/) es un complemento mantenido por Grafana Labs para Grafana que permite recuperar y procesar datos JSON desde un endpoint remoto (incluida una subruta específica) configurado por un administrador. Debido a una sanitización inadecuada del parámetro de ruta proporcionado por el panel, fue posible incluir caracteres de path traversal (../) en el parámetro de ruta y enviar solicitudes a rutas en el endpoint configurado fuera de la subruta configurada. Esto significa que si un administrador configuró la fuente de datos para que apunte a alguna subruta de un dominio (por ejemplo, https://example.com/api/some_safe_api/ https://example.com/api/some_safe_api/), Era posible que un editor creara un panel que hiciera referencia a la fuente de datos y que emitiera consultas que contuvieran caracteres de path traversal, lo que a su vez causaría que la fuente de datos consultara subrutas arbitrarias en el dominio configurado (por ejemplo, https://example.com/api/admin_api/ ) https://example.com/api/admin_api/). En el raro caso de que un administrador configure este complemento para apuntar a la propia instancia de Grafana, esta vulnerabilidad se vuelve considerablemente más grave, ya que un administrador que navega por un panel configurado maliciosamente podría verse obligado a realizar solicitudes a los endpoints de la API administrativa de Grafana con sus credenciales, lo que genera la posibilidad de una escalada de privilegios, de ahí la puntuación alta para esta vulnerabilidad.
  • Vulnerabilidad en Git (CVE-2024-32004)
    Severidad: ALTA
    Fecha de publicación: 14/05/2024
    Fecha de última actualización: 06/01/2026
    Git es un sistema de control de revisiones. Antes de las versiones 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 y 2.39.4, un atacante puede preparar un repositorio local de tal manera que, cuando se clone, ejecute código arbitrario durante la operación. El problema se solucionó en las versiones 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 y 2.39.4. Como workaround, evite clonar repositorios de fuentes que no sean de confianza.
  • Vulnerabilidad en Git (CVE-2024-32020)
    Severidad: BAJA
    Fecha de publicación: 14/05/2024
    Fecha de última actualización: 06/01/2026
    Git es un sistema de control de revisiones. Antes de las versiones 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 y 2.39.4, los clones locales pueden terminar vinculando archivos a la base de datos de objetos del repositorio de destino cuando el repositorio de origen y el de destino residen en el mismo disco. Si el repositorio de origen es propiedad de un usuario diferente, el usuario que no es de confianza puede reescribir esos archivos vinculados en cualquier momento. La clonación de repositorios locales hará que Git copie o vincule archivos del repositorio de origen al repositorio de destino. Esto acelera significativamente dichos clones locales en comparación con realizar un clon "adecuado" y ahorra espacio en disco y tiempo de cálculo. Al clonar un repositorio ubicado en el mismo disco que es propiedad de un usuario diferente al usuario actual, también terminamos creando dichos enlaces físicos. Estos archivos seguirán siendo propiedad y controlados por el usuario potencialmente no confiable y podrán ser reescritos por él a voluntad en el futuro. El problema se solucionó en las versiones 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 y 2.39.4.
  • Vulnerabilidad en urllib3 (CVE-2024-37891)
    Severidad: MEDIA
    Fecha de publicación: 17/06/2024
    Fecha de última actualización: 06/01/2026
    urllib3 es una librería cliente HTTP fácil de usar para Python. Cuando se utiliza el soporte de proxy de urllib3 con `ProxyManager`, el encabezado `Proxy-Authorization` solo se envía al proxy configurado, como se esperaba. Sin embargo, al enviar solicitudes HTTP *sin* utilizar el soporte de proxy de urllib3, es posible configurar accidentalmente el encabezado `Proxy-Authorization` aunque no tendrá ningún efecto ya que la solicitud no utiliza un proxy de reenvío o un proxy de túnel. En esos casos, urllib3 no trata el encabezado HTTP "Proxy-Authorization" como si llevara material de autenticación y, por lo tanto, no elimina el encabezado en redirecciones de origen cruzado. Dado que se trata de un escenario muy improbable, creemos que la gravedad de esta vulnerabilidad es baja para casi todos los usuarios. Por precaución, urllib3 eliminará automáticamente el encabezado "Proxy-Authorization" durante las redirecciones entre orígenes para evitar la pequeña posibilidad de que los usuarios hagan esto por accidente. Los usuarios deben usar el soporte de proxy de urllib3 o desactivar las redirecciones automáticas para lograr un procesamiento seguro del encabezado `Proxy-Authorization`, pero aun así decidimos eliminar el encabezado de forma predeterminada para proteger aún más a los usuarios que no utilizan el enfoque correcto. Creemos que la cantidad de usos afectados por este aviso es baja. Requiere que todo lo siguiente sea cierto para ser explotado: 1. Configurar el encabezado `Proxy-Authorization` sin utilizar el soporte de proxy integrado de urllib3. 2. No deshabilitar las redirecciones HTTP. 3. Ya sea no utilizar un servidor de origen HTTPS o que el proxy o el origen de destino redirija a un origen malicioso. Se recomienda a los usuarios que actualicen a la versión 1.26.19 o a la versión 2.2.2. Los usuarios que no puedan actualizar pueden usar el encabezado `Proxy-Authorization` con `ProxyManager` de urllib3, deshabilitar las redirecciones HTTP usando `redirects=False` al enviar solicitudes o no usar el encabezado `Proxy-Authorization` como mitigación.
  • Vulnerabilidad en kernel de Linux (CVE-2024-39463)
    Severidad: ALTA
    Fecha de publicación: 25/06/2024
    Fecha de última actualización: 06/01/2026
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: 9p: agregar bloqueo faltante al tomar la lista de fid de dentry. Se corrigió un use-after-free en la lista de fid d_fsdata de dentry cuando un subproceso busca un fid a través de dentry mientras otro subproceso lo desvincula: UAF hilo: refcount_t: suma en 0; use-after-free. p9_fid_get linux/./include/net/9p/client.h:262 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181 v9fs_fid_lookup+0xbf/0xc20 Linux /fs/9p/fid.c:314 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248 Liberado por: p9_fid_destroy (en línea) desconocido+0xb0 /0xe0 linux/net/9p/client.c:1456 p9_fid_put linux/./include/net/9p/client.h:278 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335 El problema es que no se accedió a d_fsdata bajo d_lock, porque normalmente d_release() solo se llama una vez que dentry no está disponible. ya no es accesible, pero como también lo llamamos explícitamente en v9fs_remove, ese bloqueo es necesario: mueva la hlist fuera del dentry bajo bloqueo y luego elimine la referencia de sus fids una vez que ya no sean accesibles.
  • Vulnerabilidad en kernel de Linux (CVE-2024-39494)
    Severidad: ALTA
    Fecha de publicación: 12/07/2024
    Fecha de última actualización: 06/01/2026
    En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ima: corrige el use-after-free en dentry dname.name ->d_name.name puede cambiar al cambiar el nombre y el valor anterior se puede liberar; existen condiciones suficientes para estabilizarlo (->d_lock on dentry, ->d_lock on its parent, ->i_rwsem exclusivo en el inodo del padre, rename_lock), pero ninguna de ellas se cumple en ninguno de los sitios. En su lugar, tome una instantánea estable del nombre.
  • Vulnerabilidad en kernel de Linux (CVE-2024-39496)
    Severidad: ALTA
    Fecha de publicación: 12/07/2024
    Fecha de última actualización: 06/01/2026
    En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: btrfs:zoned: corrige el use-after-free debido a la ejecución con el reemplazo de desarrollo. Mientras cargamos la información de una zona durante la creación de un grupo de bloques, podemos ejecutar una operación de reemplazo de dispositivo y luego activar un use-after-free en el dispositivo que acaba de ser reemplazado (dispositivo fuente de la operación de reemplazo). Esto sucede porque en btrfs_load_zone_info() extraemos un dispositivo del mapa de fragmentos en una variable local y luego usamos el dispositivo mientras no está bajo la protección del dispositivo y reemplazamos rwsem. Entonces, si se produce una operación de reemplazo de dispositivo cuando extraemos el dispositivo y ese dispositivo es la fuente de la operación de reemplazo, activaremos un use-after-free si antes de terminar de usar el dispositivo la operación de reemplazo finaliza y libera el dispositivo. Solucione este problema ampliando la sección crítica bajo la protección del dispositivo y reemplace rwsem para que todos los usos del dispositivo se realicen dentro de la sección crítica.
  • Vulnerabilidad en Cisco Discovery Protocol y Link Layer Discovery Protocol (CVE-2021-1379)
    Severidad: MEDIA
    Fecha de publicación: 18/11/2024
    Fecha de última actualización: 06/01/2026
    Varias vulnerabilidades en las implementaciones de Cisco Discovery Protocol y Link Layer Discovery Protocol (LLDP) para los teléfonos IP de Cisco de las series 68xx/78xx/88xx podrían permitir que un atacante adyacente no autenticado ejecute código de forma remota o provoque una recarga de un teléfono IP afectado. Estas vulnerabilidades se deben a la falta de comprobaciones cuando el teléfono IP procesa un paquete Cisco Discovery Protocol o LLDP. Un atacante podría explotar estas vulnerabilidades enviando un paquete Cisco Discovery Protocol o LLDP malicioso al teléfono IP de destino. Una explotación exitosa podría permitir al atacante ejecutar código en el teléfono IP afectado o hacer que se recargue inesperadamente, lo que resultaría en una condición de denegación de servicio (DoS). Nota: Cisco Discovery Protocol es un protocolo de capa 2. Para explotar estas vulnerabilidades, un atacante debe estar en el mismo dominio de difusión que el dispositivo afectado (adyacente a la capa 2). Cisco ha publicado actualizaciones de software que solucionan estas vulnerabilidades. No existen workarounds que solucionen estas vulnerabilidades.
  • Vulnerabilidad en WebAssembly wabt 1.0.36 (CVE-2025-2368)
    Severidad: MEDIA
    Fecha de publicación: 17/03/2025
    Fecha de última actualización: 06/01/2026
    Se encontró una vulnerabilidad en WebAssembly wabt 1.0.36, clasificada como crítica. Este problema afecta a la función wabt::interp::(anonymous namespace)::BinaryReaderInterp::OnExport del archivo wabt/src/interp/binary-reader-interp.cc del componente Malformed File Handler. La manipulación provoca un desbordamiento del búfer en el montón. El ataque puede iniciarse remotamente. Se ha hecho público el exploit y puede que sea utilizado. Se recomienda aplicar un parche para solucionar este problema.
  • Vulnerabilidad en WebAssembly WABT (CVE-2025-6273)
    Severidad: MEDIA
    Fecha de publicación: 19/06/2025
    Fecha de última actualización: 06/01/2026
    Se encontró una vulnerabilidad en WebAssembly WABT hasta la versión 1.0.37, clasificada como problemática. Este problema afecta a la función LogOpcode del archivo src/binary-reader-objdump.cc. La manipulación genera una aserción accesible. Se requiere acceso local para abordar este ataque. Se ha hecho público el exploit y puede que sea utilizado. La existencia real de esta vulnerabilidad aún se duda. El responsable del código explica que este problema podría no afectar a los programas WASM del mundo real.