Instituto Nacional de ciberseguridad. Sección Incibe

017 - Ir a la línea de ayuda en Ciberseguridad    Ir a Agenda     Ir a Sala de prensa     Ir a suscripción de boletines

Ir al buscador

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 Linux (CVE-2026-23101)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: leds: led-class: Solo añadir el LED a leds_list cuando esté completamente listo Antes de este cambio, el LED se añadía a leds_list antes de que se llamara a led_init_core(), añadiéndolo a la lista antes de que se inicializara led_classdev.set_brightness_work. Esto deja una ventana donde led_trigger_register() del disparador predeterminado de un LED llamará a led_trigger_set(), que llama a led_set_brightness(), lo que a su vez terminará encolando el led_classdev.set_brightness_work *no inicializado*. Esta condición de carrera es activada por el controlador EC de lenovo-thinkpad-t14s, que registra 2 LEDs con un disparador predeterminado proporcionado por snd_ctl_led.ko en rápida sucesión. La primera llamada a led_classdev_register() provoca la ejecución de un modprobe asíncrono de snd_ctl_led y ese modprobe asíncrono logra alcanzar exactamente la ventana donde el segundo LED está en leds_list sin que se haya llamado a led_init_core() para él, resultando en: ------------[ cut here ]------------ ADVERTENCIA: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 __flush_work+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Rastreo de llamadas: __flush_work+0x344/0x390 (P) flush_work+0x2c/0x50 led_trigger_set+0x1c8/0x340 led_trigger_register+0x17c/0x1c0 led_trigger_register_simple+0x84/0xe8 snd_ctl_led_init+0x40/0xf88 [snd_ctl_led] do_one_initcall+0x5c/0x318 do_init_module+0x9c/0x2b8 load_module+0x7e0/0x998 Cerrar la ventana de la condición de carrera moviendo la adición del LED a leds_list a después de la llamada a led_init_core().
  • Vulnerabilidad en Linux (CVE-2026-23102)
    Severidad: ALTA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64/fpsimd: señal: Corrección de la restauración del contexto SVE Cuando SME es compatible, la restauración del contexto de señal SVE puede salir mal de varias maneras, incluyendo colocar la tarea en un estado inválido donde el kernel puede leer de memoria fuera de límites (y puede potencialmente sufrir una falla fatal) y/o puede terminar la tarea con un SIGKILL. (1) Restaurar un contexto con SVE_SIG_FLAG_SM establecido puede colocar la tarea en un estado inválido donde SVCR.SM está establecido (y sve_state no es NULL) pero TIF_SME está despejado, lo que consecuentemente resulta en lecturas de memoria fuera de límites y/o la terminación de la tarea con SIGKILL. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde el contexto de señal SVE ha sido modificado por el espacio de usuario o fue guardado en el contexto de otra tarea (p. ej., como con CRIU), ya que de lo contrario la presencia de un contexto de señal SVE con SVE_SIG_FLAG_SM implica que TIF_SME ya está establecido. Mientras en este estado, task_fpsimd_load() NO configurará SMCR_ELx (dejando algún valor arbitrario configurado en hardware) antes de restaurar SVCR e intentar restaurar los registros SVE en modo streaming desde la memoria a través de sve_load_state(). Como el valor de SMCR_ELx.LEN puede ser mayor que la longitud del vector SVE en modo streaming de la tarea, esto puede leer memoria fuera del sve_state asignado a la tarea, leyendo datos no relacionados y/o desencadenando una falla. Si bien esto puede resultar en la carga de secretos en los registros SVE en modo streaming, estos valores nunca son expuestos. Como TIF_SME está despejado, fpsimd_bind_task_to_cpu() configurará CPACR_ELx.SMEN para atrapar accesos EL0 a los registros SVE en modo streaming, por lo que estos no pueden ser accedidos directamente en EL0. Como fpsimd_save_user_state() verifica la longitud del vector en vivo antes de guardar el estado (S)SVE en memoria, ningún valor secreto puede ser guardado de nuevo en memoria (y por lo tanto no puede ser observado a través de ptrace, señales, etc.). Cuando la longitud del vector en vivo no coincide con la longitud del vector esperada para la tarea, fpsimd_save_user_state() enviará una señal SIGKILL fatal a la tarea. Por lo tanto, la tarea puede ser terminada después de ejecutar el espacio de usuario por algún período de tiempo. (2) Restaurar un contexto con SVE_SIG_FLAG_SM despejado no despeja el SVCR.SM de la tarea. Si SVCR.SM estaba establecido antes de restaurar el contexto, entonces la tarea quedará en modo streaming inesperadamente, y algún estado de registro se combinará de manera inconsistente, aunque la tarea quedará en un estado legítimo desde el punto de vista del kernel. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde ptrace ha sido usado para establecer SVCR.SM después de la entrada a la llamada al sistema sigreturn, ya que la entrada a la llamada al sistema despeja SVCR.SM. En estos casos, los datos de registro SVE proporcionados se cargarán en el sve_state de la tarea usando la longitud del vector SVE no-streaming y los registros FPSIMD se fusionarán en esto usando la longitud del vector SVE en modo streaming. Solución para (1) estableciendo TIF_SME al establecer SVCR.SM. Esto también requiere asegurar que el sme_state de la tarea ha sido asignado, pero como esto podría contener estado ZA en vivo, no debe ser puesto a cero. Solución para (2) despejando SVCR.SM al restaurar un contexto de señal SVE con SVE_SIG_FLAG_SM despejado. Para consistencia, he adelantado la manipulación de SVCR, TIF_SVE, TIF_SME y fp_type, inmediatamente después de la asignación de sve_state/sme_state, antes de la restauración del estado de registro real. Esto facilita asegurar que estos siempre se modifiquen de manera consist
  • Vulnerabilidad en Linux (CVE-2026-23103)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ipvlan: Hacer que el addrs_lock sea por puerto Hacer que el addrs_lock sea por puerto, no por dispositivo ipvlan. El código inicial parece estar escrito bajo la suposición de que cualquier cambio de dirección debe ocurrir bajo RTNL. Pero no es así para el caso de IPv6. Así que 1) Introducir addrs_lock por puerto. 2) Fue necesario corregir lugares donde se olvidó tomar el bloqueo (ipvlan_open/ipvlan_close) Esto parece ser un problema muy menor, sin embargo. Ya que es muy poco probable que ipvlan_add_addr() sea llamado en 2 CPU simultáneamente. Pero, sin embargo, esto podría causar: 1) Falso negativo de ipvlan_addr_busy(): una interfaz iteró a través de todos los port->ipvlans + ipvlan->addrs bajo algún spinlock de ipvlan, y otra añadió IP bajo su propio bloqueo. Aunque esto solo es posible para IPv6, ya que parece que solo ipvlan_addr6_event() puede ser llamado sin rtnl_lock. 2) Condición de carrera ya que ipvlan_ht_addr_add(port) es llamado bajo diferentes bloqueos ipvlan->addrs_lock. Esto no debería afectar el rendimiento, ya que añadir/eliminar IP es una situación rara y el spinlock no se toma en rutas rápidas.
  • Vulnerabilidad en Linux (CVE-2026-23104)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: ice: corrige el rastreo de llamadas de recarga de devlink El commit 4da71a77fc3b ('ice: read internal temperature sensor') introdujo la lectura del sensor de temperatura interno a través de HWMON. ice_hwmon_init() se añadió a ice_init_feature() y ice_hwmon_exit() se añadió a ice_remove(). Como resultado, si se utiliza la recarga de devlink para reinicializar el dispositivo y luego se elimina el controlador, puede ocurrir un rastreo de llamadas. ERROR: no se puede manejar el fallo de página para la dirección: ffffffffc0fd4b5d Rastreo de Llamadas: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 name_show+0x1f/0x30 dev_attr_show+0x19/0x60 El rastreo de llamadas se repite aproximadamente cada 10 minutos cuando las herramientas de monitoreo del sistema (p. ej., sadc) intentan leer los atributos huérfanos de hwmon sysfs que referencian memoria de módulo liberada. La secuencia es: 1. Carga del controlador, ice_hwmon_init() es llamado desde ice_init_feature() 2. Recarga de Devlink hacia abajo, el flujo no llama a ice_remove() 3. Recarga de Devlink hacia arriba, ice_hwmon_init() es llamado desde ice_init_feature() resultando en una segunda instancia 4. Descarga del controlador, ice_hwmon_exit() llamado desde ice_remove() dejando la primera instancia de hwmon huérfana con un puntero colgante Solucione esto moviendo ice_hwmon_exit() de ice_remove() a ice_deinit_features() para asegurar una simetría de limpieza adecuada con ice_hwmon_init().
  • Vulnerabilidad en Linux (CVE-2026-23105)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net/sched: qfq: Usar cl_is_active para determinar si la clase está activa en qfq_rm_from_ag Esto es más bien un parche preventivo para hacer el código más consistente y para prevenir posibles exploits que emplean manipulaciones de qlen secundarias en qfq. usar cl_is_active en lugar de depender del qlen del qdisc secundario para determinar la activación de la clase.
  • Vulnerabilidad en Linux (CVE-2026-23106)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: gestión del tiempo: Ajustar el estado de salto para el gestor de tiempo auxiliar correcto Cuando se introdujo __do_ajdtimex() para manejar adjtimex para cualquier gestor de tiempo, esta referencia a tk_core no fue actualizada. Cuando se invocaba en un gestor de tiempo auxiliar, el gestor de tiempo principal se actualizaría incorrectamente. Esto es detectado por los diagnósticos de depuración de bloqueos porque el bloqueo de secuencia de los gestores de tiempo se escribe sin mantener su spinlock asociado: ADVERTENCIA: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125 aux_clock_adj (kernel/time/timekeeping.c:2979) __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173) do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131) Actualizar el gestor de tiempo auxiliar correcto.
  • Vulnerabilidad en Linux (CVE-2026-23107)
    Severidad: MEDIA
    Fecha de publicación: 04/02/2026
    Fecha de última actualización: 19/03/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64/fpsimd: señal: Asignar almacenamiento SSVE al restaurar ZA El código para restaurar un contexto ZA no intenta asignar el sve_state de la tarea antes de establecer TIF_SME. En consecuencia, restaurar un contexto ZA puede colocar una tarea en un estado inválido donde TIF_SME está establecido pero el sve_state de la tarea es NULL. En casos legítimos pero poco comunes donde el contexto de señal ZA NO fue creado por el kernel en el contexto de la misma tarea (por ejemplo, si la tarea se guarda/restaura con algo como CRIU), no tenemos garantía de que sve_state se haya asignado previamente. En estos casos, el espacio de usuario puede entrar en modo de transmisión sin atrapar mientras sve_state es NULL, causando una desreferencia de puntero NULL posterior cuando el kernel intenta almacenar el estado del registro: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Esto se soluciona haciendo que restore_za_context() asegure que el sve_state de la tarea esté asignado, coincidiendo con lo que hacemos al tomar una trampa SME. Cualquier estado SVE/SSVE activo (que se restaura anteriormente desde un contexto de señal separado) debe ser preservado, y por lo tanto no se pone a cero.
  • Vulnerabilidad en hexpm (CVE-2026-21622)
    Severidad: CRÍTICA
    Fecha de publicación: 05/03/2026
    Fecha de última actualización: 19/03/2026
    Vulnerabilidad de expiración de sesión insuficiente en hexpm hexpm/hexpm (módulo 'Elixir.Hexpm.Accounts.PasswordReset') permite la toma de control de cuentas. Los tokens de restablecimiento de contraseña generados a través del flujo 'Restablecer su contraseña' no expiran. Cuando un usuario solicita un restablecimiento de contraseña, Hex envía un correo electrónico que contiene un enlace de restablecimiento con un token. Este token permanece válido indefinidamente hasta que se usa. No se aplica ninguna expiración basada en el tiempo. Si los correos electrónicos históricos de un usuario se exponen a través de una violación de datos (por ejemplo, un archivo de buzón de correo filtrado), cualquier correo electrónico de restablecimiento de contraseña no utilizado contenido en ese conjunto de datos podría ser utilizado por un atacante para restablecer la contraseña de la víctima. El atacante no necesita acceso actual a la cuenta de correo electrónico de la víctima, solo acceso a una copia previamente filtrada del correo electrónico de restablecimiento. Esta vulnerabilidad está asociada con los archivos de programa lib/hexpm/accounts/password_reset.ex y las rutinas de programa 'Elixir.Hexpm.Accounts.PasswordReset':can_reset?/3. Este problema afecta a hexpm: desde 617e44c71f1dd9043870205f371d375c5c4d886d antes de bb0e42091995945deef10556f58d046a52eb7884.
  • Vulnerabilidad en traefik (CVE-2026-29777)
    Severidad: MEDIA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Traefik es un proxy inverso HTTP y un balanceador de carga. Antes de la versión 3.6.10, un inquilino con acceso de escritura a un recurso HTTPRoute puede inyectar tokens de reglas delimitados por comillas invertidas en el lenguaje de reglas del router de Traefik a través de valores de coincidencia de encabezado o parámetro de consulta no saneados. En implementaciones de pasarela compartida, esto puede eludir las restricciones de nombre de host del oyente y redirigir el tráfico para nombres de host de víctimas a backends controlados por el atacante. Esta vulnerabilidad se corrige en la versión 3.6.10.
  • Vulnerabilidad en Lantronix EDS5000 (CVE-2025-67034)
    Severidad: ALTA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS5000 2.1.0.0R3. Un atacante autenticado puede inyectar comandos del sistema operativo en el parámetro 'name' al eliminar credenciales SSL a través de la interfaz de gestión. Los comandos inyectados se ejecutan con privilegios de root.
  • Vulnerabilidad en Lantronix EDS5000 (CVE-2025-67035)
    Severidad: CRÍTICA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS5000 2.1.0.0R3. Las páginas del Cliente SSH y del Servidor SSH están afectadas por múltiples vulnerabilidades de inyección de sistema operativo debido a la falta de saneamiento de los parámetros de entrada. Un atacante puede inyectar comandos arbitrarios en acciones de eliminación de varios objetos, como claves de servidor, usuarios y hosts conocidos. Los comandos se ejecutan con privilegios de root.
  • Vulnerabilidad en Lantronix EDS5000 (CVE-2025-67036)
    Severidad: ALTA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS5000 2.1.0.0R3. La página Log Info permite a los usuarios ver archivos de registro especificando sus nombres. Debido a una falta de sanitización en el parámetro del nombre de archivo, un atacante autenticado puede inyectar comandos arbitrarios del sistema operativo que se ejecutan con privilegios de root.
  • Vulnerabilidad en Lantronix EDS5000 (CVE-2025-67037)
    Severidad: ALTA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió una vulnerabilidad en Lantronix EDS5000 2.1.0.0R3. Un atacante autenticado puede inyectar comandos del sistema operativo en el parámetro 'tunnel' al finalizar una conexión de túnel. Los comandos inyectados se ejecutan con privilegios de root.
  • Vulnerabilidad en Lantronix EDS5000 (CVE-2025-67038)
    Severidad: CRÍTICA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS5000 2.1.0.0R3. El módulo HTTP RPC ejecuta un comando de shell para escribir registros cuando la autenticación del usuario falla. El nombre de usuario se concatena directamente con el comando sin ninguna sanitización. Esto permite a los atacantes inyectar comandos arbitrarios del sistema operativo en el parámetro de nombre de usuario. Los comandos inyectados se ejecutan con privilegios de root.
  • Vulnerabilidad en Lantronix EDS3000PS (CVE-2025-67039)
    Severidad: CRÍTICA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS3000PS 3.1.0.0R2. La autenticación en las páginas de administración puede ser eludida al añadir un sufijo específico a la URL y al enviar una cabecera de autorización que utiliza 'admin' como nombre de usuario.
  • Vulnerabilidad en Lantronix EDS3000PS (CVE-2025-70082)
    Severidad: CRÍTICA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Un problema en Lantronix EDS3000PS v.3.1.0.0R2 permite a un atacante ejecutar código arbitrario y obtener información sensible a través del componente ltrx_evo.
  • Vulnerabilidad en Lantronix EDS3000PS (CVE-2025-67041)
    Severidad: CRÍTICA
    Fecha de publicación: 11/03/2026
    Fecha de última actualización: 19/03/2026
    Se descubrió un problema en Lantronix EDS3000PS 3.1.0.0R2. El parámetro host del cliente TFTP en la página del navegador de archivos no se sanea correctamente. Esto puede explotarse para escapar del comando original y ejecutar uno arbitrario con privilegios de root.