Entras en la web del banco y no carga. Intentas comprar un billete y aparece un aviso de mantenimiento. Vuelves a probar y nada. A veces, detrás de una caída así hay una avería corriente. Esta semana, sin embargo, parte de Internet ha tenido que protegerse de dos agujeros de seguridad especialmente graves.
El 21 de octubre de 2026, los responsables de PHP publicaron actualizaciones de emergencia para corregir dos vulnerabilidades conocidas como PHP2Shell. El día 22, medios y empresas de seguridad informaban de millones de intentos de explotación y de webs desconectadas por precaución. En España, el aviso importa porque PHP está detrás de muchas páginas de comercios, administraciones y servicios que utilizamos sin pensar en cómo funcionan.
En Sal de la Matrix solemos mirar los algoritmos que deciden qué vemos. Hoy toca hablar de otro poder menos visible: el de unas pocas piezas de software que sostienen servicios de millones de personas. Cuando una falla, hasta la página más moderna puede quedarse con el cartel de «volvemos enseguida».
Qué ha pasado con PHP2Shell y por qué es tan grave
PHP es un lenguaje de programación que trabaja en el servidor. Cuando consultas una tienda online o accedes a una zona privada, puede estar ayudando a preparar lo que aparece en tu pantalla. No necesitas saber programar para utilizarlo. De hecho, probablemente lo haces todos los días sin enterarte.
Los investigadores han identificado dos fallos críticos, CVE-2026-109618 y CVE-2026-109619, que pueden permitir ejecutar código en determinados servidores sin conocer una contraseña. El equipo oficial de PHP los considera suficientemente graves como para recomendar una actualización inmediata a todos los responsables de instalaciones afectadas.
Una puerta abierta antes de llegar a la aplicación
La idea se entiende con un ejemplo. Un comercio puede tener una web bien diseñada, contraseñas robustas y un sistema de pagos cuidado. Pero si una pieza del servidor que procesa las peticiones tiene un fallo explotable, un atacante podría intentar entrar por ahí. En ciertos entornos, el problema aparece incluso antes de que el programa de la tienda empiece a trabajar.
Eso no significa que cualquier delincuente pueda entrar automáticamente en todas las webs que usan PHP. Influyen la versión instalada, la configuración y las protecciones disponibles. El equipo de PHP señala un riesgo especialmente elevado en servidores con Apache y mod_php, aunque también considera expuestas otras formas habituales de ejecutar el lenguaje.
El famoso 70 % de Internet necesita una explicación
Algunos titulares aseguran que el fallo afecta al 70 % de las webs. La cifra tiene una base, pero hay que contarla bien. Según W3Techs, el 22 de octubre PHP aparecía en el 69,3 % de los sitios cuyo lenguaje de servidor podía identificar. No equivale al 69,3 % de todas las páginas existentes, ni demuestra que ese porcentaje sea vulnerable.
Además, utilizar PHP no implica tener una versión sin parchear. Algunos proveedores recibieron las correcciones antes de su publicación y pudieron preparar actualizaciones. Otros sistemas utilizan versiones antiguas con mantenimiento específico. Para saber si un servicio está realmente expuesto hacen falta datos de su instalación, no una multiplicación espectacular.
WordPress también utiliza PHP
La noticia interesa especialmente a pequeños negocios y medios digitales porque WordPress funciona con PHP. Un restaurante, una academia o una tienda pueden depender de ese mismo componente para mostrar su catálogo, recibir consultas o tramitar pedidos. Actualizar los plugins de WordPress no sustituye a corregir PHP en el servidor.
El riesgo de depender de una tecnología que gestiona otra organización recuerda a lo que analizamos en nuestro artículo sobre la dependencia tecnológica del Reino Unido. Allí hablábamos de servicios de inteligencia artificial. Aquí la dependencia es mucho más antigua y menos vistosa: un lenguaje que lleva décadas trabajando sin hacer ruido.
Millones de intentos de ataque no son millones de webs hackeadas
El 22 de octubre, EL PAÍS recogió las cifras comunicadas por Cloudflare: tras hacerse públicos los detalles técnicos, su red pasó de registrar miles de intentos a observar millones. También informó de desconexiones preventivas de servicios en distintos países. Un intento detectado no demuestra una intrusión exitosa; muchas solicitudes pueden proceder de ataques automatizados que no llegan a comprometer nada.
La distinción importa. Una alarma puede sonar mil veces porque alguien prueba todas las puertas del edificio. Eso no significa que haya conseguido abrirlas. Pero cuando millones de peticiones sospechosas llegan en pocas horas, los administradores tienen motivos para actuar rápido, aunque la respuesta sea cerrar temporalmente un servicio.
Por qué algunas webs se apagaron voluntariamente
El equipo de respuesta a incidentes de las instituciones europeas, CERT-EU, recomendó instalar los parches de inmediato. Si eso no era posible, aconsejó aislar de Internet los sistemas expuestos hasta poder corregirlos. Es una medida incómoda: impide prestar servicio durante un tiempo, pero reduce la oportunidad de que alguien aproveche el fallo.
Así se entiende que una web pueda dejar de funcionar sin haber sido atacada con éxito. La desconexión puede ser una decisión de seguridad, no una prueba de robo de datos. Tampoco hay datos públicos suficientes para afirmar que una entidad bancaria española concreta haya sufrido una intrusión por PHP2Shell. Conviene desconfiar de los mensajes que conviertan esta alerta en una lista improvisada de víctimas.
La inteligencia artificial encontró parte del problema
La historia tiene un giro curioso. Según el comunicado de OpenAI del 21 de octubre, la empresa Calif identificó una de las vulnerabilidades utilizando GPT-5.6 Sol dentro de la iniciativa Patch the Planet. La compañía de ciberseguridad Wiz también localizó y comunicó de forma independiente los dos fallos. Los mantenedores de PHP desarrollaron y publicaron las correcciones.
Por tanto, sería incorrecto decir que «una IA hackeó Internet» o que una sola empresa descubrió todo el problema. Hubo investigadores humanos, herramientas de IA, equipos de seguridad y responsables de software colaborando durante semanas. La IA ayudó a encontrar una debilidad, pero también puede facilitar que otros busquen cómo explotarla.
Una carrera que ahora se mueve más deprisa
Antes, analizar una pieza enorme de software exigía mucho tiempo y conocimientos especializados. Los sistemas de IA pueden ayudar a revisar código, plantear hipótesis y localizar comportamientos extraños. Eso beneficia a los defensores. El inconveniente es que algunas de esas capacidades también pueden acelerar el trabajo de quien busca una entrada ilícita.
OpenAI sostiene que los fallos fueron encontrados por los investigadores antes que por los atacantes, según la información de la que dispone. Esa afirmación no permite descartar por completo intentos previos desconocidos. Y tampoco significa que la publicación de las correcciones haya terminado con el riesgo: cada servidor que no se actualice sigue siendo un posible objetivo.
El contraste con la investigación sobre AdFection y los anuncios usados para distribuir spyware es interesante. Allí una infraestructura publicitaria podía convertirse en canal de ataque. Aquí el objetivo es una pieza básica de las webs. Dos caminos diferentes hacia el mismo problema: cuanto más dependemos de un sistema, más daño puede causar su mal uso.
Qué deberían hacer ahora los responsables de una web en España
Si gestionas una web, la primera tarea es preguntar a tu proveedor de alojamiento qué versión de PHP utiliza y si ya ha aplicado las correcciones. No basta con que el panel muestre un número parecido al recomendado: algunos proveedores distribuyen parches propios y deben confirmar qué paquete protege realmente el servidor.
Las versiones publicadas el 21 de octubre son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, según la rama utilizada. PHP 8.1 y anteriores ya no reciben actualizaciones ordinarias del proyecto; ciertos proveedores ofrecen parches adaptados, pero conviene pedir confirmación. Si tu web utiliza una versión sin soporte, planifica una migración con copias de seguridad y pruebas de compatibilidad.
Si tu web está hecha con WordPress
En el escritorio de WordPress puedes entrar en Herramientas > Salud del sitio > Información > Servidor para consultar la versión de PHP que muestra tu instalación. La ruta puede variar según el idioma o la configuración. Ese dato sirve para empezar la conversación con el alojamiento, pero no certifica por sí solo que el servidor esté protegido.
Si no administras el servidor, evita tocar configuraciones avanzadas a ciegas. Pide al hosting que confirme la actualización y comprueba después que la web funciona. Las medidas temporales descritas por PHP y CERT-EU reducen determinados riesgos, pero ninguna sustituye a instalar el parche correspondiente. Una solución rápida mal aplicada también puede dejar una tienda sin cobrar pedidos.
Y si solo utilizas Internet, ¿tienes que hacer algo?
Como usuario corriente, no puedes actualizar el PHP del banco ni de una web de viajes. Esa responsabilidad corresponde a quienes prestan el servicio. Si una página no funciona, entra más tarde desde su dirección habitual y consulta sus canales oficiales. No sigas enlaces recibidos por mensajes que prometan una «nueva web segura» para acceder a tu cuenta.
La alerta tampoco justifica cambiar todas tus contraseñas por sistema. Si un servicio confirma una brecha que afecta a tus datos, sigue sus indicaciones y revisa tus cuentas. Mientras tanto, mantener la autenticación en dos pasos y desconfiar de solicitudes urgentes de pago sigue siendo sensato. Ya vimos en el caso de ZyMix y sus proveedores de datos lo difícil que resulta saber qué ocurre detrás de una aplicación.
Una infraestructura invisible con consecuencias muy visibles
El episodio deja una imagen poco tranquilizadora: miles de organizaciones pendientes de instalar un parche mientras los sistemas automáticos prueban si alguna llega tarde. La cooperación entre investigadores y mantenedores ha permitido publicar correcciones, pero aplicarlas en cada servidor lleva tiempo, presupuesto y personal.
Y hay una paradoja bastante buena para 2026. Hemos llenado los titulares de asistentes capaces de escribir, razonar y programar. Mientras tanto, una parte enorme de nuestra vida digital sigue dependiendo de que alguien, en algún despacho, encuentre cinco minutos para actualizar PHP. Ojalá ese alguien no haya dejado la tarea para el lunes.
