El 21 de octubre no fue una excepción: mantener una web es ya parte del día a día

Hace apenas un mes publicábamos dos artículos sobre una idea sencilla: una web que funciona no está necesariamente al día, y una plataforma open source no se mantiene sola. Esta semana, una cadena de avisos de seguridad en tecnologías de todo tipo ha llevado esa idea a los titulares de medio mundo. No es un episodio aislado: es el ritmo al que vamos a tener que acostumbrarnos.

Una semana que ha dado la vuelta al mundo

El miércoles 21 de octubre concentró buena parte de los avisos, pero no fue el único día ni la única tecnología. En pocos días se publicaron, entre muchos otros:

• Lenguajes y entornos: una alerta urgente en Java, diez vulnerabilidades corregidas en Node.js, una actualización de emergencia en PHP y un fallo crítico en Pillow, la librería de imágenes más usada de Python.
• Servidores y plataformas: un fallo de gravedad máxima en GitLab, dos fallos críticos en el kernel de Linux publicados antes de tener parche y más de 1.200 vulnerabilidades corregidas por Oracle.
• Redes y seguridad perimetral: un fallo ya explotado en Arista VeloCloud, parches urgentes de Fortinet y una campaña contra firewalls y VPN con más de 70.000 credenciales expuestas.
• Cadena de suministro: versiones con malware de LiteLLM y de la herramienta de línea de comandos de OVHcloud, y un posible acceso a secretos de clientes en la plataforma Railway.
• Certificados: ocho certificados intermedios de eMudhra comprometidos, que obligaron a Chrome, Mozilla, Java y Python a dejar de confiar en ellos.
• Herramientas de IA: fallos en agentes y SDK de inteligencia artificial que permitían ejecutar código o vaciar saldos.

Ninguna tecnología se libra, y no tiene sentido culpar a una en concreto. Que un lenguaje o una plataforma reciba muchos avisos suele indicar, sobre todo, que está muy extendido y que mucha gente revisa su código. Lo que esta semana pone de manifiesto no es que una tecnología sea peor que otra, sino que todas necesitan mantenimiento.

Cada uno de estos avisos ha tenido a equipos técnicos de todo el mundo revisando sistemas, aplicando parches y respondiendo preguntas, muchas veces fuera de horario.

Ser vulnerable no es haber sido atacado

En medio del ruido conviene separar dos cosas que se están mezclando. Que se publique una vulnerabilidad no significa que una web haya sido atacada. Significa que, si no se actúa, podría serlo.

En el caso de PHP, por ejemplo, los atacantes empezaron a probar suerte a los pocos minutos: Cloudflare contabilizó millones de intentos en las primeras horas. Pero no está claro cuántos han tenido éxito: varias empresas que vigilan este tráfico no han registrado ninguno, y algunos investigadores apuntan que el ataque es más difícil de lo que parecía al principio.

Lo que corresponde ante un aviso así es evaluar a qué sistemas afecta, aplicar la actualización o las medidas de mitigación, y vigilar. En Aduxia lo hicimos desde el mismo día 21 en los sistemas que mantenemos, y seguimos haciéndolo con cada nuevo aviso. Lo intentamos hacer de forma responsable, continuada y diligente. Pero no lo presentamos como una hazaña: es exactamente lo que debería ser el mantenimiento.

Cuando la alarma genera su propio trabajo

Esta semana también ha tenido un efecto colateral. La repercusión mediática ha llevado a muchas organizaciones a pedir a sus proveedores informes, certificados y justificaciones: si su web ha sido atacada, si sus datos han salido, qué se ha hecho exactamente.

Es lógico querer saberlo, y explicar qué se ha hecho forma parte del servicio. Pero conviene entender que, sin indicios de un ataque, no se puede demostrar que algo no ha ocurrido: se puede explicar qué se ha revisado, qué se ha aplicado y cuándo. Cuando esa información se pide de golpe y a todos a la vez, el tiempo dedicado a justificar compite con el tiempo dedicado a proteger.

La solución no es dejar de preguntar, sino que la pregunta deje de ser excepcional. Si el mantenimiento y su seguimiento forman parte de la rutina, la respuesta ya existe antes de la próxima alerta.

