Herramientas AI: cómo manejar la avalancha de vulnerabilidades en Linux

El 20 de octubre, el proyecto curl publicó algo que parece una nota de mantenimiento y en realidad es un aviso de peso. A partir del 26 de ese mes, todos los reportes de vulnerabilidad que el equipo considerara de severidad baja o media dejan de pasar por el canal privado de HackerOne y se publican directamente como issues en su repositorio de GitHub. Solo las de severidad alta y crítica siguen guardadas en secreto hasta que hay un parche listo.

La razón que dan los mantenedores en su blog es una sola palabra: avalancha. Y no es una exageración retórica. Cuando una IA puede recorrer el código de tu proyecto en minutos y devolverte una lista de hallazgos, el cuello de botella deja de estar en el descubrimiento y se mueve al lado contrario, el de validar, decidir y reparar. Ese es el punto donde se rompe el equilibrio entre quien reporta y quien mantiene, y donde se decide si un proyecto open source sobrevive o se quema.

Esto ya dejó de ser teórico. En 2026, un investigador de Anthropic encontró con Claude Code un fallo de desbordamiento en el servidor NFS del kernel de Linux que llevaba más de dos décadas sin que nadie lo reportara. En la misma línea de trabajo, el proyecto curl cambió su forma de reportar. Y hay una iniciativa de la Linux Foundation para organizar la respuesta: Akrites, lanzada en junio de 2026 con un equipo de respuesta a incidentes compartido y un proceso único de divulgación coordinada para los proyectos open source críticos. Este post es sobre qué significa todo eso para ti que tienes dos o tres servidores y un horario de mantenimiento, no sobre inteligencia artificial en abstracto.

Qué es la avalancha y por qué no la vas a resolver parcheando

El 25 de octubre, Red Hat publicó un análisis de este momento que usa el término Vulnpocalypse, y describe una situación muy concreta: la IA encuentra fallos más rápido de lo que los equipos alcanzan a evaluar y arreglar. En su blog sobre divulgación responsable, Red Hat lo describe así: el descubrimiento es solo el primer paso, y el resto, validar el hallazgo, medir su impacto real, producir una corrección confiable y guiar al operador, eso lo hacen todavía personas.

El dato duro está en la estadística que curl publica sobre su propio proceso. En los últimos años, más del 90% de los envíos recibidos podían clasificarse rápidamente como de severidad inferior a alta. Es decir: la enorme mayoría de los reportes que llegan no son emergencias, pero llegan todos, y cada uno requiere atención de un humano para confirmarse, clasificar y descartar. Ese es el trabajo que no escala.

Y hay un efecto de perverseidad que el propio Dan Stenberg describe en su blog: cuando el proyecto anuncia un conjunto nuevo de CVE y sus correcciones, aparece un ejército de investigadores que usan IA y lanza esos insumos contra sus propios modelos para buscar errores similares u omisiones en el arreglo. Publicar el fix se convierte en el generador de la siguiente ola de reportes. Una política que parecía razonable para cada reporte individual termina amplificando el problema colectivo.

El caso del kernel: 23 años de código que nadie había revisado

Para entender la escala real hay que mirar el caso más concreto del año. En la conferencia [un]prompted 2026, Nicholas Carlini, investigador de Anthropic, mostró que había usado Claude Code para encontrar varios desbordamientos de heap explotables de forma remota en el kernel de Linux. Uno de ellos llevaba 23 años oculto en el código, introducido en 2003, y que ningún humano había reportado en más de dos décadas de revisión.

El fallo está en el servidor NFS. Cuando un cliente NFS recibe un bloqueo denegado, el kernel construye la respuesta en un búfer estático de 112 bytes, pero el mensaje de error puede ocupar hasta 1056 bytes. La diferencia se escribe directamente sobre memoria del kernel y el atacante controla parte de esos bytes a través del identificador de propietario del bloqueo, que es un valor de hasta 1024 bytes.

Lo interesante para tu servidor no es el exploit, es el método. Carlini describe un guion simple que recorre cada archivo del código fuente y le pide al modelo que busque un fallo en ese archivo. Y su propia evaluación del resultado es la frase más útil de toda la historia para un sysadmin: tiene centenares de fallos más en el kernel que no puede reportar porque todavía no los ha validado. Dice que no va a enviar basura potencial a los mantenedores. O sea: el hallazgo de la IA es el primer filtro, no el veredicto.

Red Hat evaluó los cinco problemas que salieron de ese trabajo y el resultado es la parte que casi nadie cita. El fallo de NFS lo calificaron como bajo en su ecosistema, porque el servicio no está expuesto fuera de la red interna por defecto y el peor caso es una caída del demonio, una denegación de servicio. El de io_uring lo descartaron explícitamente como problema de funcionalidad y estabilidad, no de seguridad. Uno de los dos de ksmbd quedó en moderado y el otro en bajo, con la recomendación de no usar compartir archivos de red en el kernel si los usuarios no son de confianza. O sea: cinco hallazgos seriousness de una IA, y para un servidor típico ninguno de los cinco era una urgencia.

