---
title: "Encontrar fallos ya es barato. Arreglarlos, no"
date: "2026-11-03T07:10:00+01:00"
modified: "2026-11-02T11:33:36+01:00"
author: "David Carrero Fdez-Baillo"
section: "Internet y sociedad"
canonical: "https://carrero.es/encontrar-fallos-barato-arreglarlos-no/"
site: "Carrero"
---

# Encontrar fallos ya es barato. Arreglarlos, no

Este mes se ha corregido un fallo crítico en la forma en que el kernel de Linux abre conexiones TCP. Permite, en ciertas configuraciones, tomar el control de un servidor a distancia sin contraseña. **Llevaba ahí once años.** Lo reportó un investigador de Anthropic, y la compañía asegura que su modelo, Claude, escribió el exploit que demuestra que se puede atacar.

Once años de código abierto, a la vista de cualquiera. La lectura fácil es que el código abierto es inseguro. Yo creo que es justo la contraria.

Pero hay otra pregunta que me preocupa mucho más, y que ya dejé caer hace unos días [en LinkedIn a raíz de PHP2Shell](https://www.linkedin.com/posts/dcarrero_php-ciberseguridad-wordpress-share-7518608822161027072-KFGn/): si las máquinas van a encontrar fallos a un ritmo que nunca hemos visto, **¿quién va a pagar por arreglarlos?**

## Las claves en 20 segundos

- El fallo CVE-2026-98432 estaba en el TCP del kernel de Linux desde la versión 4.4, unos once años, y se corrigió el 5 de octubre de 2026.
- Ya pasó con Heartbleed, WannaCry, Log4Shell o xz; la diferencia ahora es la velocidad. En abril, un investigador usó Claude Code para encontrar en Linux otro fallo explotable en remoto que llevaba 23 años escondido.
- Que el código abierto saque estos fallos no lo hace más inseguro: se encuentran precisamente porque el código se puede leer.
- La NVD registró 49.972 vulnerabilidades en todo 2025; en 2026, a 24 de octubre, ya iban 88.602. El problema está en el otro lado: semanas después del parche, varias versiones de Ubuntu y de Red Hat seguían sin él.
- La IA ha abaratado encontrar fallos. Arreglarlos sigue dependiendo de personas, muchas veces voluntarias.

## Qué ha pasado con el fallo de TCP

Cada vez que un servidor acepta una conexión, el sistema hace un pequeño saludo con el otro lado antes de empezar a hablar. En ese saludo, en conexiones IPv4, había una condición de carrera: si dos cosas ocurrían en el momento justo, el kernel acababa leyendo memoria que ya había liberado. Es lo que los técnicos llaman un *use-after-free*, y es una de las puertas de entrada clásicas para un atacante.

El fallo entró en Linux 4.4 y se corrigió el 5 de octubre de 2026. El commit atribuye el aviso a Xinyang Ge, investigador de Anthropic. La compañía afirma que **Claude escribió un exploit en dos fases** que, en servidores que usan una variante de TCP llamada MPTCP, permite ejecutar comandos como administrador sin credenciales. En su prueba, filtrar una dirección de memoria del kernel llevó 48 minutos y tomar el control, cinco más. El exploit no se ha publicado y, hasta finales de octubre, no se conocían ataques reales.

![Commit que corrige el CVE-2026-98432 en el kernel de Linux. Fuente: git.kernel.org.](https://carrero.es/wp-content/uploads/2026/11/commit-kernel-linux-cve-2026-98432-carrero.webp)
*Commit que corrige el CVE-2026-98432 en el kernel de Linux. Fuente: git.kernel.org.*

Hay un matiz importante: por lo publicado, no está claro si fue Claude quien encontró el fallo o si encontró la forma de explotarlo una vez localizado. Para lo que quiero contar da igual, porque las dos cosas, encontrar y explotar, eran hasta hace poco trabajo de semanas para especialistas muy escasos.

## La lectura fácil, y por qué es la contraria

Cuando aparece un fallo así, siempre hay quien concluye que el código abierto es un coladero. Once años con la puerta abierta y nadie se dio cuenta.

Yo lo veo al revés. **Ese fallo se ha encontrado porque el código se puede leer.** Cualquiera puede descargar el kernel de Linux, dárselo a un modelo y pedirle que busque problemas, que es exactamente lo que están haciendo investigadores de todo el mundo. En el software cerrado la deuda es la misma, o mayor, pero la revisan muchos menos ojos y, ahora, también muchas menos máquinas.

Lo escribí hace unas semanas a propósito de [Stockfish, el mejor motor de ajedrez del mundo](https://carrero.es/mejor-motor-ajedrez-gratis-stockfish-lichess/): lo abierto funciona porque cualquiera puede mirar dentro y mejorarlo. La seguridad es la otra cara de esa misma moneda. Mirar dentro también sirve para encontrar lo que está mal.

## La historia se repite, pero más deprisa

Nada de esto es nuevo. Lo que ha cambiado es la velocidad.

- **2014, Heartbleed.** En abril apareció un fallo en OpenSSL, la librería que cifraba buena parte de las conexiones seguras de internet. Lo revelador fue descubrir quién la mantenía: **en 2013 el proyecto había recibido apenas 2.000 dólares en donaciones y tenía un solo desarrollador a tiempo completo.** A raíz del susto, la Linux Foundation creó la Core Infrastructure Initiative, con más de 3 millones de dólares comprometidos por Google, Amazon, Facebook, IBM, Intel, Cisco o Dell.
- **2017, WannaCry.** El 12 de mayo, un ransomware paralizó en horas ordenadores de hospitales, empresas y administraciones de medio mundo. Explotaba un fallo en el protocolo SMB de Windows para el que **Microsoft había publicado el parche el 14 de marzo, casi dos meses antes**. El problema no fue descubrir el fallo, sino que miles de sistemas seguían sin actualizar.
- **2021, Log4Shell.** En diciembre apareció un fallo crítico en Log4j, una librería de registros de Java presente en miles de millones de aplicaciones. Muchas empresas ni siquiera sabían que la usaban. Y la mantenía un pequeño grupo de voluntarios en su tiempo libre. Su primer apoyo económico serio, casi 600.000 euros de la agencia alemana Sovereign Tech Agency, no llegó hasta 2023, dos años después del susto.
- **2024, la [puerta trasera de xz](https://www.opensecurity.es/cve-2024-3094-la-puerta-trasera-xz-descubierta-por-un-500-milisegundos/).** Alguien que firmaba como «Jia Tan» se pasó unos dos años ganándose la confianza de los mantenedores de xz, una librería de compresión presente en casi todos los Linux, presionándolos incluso con cuentas falsas, hasta convertirse en mantenedor y colar una puerta trasera. El 29 de marzo la descubrió por casualidad Andres Freund, un ingeniero que notó que SSH iba algo más lento de lo normal en una versión de pruebas de Debian. **No llegó a las versiones estables por muy poco.** Fue la prueba de que un mantenedor sobrecargado no es solo un problema de velocidad, también de seguridad.
- **2026, PHP2Shell.** El 20 de octubre se dio el aviso y el 21 salieron los parches. Pero Amazon ya había detectado un intento de explotación el día 17, antes de que existiera la corrección.
- **2026, Node2Shell o HTTP2Shell.** El mismo 21 de octubre, Node.js y Google publicaron parches para un desbordamiento de memoria en Brotli, la librería de compresión de Google que usan millones de servidores web. Se le dieron tres nombres porque primero apareció en Node.js y después se vio que alcanzaba también a librerías de Python, a .NET y a todo lo que llevara su propia copia de Brotli. **Seis días después, la agencia de ciberseguridad estadounidense CISA ya lo incluía en su catálogo de vulnerabilidades explotadas.** Y actualizar la librería del sistema no bastaba: había que reconstruir cada aplicación y cada contenedor que la llevaba dentro.

Doce años, la misma lección: el eslabón débil nunca es solo el fallo, es el tiempo que pasa hasta que se corrige donde de verdad importa. **La diferencia ahora es que la IA está acortando ese margen por los dos lados**: ayuda a encontrar fallos antes, pero también a convertirlos en ataques antes. En el caso del TCP de Linux, el exploit tardó menos de una hora en tomar el control del servidor de prueba.

## No es un caso aislado

Y lo que hace distinto este año, además de la velocidad, es la frecuencia.

- **Abril de 2026, 23 años.** Nicholas Carlini, también investigador de Anthropic, montó un script que recorría uno a uno los archivos del kernel de Linux y le pedía a Claude Code que buscara vulnerabilidades en cada uno. Así apareció un desbordamiento de memoria en el código de NFS, el sistema para compartir archivos en red, que llevaba ahí desde 2003. Y Carlini contaba que tenía **cientos de posibles fallos más sin validar**, porque no quería inundar a los mantenedores con avisos poco fiables.
- **Octubre de 2026, once años.** El fallo de TCP del que hablo aquí.
- **Octubre de 2026, PHP2Shell.** Dos vulnerabilidades en el propio lenguaje PHP, presentes desde la versión 5.4, que permitían ejecutar código en un servidor web sin iniciar sesión. Afectan a cualquier web en PHP, desde WordPress a Magento. Varios equipos las encontraron de forma independiente, y alguno de ellos reconoce que los modelos de IA fueron clave en el proceso.

Hay décadas de fallos acumulados en el software del que depende internet, y por primera vez tenemos una herramienta capaz de sacarlos a la luz de forma sistemática. **Viene una ola, y no es una metáfora.**

Y no lo digo por intuición. Hace unos días, cuando empezó a circular por LinkedIn la expresión «octubre negro», hice lo que suelo hacer con estos titulares: [me descargué los datos](https://www.linkedin.com/posts/dcarrero_estos-d%C3%ADas-me-aparece-en-linkedin-la-expresi%C3%B3n-share-7519690977813393408-qCHx/). La base de datos de vulnerabilidades del NIST (NVD) registró 49.972 CVE en todo 2025. **En 2026, a 24 de octubre, ya iban 88.602.** Septiembre marcó un récord de 15.074 en un solo mes, frente a los 4.415 de enero de 2025. El volumen es tal que el NIST ya tiene que priorizar qué vulnerabilidades analiza.

![CVE publicadas cada mes en la NVD, 2016-2026. Datos a 24 de octubre de 2026. Elaboración propia con datos de NIST, Anthropic, Wiz y PHP.](https://carrero.es/wp-content/uploads/2026/11/vulnerabilidades-se-disparan-carrero-es.webp)
*CVE publicadas cada mes en la NVD, 2016-2026. Datos a 24 de octubre de 2026. Elaboración propia con datos de NIST, Anthropic, Wiz y PHP.*

Un matiz para no vender humo: «octubre negro» no es un nombre oficial ni una campaña concreta, y en los días en que se hizo viral no había un pico especial. El salto viene de meses atrás. Y parte de la explicación es que la IA ya encuentra fallos a escala: Google Big Sleep en SQLite, OSS-Fuzz en OpenSSL, XBOW en lo más alto de la clasificación de HackerOne, la final del AIxCC de DARPA o Anthropic, que dice haber comunicado 6.157 vulnerabilidades en 591 proyectos de código abierto.

## El cuello de botella es parchear

Encontrar el fallo es solo el primer paso de una cadena larga. Alguien tiene que entenderlo, escribir la corrección, revisarla, integrarla en el kernel, y después cada distribución tiene que llevarla a sus propias versiones. Y por último, cada administrador tiene que instalarla y reiniciar sus servidores. Quizá aquí la IA también acabe ayudando, y no solo a encontrar fallos: a acelerar la actualización de servidores donde las herramientas de automatización de siempre se quedan cortas.

El fallo de TCP es un buen ejemplo de lo que pasa en esa cadena. El parche llegó al kernel el 5 de octubre. A finales de octubre, Debian, Oracle Linux, Amazon Linux 2023 y algunas versiones de SUSE ya lo tenían. Pero **a 2 de noviembre, casi un mes después del parche, Ubuntu seguía marcando como vulnerables todas sus versiones con soporte: de la 22.04 a la 26.10 con el arreglo «en curso», y la 16.04, 18.04 y 20.04 sin fecha. Red Hat 8, 9 y 10 también figuraban como afectados y sin fecha.** Ni siquiera había acuerdo sobre la gravedad: el kernel le dio un 9,8 sobre 10; Red Hat, entre 5,9 y 8,1; Amazon, un 7,0.

![Estado del CVE-2026-98432 en Ubuntu a 2 de noviembre de 2026: todas las versiones con soporte siguen vulnerables. Fuente: Ubuntu Security.](https://carrero.es/wp-content/uploads/2026/11/ubuntu-cve-2026-98432-estado-parches-carrero.webp)
*Estado del CVE-2026-98432 en Ubuntu a 2 de noviembre de 2026: todas las versiones con soporte siguen vulnerables. Fuente: Ubuntu Security.*

![Estado del CVE-2026-98432 en Debian: ya corregido en los repositorios de seguridad de bookworm y trixie. Fuente: Debian Security Tracker](https://carrero.es/wp-content/uploads/2026/11/debian-cve-2026-98432-estado-parches-carrero.webp)
*Estado del CVE-2026-98432 en Debian: ya corregido en los repositorios de seguridad de bookworm y trixie. Fuente: Debian Security Tracker*

Con PHP2Shell pasó algo todavía más revelador. La PHP Foundation reconoció que un aviso relacionado, detectado por un desarrollador en 2024, se quedó estancado durante meses, y lo calificó de **fallo estructural**. Además, PHP ya no corrige las versiones 8.1 y anteriores, y una parte enorme de la web sigue funcionando en PHP 7.

No es que nadie quiera arreglar las cosas. Es que hay muy poca gente para hacerlo. Mucho código crítico de internet lo mantienen voluntarios o equipos muy pequeños, en su tiempo libre o con financiación precaria. Hasta ahora el ritmo de fallos encontrados les permitía ir tirando. Si ese ritmo se multiplica, no lo hará.

## Lo que veo desde dentro

Esto lo vivo por los dos lados. En [Stackscale](https://www.stackscale.com/) (Aire) operamos infraestructura cloud privada en centros de datos europeos, y cada fallo crítico en el kernel o en el hipervisor significa planificar parches, ventanas de mantenimiento y reinicios sin afectar a los clientes. Y en [Color Vivo](https://colorvivo.com/) mantenemos una red de más de cien webs, casi todas en WordPress y, por tanto, en PHP. Cuando salió PHP2Shell, la pregunta no fue si había que actualizar, sino en qué orden y en cuánto tiempo. Por suerte en este caso no son muchas máquinas virtuales el proceso se pudo completar en menos de 60 minutos de tiempo efectivo desde la publicación de las actualizaciones de Ubuntu, Debian y AlmaLinux.

Y, como desarrollador independiente, también estoy al otro lado. [mboxshell](https://github.com/dcarrero/mboxshell), mi proyecto de código abierto más vivo, ya recibe contribuciones de personas que no conozco. Si mañana alguien me manda diez avisos de seguridad generados con IA, tendré que revisarlos uno a uno, en mi tiempo libre, sin cobrar por ello. Multiplica eso por miles de proyectos y tienes el problema.

**Encontrar fallos se ha vuelto barato. Arreglarlos sigue siendo caro**, y el coste recae en quien menos recursos tiene.

## Quién debería pagar

No tengo la solución, pero sí tengo claro por dónde empezar.

- **Quien usa el código.** Las grandes empresas, los proveedores cloud y los hiperescaladores construyen negocios enormes sobre Linux, PHP y miles de librerías abiertas. Financiar a sus mantenedores no es caridad, es mantenimiento de su propia infraestructura.
- **Las administraciones.** Igual que pagamos carreteras y puentes, el software abierto del que dependen los servicios públicos es infraestructura crítica. Hace un mes escribí sobre [un buzón que se ha pagado diecisiete veces](https://carrero.es/no-es-un-buzon-de-4-millones-es-el-mismo-software-pagado-diecisiete-veces/); una fracción de ese dinero bien dirigida mantendría proyectos de los que depende media Europa.
- **Quien encuentra los fallos con IA.** Los laboratorios que están sacando a la luz estas vulnerabilidades tienen una responsabilidad especial. No basta con avisar: hay que ayudar a arreglar, con parches propuestos, avisos bien validados y recursos para los equipos que reciben el aluvión. Que los mismos modelos que encuentran fallos ayuden también a corregirlos sería el mejor uso posible de esta capacidad.
- **Y cada uno de nosotros.** Actualizar no es opcional: un parche que existe pero no se instala no protege a nadie, como demostró WannaCry. Pero con este ritmo no basta con contar parches pendientes. Hay que saber responder a tres preguntas: qué fallos son un riesgo real para mi negocio, qué equipos tengo de verdad expuestos y cuánto tiempo necesito para cerrar la puerta. Y cuando no se puede actualizar de inmediato, existen medidas de contención, como bloquear el ataque en un cortafuegos de aplicaciones o desactivar el servicio afectado, que dan margen mientras llega la corrección definitiva.

## La deuda ya estaba ahí

La Inteligencia Artificial no ha creado estos fallos. Llevaban once, veinte, veintitrés años escritos en el código. Lo que ha cambiado es que ahora podemos verlos, y eso es una buena noticia. Es mucho mejor que los encuentre un investigador que los reporta que alguien que los vende.

Pero ver la deuda no es pagarla. Si seguimos tratando el mantenimiento del código abierto como un trabajo invisible que alguien hará gratis, la ola de vulnerabilidades que viene acabará encima de unas pocas personas que no dan abasto.

Encontrar fallos ya es barato. Arreglarlos, no. **La pregunta es quién va a pagar la diferencia.**

## Preguntas frecuentes

**¿Qué es CVE-2026-98432?** Un fallo crítico en el TCP del kernel de Linux, presente desde la versión 4.4, que provoca un use-after-free al establecer conexiones IPv4. En servidores con MPTCP puede permitir ejecutar comandos como administrador de forma remota. Se corrigió el 5 de octubre de 2026.

**¿Lo encontró una inteligencia artificial?** Lo reportó un investigador de Anthropic, y la compañía afirma que su modelo Claude escribió el exploit. No está claro si Claude también localizó el fallo.

**¿El código abierto es menos seguro que el cerrado?** No necesariamente. Estos fallos se encuentran porque el código se puede revisar. El software cerrado también acumula fallos, pero los revisan menos personas y menos herramientas.

**¿Qué tengo que hacer si tengo servidores Linux?** Actualizar el kernel en cuanto tu distribución publique el parche y reiniciar. Revisa el estado en la página de seguridad de tu distribución, porque los plazos varían mucho.

**¿Qué versiones de PHP corrigen PHP2Shell?** Las 8.5.12, 8.4.27, 8.3.36 y 8.2.35, publicadas el 21 de octubre de 2026. Tras actualizar hay que reiniciar los procesos de PHP (por ejemplo, PHP-FPM). Las versiones 8.1 y anteriores ya no reciben parches.

## Fuentes

- [Linux Kernel TCP Flaw With 9.8 CVSS Score Affects Ubuntu, Red Hat and Other Distributions, The Hacker News](https://thehackernews.com/2026/10/linux-kernel-tcp-flaw-with-98-cvss.html)
- [Critical Linux kernel flaw allows remote root attacks on MPTCP servers, BleepingComputer](https://www.bleepingcomputer.com/news/security/critical-linux-kernel-flaw-allows-remote-root-attacks-on-mptcp-servers/)
- [Claude Code Found a Linux Vulnerability Hidden for 23 Years, mtlynch.io](https://mtlynch.io/claude-code-found-linux-vulnerability)
- [PHP2Shell: One Upload, Full Server, Varonis](https://www.varonis.com/blog/php2shell)
- [PHP2Shell explained, Flow Ninja](https://www.flowninja.com/blog/php2shell)
- [PHP2Shell vulnerabilities now under active exploitation, Computing](https://www.computing.co.uk/news/2026/security/php2shell-under-active-exploitation)
- [Indicators Associated With WannaCry Ransomware, US-CERT](https://us-cert.gov/ncas/alerts/TA17-132A)
- [Log4j, Sovereign Tech Agency](https://www.sovereign.tech/tech/log4j)
- [The Apache Log4j team talks about the Log4Shell patching process, The Record](https://therecord.media/the-apache-log4j-team-talks-about-the-log4shell-patching-process/)
- [Where’s the next Heartbleed bug lurking?, MIT Technology Review](https://www.technologyreview.com/2014/04/29/172985/wheres-the-next-heartbleed-bug-lurking)
- [Core Infrastructure Initiative, Wikipedia](https://en.wikipedia.org/wiki/Core_Infrastructure_Initiative)
- [xz backdoor, OffSec](https://www.offsec.com/offsec/xz-backdoor/)
- [XZ Utils supply chain attack, TechRepublic](https://www.techrepublic.com/es/article/xz-backdoor-linux/)
- [CVE-2026-98432, Ubuntu Security](https://ubuntu.com/security/CVE-2026-98432)
- [CVE-2026-98432, Debian Security Tracker](https://security-tracker.debian.org/tracker/CVE-2026-98432)
- [Commit de la corrección en el kernel de Linux](https://git.kernel.org/linus/e3f33b0a1d89d738e2b913dab519226eaf76e15b)
- [National Vulnerability Database (NVD), NIST](https://nvd.nist.gov/)
- [Mi análisis de los datos de NVD sobre el «octubre negro», LinkedIn](https://www.linkedin.com/posts/dcarrero_estos-d%C3%ADas-me-aparece-en-linkedin-la-expresi%C3%B3n-share-7519690977813393408-qCHx/)
- [Critical HTTP2Shell Brotli vulnerability triggers emergency patches, BleepingComputer](https://bleepingcomputer.com/news/security/critical-http2shell-brotli-vulnerability-triggers-emergency-patches)
- [Node2Shell (CVE-2026-111497) in active exploitation, Sophos](https://www.sophos.com/blog/node2shell-cve-2026-111497-in-active-exploitation)

---

Fuente: https://carrero.es/encontrar-fallos-barato-arreglarlos-no/