Tres vulnerabilidades Linux explotadas han sido incorporadas al catálogo Known Exploited Vulnerabilities (KEV) de la agencia estadounidense CISA después de existir evidencias de explotación activa.
Los fallos afectan al kernel de Linux, la parte central del sistema operativo encargada de gestionar procesos, memoria, dispositivos, red y permisos.
Las vulnerabilidades son:
- CVE-2025-39682
- CVE-2026-53266
- CVE-2025-39964
CISA incorporó las tres al catálogo KEV el 18 de septiembre de 2026 y estableció el 21 de septiembre de 2026 como fecha de remediación para los sistemas federales estadounidenses sujetos a su directiva.
Este dato cambia significativamente su prioridad.
No hablamos únicamente de vulnerabilidades teóricas descubiertas en el código.
Hablamos de:
fallos conocidos + correcciones disponibles + evidencia de explotación real.
Por tanto, cualquier empresa que utilice servidores Linux debería revisar si sus distribuciones y kernels se encuentran dentro de los rangos afectados.
¿Qué significa que existan vulnerabilidades Linux explotadas?
Una vulnerabilidad puede publicarse durante meses sin que exista evidencia conocida de explotación.
Sin embargo, cuando CISA la incorpora a su catálogo KEV significa que dispone de evidencia suficiente para considerarla explotada en condiciones reales.
El catálogo KEV se utiliza precisamente para ayudar a priorizar vulnerabilidades que ya no son únicamente posibilidades técnicas.
Por eso existe una diferencia importante entre:
CVE publicada
y:
CVE explotada.
La primera necesita evaluación.
La segunda normalmente requiere una prioridad superior.
Vulnerabilidades Linux explotadas: por qué importa el kernel
El kernel se encuentra en el núcleo del sistema operativo.
Entre otras funciones, controla:
- memoria;
- procesos;
- dispositivos;
- comunicaciones;
- acceso al hardware;
- aislamiento;
- privilegios.
Por ello, una vulnerabilidad en esta capa puede tener consecuencias importantes.
Además, Linux está presente en una gran cantidad de infraestructuras empresariales:
- servidores web;
- hosting;
- bases de datos;
- sistemas de backup;
- firewalls;
- appliances;
- plataformas de virtualización;
- contenedores;
- NAS;
- servicios cloud.
Por tanto, el problema no afecta únicamente a organizaciones que administran explícitamente un servidor denominado “Linux”.
Muchas plataformas empresariales utilizan Linux internamente.
Vulnerabilidades Linux explotadas: CVE-2025-39682
CVE-2025-39682 afecta al manejo de determinados registros TLS dentro del kernel de Linux.
El problema está relacionado con la forma en la que el kernel procesa ciertos registros de longitud cero en la ruta de recepción TLS.
El registro oficial de CVE indica que el fallo fue corregido en distintas ramas estables del kernel, incluyendo versiones específicas de las ramas 6.1, 6.6, 6.12 y 6.16.
CISA incorporó esta vulnerabilidad al catálogo KEV el 18 de septiembre de 2026 debido a evidencia de explotación.
En consecuencia, las empresas deberían comprobar la versión distribuida por su fabricante y no limitarse únicamente a comparar el número de kernel genérico.
¿Qué riesgo presenta CVE-2025-39682?
La vulnerabilidad está relacionada con el procesamiento de TLS dentro del kernel.
Dependiendo del entorno y de la implementación concreta, un atacante con las condiciones necesarias podría provocar comportamientos anómalos relacionados con memoria o disponibilidad.
Sin embargo, es importante evitar una interpretación incorrecta:
estar conectado a Internet no significa automáticamente ser explotable remotamente mediante CVE-2025-39682.
Las condiciones exactas dependen de:
- kernel;
- distribución;
- configuración;
- funcionalidad utilizada;
- correcciones aplicadas.
Por ello, la referencia correcta debe ser siempre el boletín del fabricante de la distribución utilizada.
Vulnerabilidades Linux explotadas: CVE-2026-53266
La segunda vulnerabilidad es CVE-2026-53266.
El fallo afecta al subsistema Netfilter / ebtables, concretamente al tratamiento de reglas SNAT que modifican direcciones hardware ARP.
Red Hat explica que el problema puede permitir modificar memoria de forma incorrecta y provocar:
- corrupción de memoria;
- comportamiento inesperado;
- denegación de servicio;
- potencial escalada de privilegios.
Además, para que sea aplicable deben existir determinadas configuraciones de bridge networking y reglas específicas de ebtables.
Este detalle es importante.
No todos los servidores Linux presentan exactamente el mismo nivel de exposición.
Vulnerabilidades Linux explotadas y entornos virtualizados
CVE-2026-53266 resulta especialmente interesante para infraestructuras que utilizan:
- bridge networking;
- virtualización;
- contenedores;
- ebtables;
- configuraciones avanzadas de red.
Red Hat señala precisamente que este tipo de configuraciones puede aparecer en entornos virtualizados y contenerizados.
Por tanto, la primera pregunta debería ser:
¿tenemos sistemas afectados por esta configuración?
Después:
¿están parcheados?
Y, finalmente:
¿tenemos evidencias de actividad anómala previa?
Vulnerabilidades Linux explotadas: CVE-2025-39964
La tercera vulnerabilidad es CVE-2025-39964.
Se trata de una condición de carrera en la API criptográfica AF_ALG del kernel.
El problema aparece cuando se producen escrituras concurrentes sobre el mismo socket.
Eso puede provocar que los datos se intercalen de forma impredecible y que el estado interno del socket quede inconsistente.
CISA también añadió esta vulnerabilidad al catálogo KEV el 18 de septiembre de 2026.
Por tanto, aunque sus condiciones de explotación sean locales, debemos considerarla dentro de una posible cadena de ataque.
Una vulnerabilidad local también puede ser peligrosa
Este concepto genera mucha confusión.
Cuando una vulnerabilidad requiere acceso local, algunas organizaciones concluyen:
“entonces no nos afecta porque el servidor no está abierto a Internet”.
Pero un ataque moderno puede desarrollarse por fases:
1. acceso inicial
↓
2. ejecución con privilegios reducidos
↓
3. explotación de vulnerabilidad local
↓
4. escalada de privilegios
↓
5. persistencia o movimiento lateral
Por tanto, una vulnerabilidad local puede ser extremadamente útil para un atacante que ya consiguió entrar mediante otro mecanismo.
Vulnerabilidades Linux explotadas: no sabemos si forman una misma cadena
Actualmente no existe información pública suficiente para afirmar que las tres vulnerabilidades estén siendo utilizadas por:
el mismo atacante
o:
dentro de la misma campaña.
Tampoco se han publicado detalles completos sobre los incidentes concretos que llevaron a CISA a incluirlas en KEV.
Por eso debemos evitar titulares como:
“hackers están combinando estas tres vulnerabilidades para tomar servidores Linux”.
No existe evidencia pública suficiente para afirmar eso.
Lo confirmado es más concreto:
CISA considera que cada una presenta evidencia de explotación activa.
CVSS no debe ser el único criterio
Las puntuaciones CVSS publicadas pueden variar entre bases de datos y fabricantes.
Por ejemplo, Red Hat asigna a CVE-2026-53266 una valoración diferente de la publicada por otras fuentes debido a cómo afecta específicamente a sus productos.
Esto es normal.
Un mismo CVE puede tener distinto impacto dependiendo de:
- distribución;
- compilación;
- configuración;
- funcionalidad;
- mitigaciones.
Por eso, para priorizar correctamente debemos combinar:
CVSS + explotación conocida + exposición + criticidad del activo + configuración.
Y en este caso existe un factor especialmente importante:
están en CISA KEV.
Vulnerabilidades Linux explotadas: qué debe hacer una empresa
El orden recomendado es:
inventariar → comprobar → actualizar → verificar → investigar.
No basta con instalar actualizaciones de forma automática y asumir que todo está resuelto.
Primero necesitamos saber qué sistemas existen.
1. Identificar todos los sistemas Linux
La empresa debería disponer de un inventario de:
- servidores físicos;
- máquinas virtuales;
- servidores cloud;
- hosting;
- Docker hosts;
- Kubernetes;
- NAS;
- appliances;
- sistemas de backup.
Además, debemos incluir infraestructura gestionada por proveedores.
Porque un servidor administrado por un tercero sigue formando parte de nuestra superficie de riesgo.
Vulnerabilidades Linux explotadas: comprobar distribución y kernel
En Linux no resulta aconsejable decidir únicamente basándonos en:
“mi kernel parece antiguo”.
Distribuciones como:
- Red Hat;
- Ubuntu;
- Debian;
- SUSE;
pueden aplicar backports de seguridad.
Esto significa que mantienen una versión aparentemente antigua pero incorporan el parche internamente.
Red Hat advierte expresamente de que algunos escáneres pueden detectar falsos positivos cuando comparan únicamente números de versión y no tienen en cuenta correcciones backportadas.
Por tanto, debemos comprobar:
boletín del fabricante + paquete instalado + actualización disponible.
2. Aplicar actualizaciones de seguridad
Si el fabricante indica que el sistema está afectado, debemos aplicar la actualización correspondiente.
Red Hat recomienda mantener instaladas las últimas actualizaciones y security updates disponibles para las versiones soportadas.
Además, cuando existe explotación activa, el plazo de mantenimiento debería reducirse.
No resulta adecuado tratar una vulnerabilidad KEV como:
“lo actualizaremos el mes que viene”.
Debe evaluarse con prioridad.
Vulnerabilidades Linux explotadas y reinicio del kernel
En muchas distribuciones, actualizar el paquete del kernel no significa que el nuevo kernel esté siendo utilizado inmediatamente.
Puede ser necesario:
reiniciar el servidor.
Por eso debemos comprobar:
- paquete actualizado;
- kernel instalado;
- kernel actualmente cargado.
Un servidor puede tener el parche instalado en disco pero continuar ejecutando el kernel vulnerable hasta el siguiente reinicio.
3. Verificar después de actualizar
Después del mantenimiento debemos comprobar:
- versión activa;
- servicios;
- aplicaciones;
- red;
- backups;
- rendimiento.
Porque una buena gestión de vulnerabilidades no termina con:
“apt update”
o:
“dnf update”.
Termina con:
actualización verificada y servicio operativo.
Vulnerabilidades Linux explotadas: actualizar no responde a todo
Existe una segunda pregunta.
Si la vulnerabilidad estaba presente durante meses:
¿pudo ser explotada antes?
Actualizar responde:
“¿seguimos vulnerables ahora?”
Pero no responde:
“¿alguien la explotó ayer?”
Por eso, cuando aparece una vulnerabilidad dentro de CISA KEV, puede resultar necesario realizar una investigación retrospectiva.
4. Revisar logs de autenticación
Entre otras fuentes conviene revisar:
- SSH;
- sudo;
- PAM;
- usuarios;
- sesiones;
- accesos remotos.
Debemos buscar patrones como:
- usuarios inesperados;
- accesos fuera de horario;
- orígenes desconocidos;
- múltiples intentos;
- cambios de privilegios.
Sin embargo, un acceso desde una IP desconocida no demuestra por sí solo una intrusión.
Siempre necesitamos contexto.
5. Revisar cambios de privilegios
Como algunas de estas vulnerabilidades pueden participar en escenarios de escalada de privilegios, debemos prestar atención a:
- sudo;
- cambios de grupos;
- cuentas administrativas;
- UID 0;
- permisos;
- claves SSH.
También conviene revisar modificaciones no autorizadas en:
/etc/passwd/etc/shadow/etc/sudoersauthorized_keys
No significa que cualquier cambio sea malicioso.
Pero sí debe poder explicarse.
Vulnerabilidades Linux explotadas y persistencia
Un atacante que obtiene privilegios elevados puede intentar permanecer en el sistema.
Por ejemplo mediante:
- cron;
- systemd;
- scripts;
- usuarios;
- claves SSH;
- servicios nuevos.
Por tanto, también conviene revisar:
qué apareció
y:
cuándo apareció.
Aquí el histórico de eventos resulta fundamental.
6. Revisar procesos y conexiones
Asimismo, debemos buscar:
- procesos anómalos;
- binarios desconocidos;
- conexiones salientes inesperadas;
- cambios en servicios;
- actividad posterior a accesos sospechosos.
Sin embargo, debemos evitar otra simplificación:
conexión a una IP externa ≠ ataque confirmado.
Linux genera gran cantidad de comunicaciones legítimas.
El valor está en correlacionar.
Vulnerabilidades Linux explotadas y SIEM Wazuh
Un SIEM Wazuh para empresas permite centralizar eventos procedentes de diferentes sistemas.
Por ejemplo:
- Linux;
- Windows;
- macOS;
- servidores;
- NAS;
- SonicWall;
- UniFi;
- Microsoft 365;
- Endpoint.
Esto permite relacionar señales.
Por ejemplo:
Firewall → nueva conexión
↓
Linux → inicio de sesión
↓
Linux → ejecución con privilegios
↓
Servidor → nuevo proceso
Una de esas señales por separado puede ser legítima.
Sin embargo, juntas pueden requerir investigación.
Nuestro SOC analiza las vulnerabilidades Linux explotadas en contexto
Wazuh es la plataforma.
El análisis corresponde a nuestro SOC.
Nuestro modelo es:
sistema genera eventos
↓
SIEM centraliza y correlaciona
↓
SOC analiza
↓
se comunica aquello que requiere atención
Esto es especialmente importante cuando tratamos vulnerabilidades explotadas.
Porque una alerta automática puede decir:
“actividad potencialmente anómala”.
Pero necesitamos determinar:
qué usuario
qué servidor
qué proceso
qué ocurrió antes
qué ocurrió después.
Hasta 400 días de histórico para investigar
Una vulnerabilidad puede incluirse hoy en KEV aunque llevara tiempo presente.
Por tanto, puede interesarnos buscar actividad anterior.
En nuestros servicios podemos conservar hasta 400 días de histórico de logs de las fuentes integradas.
Esto facilita preguntas como:
¿cuándo apareció este usuario?
¿esta IP se conectó anteriormente?
¿este proceso ya se había ejecutado?
¿hubo actividad privilegiada meses atrás?
Ese tipo de investigación retrospectiva puede ser fundamental.
Vulnerabilidades Linux explotadas: el parche protege el futuro, los logs explican el pasado
Esta diferencia merece destacarse.
Parchar sirve principalmente para cerrar la vulnerabilidad.
Investigar logs sirve para determinar si existe evidencia de utilización anterior.
Por tanto:
actualización + investigación
pueden ser necesarias cuando hablamos de vulnerabilidades explotadas.
Una no sustituye a la otra.
Los backups también deben revisarse
Si un servidor Linux es crítico, también debemos comprobar:
- última copia correcta;
- retención;
- copia externa;
- capacidad de restauración.
Porque una escalada de privilegios puede permitir alterar muchos elementos del servidor.
Además, durante una incidencia podríamos necesitar restaurar información.
Por eso recomendamos probar periódicamente la recuperación y no confiar únicamente en el mensaje:
“backup finalizado correctamente”.
Vulnerabilidades Linux explotadas y mínimo privilegio
Las vulnerabilidades locales recuerdan la importancia del principio de:
mínimo privilegio.
Un usuario o servicio debería tener únicamente los permisos necesarios.
Si una aplicación no necesita root:
no debería ejecutarse como root.
Si un técnico solo necesita administrar un servicio:
no necesita acceso total a toda la infraestructura.
Cuanto menor sea el privilegio inicial, más barreras encuentra un atacante.
MFA también importa en Linux
MFA no corrige una vulnerabilidad del kernel.
Sin embargo, puede ayudar a reducir otras vías de acceso inicial.
Por ejemplo:
- VPN;
- panel de administración;
- acceso remoto;
- consola cloud.
La ciberseguridad funciona por capas.
Por eso:
MFA + parches + firewall + Endpoint + SIEM
son complementarios.
Firewall y vulnerabilidades Linux explotadas
Un firewall tampoco corrige CVE-2025-39682, CVE-2026-53266 o CVE-2025-39964.
Sin embargo, puede reducir superficie de ataque.
Conviene revisar:
- servicios expuestos;
- puertos;
- reglas;
- NAT;
- accesos administrativos.
Una regla que dejó de ser necesaria hace tres años no debería seguir abierta únicamente porque nadie la revisó.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
¿Afectan estas vulnerabilidades Linux explotadas a todos los servidores?
No.
Que una vulnerabilidad afecte al kernel Linux no significa que:
todos los Linux del mundo sean vulnerables.
Depende de:
- versión;
- distribución;
- backport;
- configuración;
- funcionalidades;
- arquitectura.
Por eso la respuesta correcta no es:
“tenemos Linux, estamos afectados”.
La respuesta correcta es:
“vamos a comprobar si nuestra distribución y configuración concreta están afectadas”.
Qué debe preguntar una empresa a su proveedor
Si un proveedor administra el servidor, podemos preguntar:
¿Estamos afectados por CVE-2025-39682?
¿Estamos afectados por CVE-2026-53266?
¿Estamos afectados por CVE-2025-39964?
¿Cuándo se instalaron las correcciones?
¿Fue necesario reiniciar?
¿Se verificó el kernel activo?
¿Se han revisado logs anteriores?
Una respuesta como:
“nosotros actualizamos siempre”
es menos útil que:
“estos sistemas no están afectados / estos fueron parcheados en esta fecha”.
Vulnerabilidades Linux explotadas y software sin soporte
También debemos prestar atención a sistemas fuera de soporte.
Un servidor antiguo puede no recibir:
- parches;
- actualizaciones;
- correcciones.
Red Hat advierte de que las versiones fuera de su ciclo soportado pueden permanecer expuestas a vulnerabilidades sin solución disponible.
Por tanto, mantener sistemas EOL aumenta el riesgo.
No basta con instalar antivirus encima.
CISA KEV como herramienta de priorización
Cada empresa puede tener cientos o miles de CVE pendientes.
Resulta prácticamente imposible tratar todas con la misma urgencia.
Por eso KEV puede utilizarse como una señal de priorización:
¿está explotada?
Después debemos añadir nuestro propio contexto:
¿nos afecta?
¿está expuesta?
¿qué activo protege?
¿qué impacto tendría?
Ese enfoque es más útil que ordenar únicamente por CVSS.
Vulnerabilidades Linux explotadas y gestión profesional
La gestión de vulnerabilidades debería seguir un ciclo:
inventario
↓
detección
↓
priorización
↓
parcheo
↓
verificación
↓
monitorización
↓
investigación cuando sea necesaria
No debería consistir en:
leer una noticia y actualizar un servidor al azar.
Necesitamos saber qué activos existen y cuáles están realmente afectados.
¿Qué debe revisar una pyme?
Aunque las vulnerabilidades del kernel puedan parecer un asunto exclusivo de grandes centros de datos, una pyme puede utilizar Linux sin saberlo.
Por ejemplo:
- servidor web;
- NAS;
- appliance;
- ERP;
- hosting;
- central de backup;
- servicios cloud.
Por eso conviene consultar con el proveedor responsable.
Especialmente cuando se trata de sistemas que contienen:
- datos de clientes;
- documentación;
- copias;
- servicios web.
Vulnerabilidades Linux explotadas: lista práctica de revisión
Para simplificar, recomendamos comprobar:
1. Inventario
¿Qué sistemas Linux tenemos?
2. Distribución
¿Ubuntu, Debian, Red Hat, SUSE u otra?
3. Kernel
¿Qué kernel está realmente cargado?
4. Aviso del fabricante
¿Nuestra versión está afectada?
5. Parches
¿Existe actualización instalada?
6. Reinicio
¿El nuevo kernel está en ejecución?
7. Accesos
¿Hay autenticaciones anómalas?
8. Privilegios
¿Existen cambios inesperados?
9. Persistencia
¿Hay tareas, usuarios o servicios nuevos?
10. Histórico
¿Tenemos logs suficientes para investigar?
¿Hay que apagar inmediatamente los servidores?
No necesariamente.
La respuesta debe depender de:
- exposición;
- criticidad;
- fabricante;
- parche disponible;
- posibilidad de mantenimiento.
En muchos casos la acción correcta será:
planificar un parche urgente y controlado.
Detener un sistema crítico sin análisis también puede provocar impacto.
La gestión del riesgo consiste precisamente en equilibrar:
seguridad + continuidad.
Otras vulnerabilidades recientes del kernel
Durante 2026 también se han divulgado otros fallos de escalada local de privilegios en Linux.
Sin embargo, no debemos mezclarlos automáticamente con estas tres vulnerabilidades.
El hecho de que existan otras CVE o exploits públicos no demuestra que formen parte de las campañas que motivaron la inclusión actual en KEV.
Por tanto, conviene tratar cada vulnerabilidad según:
evidencia + producto + exposición + contexto.
Vulnerabilidades Linux explotadas: conclusión
Las tres vulnerabilidades Linux explotadas incorporadas por CISA a KEV el 18 de septiembre de 2026 requieren una revisión prioritaria:
CVE-2025-39682
CVE-2026-53266
CVE-2025-39964
CISA las considera vulnerabilidades con evidencia de explotación y estableció el 21 de septiembre como fecha de remediación para los sistemas federales incluidos en su directiva.
Sin embargo, esto no significa que cualquier servidor Linux sea automáticamente vulnerable o esté comprometido.
El proceso correcto es:
1. identificar el sistema
2. comprobar el fabricante
3. determinar si está afectado
4. instalar el parche
5. verificar el kernel activo
6. revisar actividad anterior cuando proceda
Además, cuando una vulnerabilidad ya se está explotando, debemos recordar una diferencia fundamental:
parchear nos protege hacia adelante.
Pero:
los logs nos ayudan a investigar hacia atrás.
En GHM Soluciones Informáticas trabajamos con:
🖥️ servidores Linux
🔥 firewall administrado
💻 Endpoint / EDR
📊 SIEM Wazuh
🔎 análisis SOC
🗄️ hasta 400 días de histórico de logs
💾 backup y continuidad
Puede conocer nuestras soluciones de ciberseguridad para empresas.
Porque ante vulnerabilidades Linux explotadas, la pregunta no debería limitarse a:
“¿hemos instalado el parche?”
También debería ser:
“¿podemos demostrar qué ocurrió antes de instalarlo?”
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre vulnerabilidades Linux explotadas
¿Qué vulnerabilidades Linux explotadas ha señalado CISA?
CVE-2025-39682, CVE-2026-53266 y CVE-2025-39964 fueron incorporadas al catálogo KEV el 18 de septiembre de 2026.
¿Qué significa aparecer en CISA KEV?
Significa que CISA dispone de evidencia que justifica considerar la vulnerabilidad explotada en condiciones reales.
¿Las tres vulnerabilidades afectan al kernel Linux?
Sí. Las tres están relacionadas con distintos componentes del kernel Linux.
¿Todos los servidores Linux están afectados?
No. Depende de la versión, distribución, backports, configuración y componentes utilizados.
¿CVE-2026-53266 afecta a Netfilter?
Sí. Está relacionada con ebtables SNAT y determinadas operaciones ARP.
¿Qué es CVE-2025-39964?
Es una condición de carrera relacionada con escrituras concurrentes sobre sockets AF_ALG de la API criptográfica del kernel.
¿Qué es CVE-2025-39682?
Es un fallo relacionado con el procesamiento de determinados registros TLS dentro del kernel Linux.
¿Son vulnerabilidades remotas?
Las condiciones dependen de cada CVE. Varias requieren acceso local o circunstancias específicas, por lo que no deben interpretarse como tres vulnerabilidades remotas universales sin autenticación.
¿Por qué son importantes si requieren acceso local?
Porque pueden utilizarse después de que un atacante haya conseguido un primer acceso con privilegios reducidos.
¿Las tres vulnerabilidades forman una misma cadena de ataque?
No existe información pública suficiente para afirmarlo.
¿Hay que actualizar Linux?
Si el fabricante de nuestra distribución confirma que estamos afectados, debemos aplicar las actualizaciones correspondientes con prioridad.
¿Es suficiente actualizar paquetes?
No siempre. Si se actualiza el kernel, puede ser necesario reiniciar para comenzar a utilizar la versión corregida.
¿Cómo saber qué kernel está activo?
Debe comprobarse el kernel actualmente cargado después del mantenimiento y compararlo con las recomendaciones del fabricante.
¿Por qué el número de versión puede engañar?
Porque algunas distribuciones aplican backports de seguridad sin cambiar al número de versión principal más reciente.
¿CVSS es suficiente para priorizar?
No. También deben considerarse explotación conocida, exposición, criticidad y configuración.
¿Qué aporta el catálogo CISA KEV?
Ayuda a identificar vulnerabilidades para las que existe evidencia de explotación conocida y, por tanto, puede utilizarse como señal de priorización.
¿Actualizar demuestra que no hubo compromiso?
No. El parche corrige el fallo, pero no demuestra que no haya sido explotado anteriormente.
¿Qué logs deberían revisarse?
Según el entorno: autenticaciones, SSH, sudo, procesos, usuarios, servicios, firewall y otros registros relevantes.
¿Qué aporta SIEM Wazuh?
Centraliza logs, permite aplicar reglas y facilita correlaciones entre diferentes sistemas.
¿Qué aporta un SOC?
Nuestro SOC analiza los eventos y su contexto para determinar cuáles son legítimos, sospechosos o necesitan actuación.
¿Por qué conservar hasta 400 días de logs?
Porque algunas vulnerabilidades se reconocen como explotadas mucho después de haberse publicado y puede ser necesario investigar actividad histórica.
¿Cuál es la principal recomendación ante estas vulnerabilidades Linux explotadas?
Comprobar si los sistemas están afectados, parchearlos con prioridad y conservar suficiente visibilidad para investigar actividad anterior.
Imagen recomendada: servidor Linux empresarial con kernel, consola de seguridad y aviso de vulnerabilidades explotadas, evitando representar una intrusión como confirmada.
Catálogo Known Exploited Vulnerabilities de CISA
CVE-2025-39682 en CVE.org
CVE-2026-53266 en Red Hat
Información de seguridad de Red Hat