Priorizar por exposición real en lugar de por número de CVE

Este es el cambio de fondo que te afecta. Si la oferta de hallazgos se multiplica, la única variable que puedes controlar es cuál de ellos te toca. Y esa decisión se toma con tres preguntas muy concretas: ¿está explotado en la wild?, ¿la probabilidad de explotación es alta?, y ¿tienes el componente afectado expuesto?

La primera pregunta tiene una respuesta pública y actualizada a diario. FIRST publica el sistema de puntuación EPSS, que estima la probabilidad de que un CVE publicado sea explotado en la wild en los próximos 30 días. Es un dato cuantitativo que te permite ordenar tu backlog de parches sin depender del CVSS, que como bien señalan los propios mantenedores de curl no usan porque lo consideran un sistema roto.

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2026-92392,CVE-2021-44228"

La consulta devuelve una línea por CVE con la probabilidad de explotación y su percentil. Para comparar: CVE-2026-92392, un use-after-free de carga HTTP/2 en curl que la versión corregida de tu distribución ya trae, y CVE-2021-44228, el Log4Shell. Para el primero la probabilidad de explotación es del 1,3%, mientras que el Log4Shell llega al 99,999%. Tu backlog no debería tratar esos dos igual, aunque ambos aparezcan en el mismo listado de tu gestor de actualizaciones.

La segunda fuente es el catálogo KEV de CISA, que lista las vulnerabilidades con explotación confirmada. No es una opinión: es un registro. A fecha de 27 de octubre de 2026 el catálogo tiene 1760 entradas y se actualiza a diario, así que consultarlo es la forma más barata de saber qué está explotado de verdad.

curl -s https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json -o /tmp/kev.json
python3 -c "import json; d=json.load(open('/tmp/kev.json')); print(d['count'], 'vulnerabilidades en KEV')"

Si tu CVE aparece ahí, no es una fila más de una tabla, es un incidente esperando. Y si no aparece, no te salva: KEV solo registra lo que CISA ha visto explotado. Por eso EPSS y KEV se complementan, uno estima probabilidad y el otro registra hechos.

Revisar qué componentes corres de verdad, no los que en teoría tienes

El error más común que veo en los equipos que reciben una lista grande de hallazgos es parchar por volumen. La pregunta correcta es más aburrida y más útil: ¿el servicio vulnerable está corriendo en mi máquina y está expuesto a la red?

En el caso de los cinco hallazgos del kernel, Red Hat lo resolvió mirando exactamente eso. El demonio NFS no está expuesto fuera de la red interna por defecto, así que el impacto real cae. La lección para tu homelab es directa: antes de abrir un ticket de parche, mira qué demonios tienes levantados.

systemctl list-units --type=service --state=running | grep -Ei "nfs|smb"

Si la respuesta es vacía, ese camino de ataque no existe en tu máquina y puedes seguir con el siguiente. Y para lo que sí corres, hay una segunda comprobación que vale la pena: el registro de cambios del paquete instalado te dice qué CVE ya están corregidos en la versión que tienes, sin depender de que el gestor de actualizaciones te haya avisado.

apt-get changelog curl | grep -iE "CVE-[0-9]{4}-[0-9]+" | head -5

Esto es útil porque muchas veces estás actualizado y no lo sabes. La versión instalada de curl en mi máquina es la 8.14.1-2+deb13u7, y su registro de cambios ya recoge el arreglo de CVE-2026-92392. Ese CVE no lo toco porque ya está dentro. Descubrir eso en cinco segundos te ahorra una ventana de mantenimiento completa.

Escanear tus dependencias sin instalar un agente de IA en tu servidor

Hay una tentación razonable aquí: si la IA encuentra fallos, ¿por qué no usar IA para encontrarlos a ti? La respuesta honesta es que las herramientas de escaneo deterministas siguen siendo mejores para el trabajo mecánico de inventario, y son mucho más baratas de correr. La IA aporta valor en el análisis, no en la lectura de listas de dependencias.

El escáner de OSV es la opción más directa para lo que te importa: leer tu archivo de bloqueo de dependencias y cruzarlo contra la base de datos pública de vulnerabilidades, sin instalar nada en el sistema. Se ejecuta en un contenedor, así que no dejasBinarios en tu servidor.

docker run --rm -v "$PWD":/src ghcr.io/google/osv-scanner:latest scan source --format=vertical --verbosity=error --recursive /src

Lo probé contra un archivo de bloqueo de ejemplo con una versión antigua de lodash y devolvió seis vulnerabilidades conocidas con su versión mínima de corrección. Es exactamente el tipo de salida que te sirve para decidir: esta dependencia está en 4.17.15 y el arreglo empieza en 4.17.21, así que el trabajo es actualizar, no investigar.

