Qué ha pasado
El 22 de agosto, Anil Madhavapeddy —profesor de informática en Cambridge y uno de los responsables del compilador de OCaml— contó algo que conviene entender aunque no programes.
Hizo lo que se hace desde siempre con un fallo de seguridad: preparar la corrección y publicarla para que otros la revisen. El fallo era de un tipo conocido —una forma de pedirle a un servidor archivos que no debería entregar— en una librería llamada cohttp. Unos diez minutos después de abrir en público esa corrección, empezaron a llegarle a su servidor sondeos que buscaban esa clase de ataque.
Su lectura de por qué llegaron tan rápido es la parte interesante, y conviene citarla como lo que es —su interpretación, no un hecho medido—: lo atribuye a que hay vigilantes automáticos pendientes de los repositorios públicos. Él acababa de emitir una señal, y alguien estaba escuchando esa señal.
Antes incluso de mirar el parche con calma, probó el otro lado: apuntó un asistente de inteligencia artificial al código afectado con una sola pista —que investigara los problemas de normalización de rutas— y en menos de un minuto tenía un ataque que funcionaba contra un servidor real levantado en local. No partió de la corrección terminada. Partió de saber aproximadamente por dónde iba la cosa.
Que la pista importe tanto no es solo su impresión. Madhavapeddy cita un estudio de Fang y otros en el que un agente basado en GPT-4 aprovechó el 87 % de un banco de 15 vulnerabilidades cuando se le daba la descripción del fallo, y solo el 7 % sin ella. La descripción sigue ayudando muchísimo: esas dos cifras están lejísimos. Lo que Madhavapeddy sostiene, con su propio caso encima, es que hoy hace falta bastante menos que una descripción completa.
Y hay un segundo síntoma, que no mide la velocidad sino el volumen: Nick Craig-Wood, que mantiene la herramienta rclone, cuenta que en los diez primeros años del proyecto recibió por GitHub unos veinte avisos de seguridad, y más de cuarenta en el último mes —de los que calcula que unas tres cuartas partes traen algo real que mirar—.
Por qué esto rompe el cálculo de siempre
La seguridad del software libre —que está por debajo de la mayoría de las webs— se ha apoyado durante décadas en una idea sencilla: encontrar cómo aprovechar un fallo es difícil y lleva tiempo. Con ese margen se organizaba todo lo demás. Se avisaba en privado, se preparaba el arreglo, se publicaba, y quien tuviera que actualizar disponía de cierta ventaja antes de que alguien supiera atacarlo.
Ese margen era el producto que se estaba comprando. Y es lo que se está evaporando.
Madhavapeddy cita dos casos de este mismo año: en el fallo CVE-2026-39987 de marimo, los primeros intentos de explotación llegaron a las nueve horas del aviso, sin que existiera prueba de concepto pública; en el CVE-2026-33017 de Langflow, a las veinte.
La consecuencia es la que importa, y es un cambio de sitio del problema: antes el cuello de botella estaba en el atacante; ahora está en quien tiene que aplicar el parche. Ya no se gana tiempo publicando con cuidado. Solo se gana actualizando rápido.
Para una empresa pequeña con una web, un gestor o una tienda, la traducción es directa. La pregunta «¿cada cuánto se actualiza esto?» ha dejado de ser una cuestión de higiene. Y no es una pregunta que puedas contestar tú: la contesta el contrato que tengas firmado con quien te lleva la web.
«Mi web es pequeña, nadie va a molestarse en atacarla»
Es la objeción de siempre, y la respuesta honesta no es la que suele darse.
Tienes razón en lo principal: es improbable que alguien se siente a estudiar específicamente tu negocio. Tu web no publica correcciones, no tiene repositorio que vigilar y no emite ninguna señal que a nadie le interese seguir. Nada de lo que le pasó a Madhavapeddy te va a pasar a ti de esa manera.
El problema es que la señal la emite otro por ti.
Tu web no está escrita entera desde cero: se apoya en piezas hechas por terceros. Cuando una de esas piezas publica la corrección de un fallo —y lo hace en abierto, como se ha hecho siempre—, ahí está la señal. Y a partir de ese momento, muchas de las webs que usan esa pieza sin actualizar quedan expuestas al mismo fallo conocido; en cuanto la corrección es pública, la zona donde buscarlo también lo es.
Y esa es la diferencia entre la anécdota de arriba y los dos casos que venían después. Lo de cohttp le pasó a quien publicó la corrección. Lo de marimo y lo de Langflow arranca en un aviso público y desemboca en intentos de explotación a las nueve y a las veinte horas: ahí el reloj ya no corre para el que publica, corre para todo el que use esa pieza.
Ahí ya no hace falta que nadie te elija a ti. Tu carpintería de tres personas no es un objetivo: es uno más de los sitios donde entra lo que ya se sabe cómo abrir.
Dicho corto: no te atacan por ser interesante. Te alcanzan por usar lo mismo que todos y no haberlo actualizado.
Las dos capas que se actualizan, y por qué se confunden
Aquí está el punto que más se confunde al contratar un mantenimiento. «Mantenimiento» significa dos cosas distintas, y un contrato puede cubrir una y no la otra.
La capa de abajo: el servidor
Es la máquina donde vive tu web y el sistema que la hace funcionar. Se actualiza con parches del sistema operativo, y suele ser lo que incluye un alojamiento. Aquí entran también las copias de seguridad, el certificado SSL —el candado del navegador— y la revisión de los registros del servidor para ver si está pasando algo raro.
La capa de arriba: lo que tu web usa para funcionar
Son las piezas de terceros de las que hablábamos: la librería que manda los correos, la que genera los PDF, la que dibuja los botones, la que conecta con la pasarela de pago. Se llaman frameworks y librerías, y son exactamente el sitio donde ocurrió lo de cohttp.
Esta capa no se actualiza sola. Alguien tiene que mirar qué piezas usa tu web, enterarse de que ha salido una versión que corrige un fallo, actualizarla y comprobar después que no se ha roto nada. Es trabajo de una persona, de forma recurrente, y es justo lo que distingue un mantenimiento de otro.
La confusión es fácil de entender: las dos cosas se llaman «mantenimiento» y las dos suenan a lo mismo. Pero el reloj del que habla este artículo corre en la capa de arriba, no en la de abajo.
Menos piezas prestadas, menos frentes abiertos
Hay una consecuencia de todo esto que no se suele decir en voz alta: cada pieza prestada que usa tu web es una puerta más que hay que vigilar. Y muchas no las eligió nadie conscientemente: vinieron dentro de otra.
Nuestro trabajo se hace con PHP, SQL, HTML, CSS con Bootstrap y JavaScript escrito a mano, sin frameworks de JavaScript. En la parte que se ejecuta en el navegador de tu cliente, eso deja las piezas ajenas en Bootstrap y poco más.
Con tres matices, porque menos no es ninguna y esto no es un argumento de venta:
- No es una estrategia de seguridad: es sencillamente cómo programamos, y este es un efecto lateral suyo.
- Dependencias sigue habiendo: PHP, la base de datos, Bootstrap y el propio servidor se actualizan igual y hay que estar encima.
- Reduce la superficie, no la elimina. Nadie está fuera de esta historia, y quien te diga lo contrario te está vendiendo algo.
Dónde toca esto lo que hacemos
Conviene mirar nuestros planes de mantenimiento con esas dos capas en la cabeza:
| Básico | Profesional | Empresarial | |
|---|---|---|---|
| Actualizaciones del sistema operativo | Incluido | Incluido | Incluido |
| Copias de seguridad | Incluido | Incluido | Incluido |
| Revisión de logs | Incluido | Incluido | Incluido |
| Seguridad SSL | Incluido | Incluido | Incluido |
| Resolución de errores (tecnología Galianet) | Incluido | Incluido | Incluido |
| Actualización mensual de frameworks y librerías | No incluido | Incluido | Incluido |
(Precios y ficha completa, en nuestra página de planes.)
Lo decimos sin adornarlo, porque está publicado en nuestra propia web y porque una empresa que te oculta esto tampoco te va a avisar el día que importe. El plan Básico incluye mantenimiento de seguridad y corrección de errores. Lo que no incluye es la actualización mensual de frameworks y librerías, que entra a partir del plan Profesional.
Y merece la pena leer esas dos frases juntas, porque es fácil quedarse con la primera: que un plan diga «mantenimiento de seguridad» no significa que cubra el reloj del que habla este artículo. Ese reloj corre en la capa de arriba, y esa línea de la tabla es la que hay que mirar.
Eso no convierte el Básico en un mal plan: es el plan pensado para una web estable, que cambia poco. Nuestra recomendación —y es recomendación, no regla— es que si lo que tienes es una tienda online, un portal de clientes o un gestor con datos dentro, la capa de arriba pesa lo suficiente como para que la actualización recurrente no sea opcional. Si estás en el Básico y crees que tu caso es ese, pregúntanos y te decimos qué plan te encaja.
Una aclaración que toca hacer, porque es la pregunta que llega siempre: nuestros planes de mantenimiento son para las soluciones que hemos desarrollado nosotros, no un servicio que se contrate por separado para una web hecha por otro. Si tu web es de otro proveedor, este artículo te sirve igual —la sección de abajo está escrita justo para eso—.
Cuatro preguntas para quien te lleve la web
Da igual quién sea tu proveedor: estas cuatro preguntas se contestan en un correo, y las respuestas te dicen casi todo. Si te contestan con generalidades, esa también es una respuesta.
- ¿Mi mantenimiento incluye actualizar los frameworks y librerías, o solo el servidor? Es la pregunta de este artículo entera, y admite un sí o un no.
- ¿Cada cuánto se hace, y cómo me entero de que se ha hecho? «Cuando hace falta» no es un plazo. Un mes es un plazo.
- ¿Qué piezas de terceros usa mi web? Nadie espera que te lo sepas de memoria, pero quien te la hizo sí debería poder decírtelo.
- Si mañana sale un fallo grave en una de ellas, ¿quién se entera y en cuánto tiempo actuáis? Aquí es donde se ve si hay alguien mirando o si el plan es esperar a que algo se rompa.
Por dónde empezar esta semana
No hace falta un proyecto para esto. Hace falta un rato:
- Busca tu contrato de mantenimiento y lee qué incluye, con la distinción de las dos capas en la cabeza. Si no aparecen las palabras «frameworks» o «librerías» por ninguna parte, es la primera pregunta que tienes que hacer.
- Manda las cuatro preguntas de arriba por correo. Que quede por escrito, que es lo que sirve dentro de un año.
- Si la respuesta no te tranquiliza, no lo dejes para el trimestre que viene. Lo que describen estos casos no es una previsión sobre lo que pasará: es lo que ya está pasando.
Y si estás dándole vueltas a rehacer tu web o tu herramienta de gestión y quieres que esta parte esté resuelta desde el principio, cuéntanos qué necesitas: te respondemos en menos de 24 horas, con claridad y sin compromiso.
Fuentes
- Anil Madhavapeddy, «Just a rumour of a bug is enough to find a security exploit these days», anil.recoil.org, 22 de agosto de 2026. anil.recoil.org
- Simon Willison, «Just a rumour of a bug is enough to find a security exploit these days», simonwillison.net, 28 de agosto de 2026. simonwillison.net
- Comentario de Nick Craig-Wood (mantenedor de rclone) en el hilo de Hacker News sobre la nota de Madhavapeddy, agosto de 2026. news.ycombinator.com