¿Sabes en qué estado está tu web? Solicita una revisión sin compromiso

Por qué se está acelerando

En buena parte, por la inteligencia artificial. Fortinet explica que sus últimas correcciones vienen de un programa de pruebas de seguridad asistidas por IA, en colaboración con varias empresas del sector. En PHP, un fallo conocido desde hacía años no se había podido demostrar como explotable hasta que dos equipos de investigación lo consiguieron este verano con ayuda de modelos de IA.

Es una buena noticia: se encuentran y se corrigen fallos que llevaban años escondidos. Pero tiene otra cara. Las mismas herramientas permiten a quien ataca analizar un parche y deducir cómo aprovechar el fallo en horas, no en semanas. Por eso el margen para actualizar se reduce cada vez más.

Nada de esto es gratis

En los últimos años hemos democratizado la tecnología. El open source permite construir una web o una tienda online sin pagar licencias. La IA permite generar código en minutos. Todo eso es positivo, pero ha alimentado una idea equivocada: que lo que no se paga al principio no cuesta nada después.

Una licencia gratuita no incluye el mantenimiento. Alguien tiene que vigilar los avisos, actualizar, probar y responder cuando algo sale mal. Y aunque cualquiera puede generar código con IA, hacer que ese código sea seguro y mantenible sigue requiriendo conocimiento. Sin él, lo que se ahorra hoy se paga mañana en deuda técnica.

La parte buena es que la IA también abarata ese mantenimiento: ayuda a revisar código, detectar componentes obsoletos y preparar migraciones. El coste no desaparece, pero puede ser más razonable si se gestiona con criterio.

Las pequeñas empresas también están en el mapa

Las grandes empresas cuentan con un responsable de seguridad de la información, el CISO (Chief Information Security Officer). Para una pequeña empresa, tener uno en plantilla, o incluso contratarlo como servicio externo, puede ser un coste difícil de asumir.

Pero los ataques automatizados no distinguen tamaños. Recorren Internet buscando cualquier servidor vulnerable, y una web pequeña es tan fácil de encontrar como una grande. Una vez dentro, se puede robar datos de clientes, pedir un rescate, usar el servidor para atacar a otros o, simplemente, dejar la web fuera de servicio.

Para una tienda de barrio que gestiona sus pedidos online o un pequeño comercio electrónico, unos días sin web pueden suponer un golpe serio. Por eso la seguridad también tiene que tener un responsable en las empresas pequeñas, aunque sea a una escala proporcionada.

Qué puede hacer cualquier empresa

1. Saber qué tiene. Qué webs y aplicaciones usa, con qué tecnología y quién las mantiene.
2. Acordar cómo se responde a los avisos. Quién los revisa, en qué plazo se aplican los parches urgentes y cómo se comunica lo que se ha hecho.
3. Pedir información de forma periódica, no solo en las alertas. Un informe regular de mantenimiento evita tener que reconstruirlo todo con prisas.
4. Mantener copias de seguridad que se hayan probado. Son la red de seguridad cuando todo lo demás falla.
5. No dejar las versiones sin soporte para más adelante. Una migración pendiente no se resuelve en un día de alerta; necesita un plan.
6. Tener un responsable de seguridad, a su escala. Una persona interna, el proveedor o un servicio externo, pero que alguien tenga claro que esa tarea es suya.

Ya lo decíamos, y ahora va más rápido

En Cuando una aplicación web funciona no significa que esté al día explicábamos que una web puede seguir funcionando mientras se aleja, sin hacer ruido, de las versiones mantenidas. En Una web open source no se mantiene sola contábamos que tener una actualización disponible no es lo mismo que poder aplicarla con seguridad.

Un mes después, lo que ha cambiado es la velocidad. La próxima alerta llegará, probablemente antes de lo que pensamos. La diferencia no estará en si nos afecta, sino en si estamos preparados para responder con calma.

Fuentes: avisos de seguridad de PHP, Node.js, Oracle, Fortinet y LiteLLM; The Hacker News, SecurityWeek y W3Techs.

Las imágenes ilustrativas de este artículo se han generado con inteligencia artificial.