Para imágenes de contenedor, Trivy hace lo mismo pero sobre el sistema de archivos de la imagen, y ahí el hallazgo típico no está en tu código sino en la base.

docker run --rm aquasec/trivy:0.67.2 image --scanners vuln --severity HIGH,CRITICAL alpine:3.19

La salida que me devolvió es un recordatorio de por qué el escaneo de imágenes importa: la imagen mínima de Alpine arrastra una vulnerabilidad alta en musl, la librería base, que no aparece en ninguna de las dependencias que tú escribiste. Tú no la instalaste, pero ahí está, y en el momento del arranque.

Lo que cambia en tu día a día, en concreto

Todo lo anterior suena a política de empresa grande, pero te afecta de formas bastante específicas.

La primera es que el volumen de alertas deja de ser una métrica. Si tu panel de seguridad te dice que tienes 400 vulnerabilidades abiertas, ese número no te dice nada sobre tu riesgo. El número que importa es cuántos de tus servicios expuestos tienen un fallo con explotación probable. Esa es una pregunta distinta y la puedes responder.

La segunda es que la ventana de embargo se está acortando, y eso te afecta aunque no reportes vulnerabilidades. Red Hat define el embargo como una ventaja táctica para quien defiende: tiempo corto y definido para preparar la defensa. Cuando un proyecto como curl pasa a publicar en abierto las severidades media y baja, ese tiempo desaparece para esos casos, y con él la sorpresa para quien pensaba explotarlas. En el blog de curl, el propio equipo reconoce el riesgo: dar a los malos una ventana ligeramente más larga para explotar debilidades a cambio de los usuarios existentes.

La tercera es que si tú encuentras algo, el proceso de reporte importa más que el hallazgo. El proyecto curl tiene una política estricta: no acepta reportes por correo electrónico, todo va por su rastreador, y desde octubre de 2026 los casos de severidad baja y media van por GitHub. La razón de fondo es la que Red Hat repite: la velocidad de la máquina no reemplaza la confianza entre personas. Un reporte mal coordinado no solo no ayuda: desplaza el trabajo a la gente que no estaba preparada para recibirlo.

Y la cuarta es la que más te importa a largo plazo: el valor de tu servidor se mide por lo que no puede pasar. No por cuántos parches tienes aplicados, sino por qué tan difícil sería que alguien lo comprometa. Un servidor que no expone NFS ni comparte archivos por el kernel tiene, estructuralmente, menos superficie que uno que los expone, sin importar cuántas vulnerabilidades tenga el kernel.

El plan práctico para un homelab con dos o tres servidores

Mi postura es pragmática y no heroica. No voy a revisar código ajeno en mi tiempo libre ni a reportar vulnerabilidades a proyectos que no uso, y no creo que un servidor de dos VMs en un rack de casa necesite un proceso formal de gestión de vulnerabilidades. Pero sí hago tres cosas, porque cuestan poco y cubren lo que de verdad me puede despertar de madrugada.

La primera es tener un inventario real de lo que corre. No lo que instalé, lo que está levantado y escuchando. Es la base de todo lo demás: sin saber qué demonios tienes, cualquier alerta es ruido, y con ruido encima no hay triaje posible.

La segunda es priorizar con datos de probabilidad, no de severidad. EPSS y el catálogo KEV son dos endpoints HTTP sin costo, sin cuenta y sin instalación. Los meto en un guion que corre una vez por semana y me ordena el backlog de parches antes de que yo tenga que decidir nada.

La tercera es aceptar que no voy a estar al día con todo, y priorizar en consecuencia. Un servidor mío que expone SSH a internet con una contraseña, o un contenedor con permisos amplios, vale más que veinte CVE de severidad media en componentes que no están expuestos. Red Hat en su propio análisis llega a una conclusión parecida para su ecosistema: casi ninguno de los bugs encontrados por IA puede causar un impacto de servicio, y eso es un alivio, no un motivo para bajar la guardia.

Lo que no hago es correr scanners de IA contra mi infraestructura. Los modelos de lenguaje son útiles para leer código y encontrar patrones raros, pero son una pésima herramienta para inventario: te dan una lista de supuestos que alguien tiene que validar, que es exactamente el trabajo que ya está saturado. Para eso hay escáneres deterministas, que son más rápidos, más baratos y no alucinan.

Preguntas frecuentes

Lee también

• PHP2Shell: las RCE de PHP que explotaron miles de PoC falsos
• PHP tardó 2 años en parchear una RCE: el fallo estructural que la PHP Foundation reconoció
• CVE-2026-111497: el fallo de Brotli que rompe Node.js, Bun y Python
• Últimas vulnerabilidades: Ivanti, Cisco, Palo Alto y ahora BeyondTrust en la mira