PHP2Shell y el miércoles negro: mantener una web ya no es opcional
El 21 de octubre de 2026 coincidieron parches críticos en PHP, Node.js, Java y Fortinet, con intentos de ataque desde las primeras horas. No fue una casualidad: la inteligencia artificial está acelerando tanto el descubrimiento de vulnerabilidades como su explotación. Para cualquier negocio en Internet, el mantenimiento continuo pasa a ser parte del coste de estar online.
PHP2Shell y el miércoles negro: mantener una web ya no es opcional
El 21 de octubre de 2026 coincidieron parches críticos en PHP, Node.js, Java y Fortinet, y en algunos casos los intentos de ataque empezaron antes que las actualizaciones. Hace unas semanas escribíamos que una aplicación que funciona no está necesariamente al día. Esta semana hemos visto, a escala mundial, qué significa eso en la práctica.
Lo que pasó el 21 de octubre
El 20 de octubre, el proyecto PHP anunció que al día siguiente publicaría una actualización de seguridad crítica. El miércoles 21 salieron las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35, que corrigen dos vulnerabilidades conocidas ya como PHP2Shell:
- CVE-2026-109618: la gestión de los errores por falta de memoria puede interrumpir PHP con datos internos a medio inicializar, que después se tratan como válidos.
- CVE-2026-109619: cierto estado interno de una petición puede sobrevivir cuando su memoria ya se ha liberado, y una petición posterior puede llegar a usarlo.
Las dos tienen una puntuación CVSS 4.0 de 9,2 sobre 10 y permiten, en determinadas configuraciones, ejecutar código en el servidor sin necesidad de credenciales. Afectan a prácticamente todas las versiones de PHP en uso. PHP está detrás de cerca del 70 % de las webs cuyo lenguaje de servidor se puede identificar, según W3Techs.
No fue lo único. Ese mismo día:
- Node.js publicó correcciones para diez vulnerabilidades, la más grave en el descompresor Brotli, con posible ejecución remota de código en todas las versiones con soporte.
- Oracle emitió una alerta urgente para Java (CVE-2026-91403, CVSS 9,1): varios certificados intermedios de una autoridad de certificación habían quedado comprometidos, lo que afecta a la confianza en las conexiones HTTPS. Un día antes había publicado su actualización trimestral, con más de 1.200 vulnerabilidades corregidas.
- Fortinet anunció parches para fallos críticos en FortiOS, FortiManager y FortiAnalyzer, y pidió priorizar los equipos expuestos a Internet.
Por qué ahora: la IA acelera los dos lados
El fallo de memoria de PHP se conocía desde hace años, pero nadie había demostrado que pudiera explotarse. Según los propios investigadores, en agosto de 2026 dos equipos lo convirtieron de forma independiente en un ataque funcional con ayuda de modelos de inteligencia artificial. La PHP Foundation reconoce que la IA ha permitido aflorar más vulnerabilidades: desde el 1 de julio se han publicado quince nuevos CVE en PHP.
Esa es la parte positiva. La otra es que la misma tecnología reduce el tiempo entre que se publica un parche y aparece un ataque. Amazon detectó un intento de explotación cuatro días antes de que se publicaran las correcciones, y varias empresas de seguridad registraron intentos desde las primeras horas del día 21. El responsable de seguridad de Amazon lo resumía así: el análisis asistido por IA abarata convertir un parche en un ataque. Fortinet hizo una advertencia parecida.
Dicho de otro modo: el margen entre «ha salido una actualización» y «ya hay alguien intentándolo» ha pasado de semanas a horas.
[IMAGEN: miercoles-negro-equipo-respuesta.jpg — sustituir antes de publicar]
¿Qué gana quien ataca una web pequeña?
Es una pregunta muy habitual: «mi web no tiene nada de valor, ¿para qué iban a atacarla?». La respuesta es que casi nunca se ataca una web concreta. Se lanzan búsquedas automáticas contra miles de servidores y se aprovecha cualquiera que siga siendo vulnerable.
Una vez dentro, el beneficio puede venir de muchas formas: vender los datos de clientes o las credenciales, cifrar la información y pedir un rescate, insertar código que roba datos de pago, usar el servidor para enviar spam o minar criptomonedas, o utilizarlo como punto de partida para atacar a otros. A eso se suman las obligaciones de notificación por protección de datos y el daño a la reputación.
PHP 5.6 en 2026
Según W3Techs, más de un tercio de las webs en PHP siguen usando versiones 5 o 7, que hace años que no tienen soporte oficial. Para las ramas 7.4, 8.0 y 8.1, el proyecto publicó esta vez unas correcciones mínimas. Para PHP 5 no hay ninguna.
No es un problema de PHP. Cualquier tecnología profesional tiene un ciclo de soporte, y la rama 8.2, por ejemplo, deja de recibir parches el 31 de diciembre de 2026. Lo que el 21 de octubre ha puesto en evidencia es la diferencia entre las organizaciones que conocen el estado de sus sistemas y las que lo descubren el día de la alerta.
Es exactamente lo que planteábamos en Cuando una aplicación web funciona no significa que esté al día: una web puede funcionar perfectamente mientras se aleja, sin hacer ruido, de las versiones mantenidas. Y lo que explicábamos en Una web open source no se mantiene sola: tener una actualización disponible no es lo mismo que poder aplicarla con seguridad.
El nuevo día a día
El miércoles 21 no fue una excepción, sino un anticipo. Con la IA buscando fallos de forma sistemática, es razonable esperar más vulnerabilidades, más parches y menos tiempo para aplicarlos.
Para cualquier negocio con presencia en Internet, eso tiene una consecuencia práctica: el mantenimiento deja de ser una tarea puntual y pasa a ser un coste recurrente, como el hosting o el dominio. Da igual que la web esté hecha con una plataforma open source o con un desarrollo a medida, y que la mantenga un equipo propio o un proveedor.
La buena noticia es que la misma IA también abarata ese mantenimiento. Ayuda a revisar código, detectar dependencias obsoletas, preparar pruebas o acelerar migraciones. OpenAI, por ejemplo, publicó una herramienta para comprobar si un sistema es vulnerable a PHP2Shell.
Eso sí, conviene no confundir rapidez con criterio. Hoy cualquiera puede generar código con IA, pero hacer que ese código sea seguro, mantenible y coherente con el resto de la aplicación sigue requiriendo conocimiento. Sin él, lo que se ahorra hoy en desarrollo se paga mañana en deuda técnica.
[IMAGEN: miercoles-negro-ia-doble-filo.jpg — sustituir antes de publicar]
Qué conviene hacer
- Saber qué se tiene. Versión de PHP, Node.js o Java, CMS, plugins, librerías y servidor de cada web o aplicación.
- Conocer los ciclos de soporte. Identificar qué componentes están fuera de soporte o lo estarán pronto.
- Tener un procedimiento para los parches urgentes. Quién los aplica, en qué plazo, cómo se prueban y qué se revisa después.
- Aplicar las mitigaciones mientras tanto. Si no se puede actualizar de inmediato, aplicar las recomendaciones del fabricante y vigilar los accesos.
- Planificar las migraciones pendientes. Una versión sin soporte no se arregla en un día de alerta; se resuelve con un plan.
- Revisar con criterio lo que genera la IA. Usarla para ir más rápido, no para saltarse la revisión.
[IMAGEN: miercoles-negro-mantenimiento-continuo.jpg (opcional) — sustituir antes de publicar]
Una pregunta para esta semana
Si el miércoles 21 alguien te hubiera preguntado qué versión de PHP usa tu web, ¿lo habrías sabido? ¿Y cuánto habrías tardado en aplicar el parche?
Si la respuesta llegó rápido, el mantenimiento está funcionando. Si no, este es un buen momento para empezar a ordenarlo, antes de la próxima alerta.
Fuentes: avisos de seguridad de PHP (CVE-2026-109618, CVE-2026-109619), Node.js, Oracle; SecurityWeek, The Hacker News y W3Techs.
Las imágenes ilustrativas de este artículo se han generado con inteligencia artificial.