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-23272)
    Severidad: ALTA
    Fecha de publicación: 20/03/2026
    Fecha de última actualización: 23/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: netfilter: nf_tables: incrementar incondicionalmente set->nelems antes de la inserción En caso de que el conjunto esté lleno, se publica un nuevo elemento que luego se elimina sin esperar el período de gracia de RCU, mientras que un lector de RCU ya puede estar recorriéndolo. Para abordar este problema, añadir la transacción del elemento incluso si el conjunto está lleno, pero alternar la bandera set_full para informar -ENFILE de modo que la ruta de aborto deshaga de forma segura el conjunto a su estado anterior. En cuanto a las actualizaciones de elementos, decrementar set->nelems para restaurarlo. Una solución más simple es llamar a synchronize_rcu() en la ruta de error. Sin embargo, con un gran lote añadiendo elementos a un conjunto ya agotado, esto podría causar una ralentización notable de dichos lotes.
  • Vulnerabilidad en PuTTY (CVE-2026-4115)
    Severidad: BAJA
    Fecha de publicación: 22/03/2026
    Fecha de última actualización: 25/05/2026
    Una vulnerabilidad fue detectada en PuTTY 0.83. Afectada es la función eddsa_verify del archivo crypto/ecc-ssh.c del componente Gestor de Firma Ed25519. La manipulación resulta en verificación impropia de firma criptográfica. El ataque puede ser realizado desde remoto. El ataque requiere un alto nivel de complejidad. La explotabilidad se dice que es difícil. El exploit es ahora público y puede ser usado. La existencia real de esta vulnerabilidad todavía se duda en este momento. El parche se identifica como af996b5ec27ab79bae3882071b9d6acf16044549. Es aconsejable implementar un parche para corregir este problema. El proveedor fue contactado temprano, respondió de manera muy profesional y rápidamente lanzó un parche para el producto afectado. Sin embargo, en este momento no hay prueba de que este fallo pueda tener algún impacto en el mundo real.
  • Vulnerabilidad en Linux (CVE-2026-23296)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 26/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: scsi: core: Corrección de fuga de contador de referencias para tagset_refcnt Esta fuga causará un cuelgue al desmontar el host SCSI. Por ejemplo, iscsid se cuelga con el siguiente rastreo de llamadas: [130120.652718] scsi_alloc_sdev: Fallo de asignación durante el escaneo SCSI, algunos dispositivos SCSI podrían no estar configurados PID: 2528 TAREA: ffff9d0408974e00 CPU: 3 COMANDO: iscsid #0 [ffffb5b9c134b9e0] __schedule at ffffffff860657d4 #1 [ffffb5b9c134ba28] schedule at ffffffff86065c6f #2 [ffffb5b9c134ba40] schedule_timeout at ffffffff86069fb0 #3 [ffffb5b9c134bab0] __wait_for_common at ffffffff8606674f #4 [ffffb5b9c134bb10] scsi_remove_host at ffffffff85bfe84b #5 [ffffb5b9c134bb30] iscsi_sw_tcp_session_destroy at ffffffffc03031c4 [iscsi_tcp] #6 [ffffb5b9c134bb48] iscsi_if_recv_msg at ffffffffc0292692 [scsi_transport_iscsi] #7 [ffffb5b9c134bb98] iscsi_if_rx at ffffffffc02929c2 [scsi_transport_iscsi] #8 [ffffb5b9c134bbf0] netlink_unicast at ffffffff85e551d6 #9 [ffffb5b9c134bc38] netlink_sendmsg at ffffffff85e554ef
  • Vulnerabilidad en Linux (CVE-2026-23311)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 26/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: perf/core: Corrección de contexto de espera inválido en ctx_sched_in() Lockdep encontró un error en la programación de eventos cuando un evento anclado falló y despierta los hilos en el búfer circular como se muestra a continuación. Parece que no debería adquirir un bloqueo de cola de espera bajo el bloqueo de contexto de perf. Hagámoslo con irq_work. [ 39.913691] ============================= [ 39.914157] [ ERROR: Contexto de espera inválido ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 No contaminado [ 39.915271] ----------------------------- [ 39.915731] repro/837 está intentando bloquear: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, en: __wake_up+0x26/0x60 [ 39.917182] otra información que podría ayudarnos a depurar esto: [ 39.917761] contexto-{5:5} [ 39.918079] 4 bloqueos mantenidos por repro/837: [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, en: __perf_event_task_sched_in+0xd1/0xbc0 [ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}, en: __perf_event_task_sched_in+0x1a7/0xbc0 [ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}, en: __perf_event_task_sched_in+0x1f9/0xbc0 [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, en: perf_event_wakeup+0x6c/0x470
  • Vulnerabilidad en Linux (CVE-2026-23312)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 26/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: net: usb: kaweth: validar los puntos finales USB El controlador kaweth debería validar que el dispositivo que está sondeando tiene el número y los tipos adecuados de puntos finales USB que espera antes de vincularse a él. Si un dispositivo malicioso no tuviera los mismos urbs, el controlador se bloqueará más adelante cuando acceda ciegamente a estos puntos finales.
  • Vulnerabilidad en Linux (CVE-2026-23313)
    Severidad: MEDIA
    Fecha de publicación: 25/03/2026
    Fecha de última actualización: 26/05/2026
    En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: i40e: Solución a la fuga del contador de preemption en el tracepoint de sondeo de napi Usar get_cpu() en la asignación del tracepoint causa una fuga obvia del contador de preemption porque nada invoca put_cpu() para deshacerlo: 'softirq: eh, entró en softirq 3 NET_RX con preempt_count 00000100, salió con 00000101?' Esto claramente ha sido sometido a muchas pruebas en los últimos 3+ años... Usar smp_processor_id() en su lugar.