El 21 de octubre de 2026 PHP publicó cuatro versiones de emergencia: 8.5.12, 8.4.27, 8.3.36 y 8.2.35. No era una actualización rutinaria. Cerraban dos vulnerabilidades bautizadas como php2shell, identificadas como CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en el servidor sin autenticación previa. La agencia federal de ciberseguridad estadounidense pidió ese mismo día aplicar el parche sin espera (CISA, 2026).
Ejecución remota de código sin autenticación es, en la lista de cosas que pueden pasarle a una web, la combinación que nadie quiere ver. No hace falta robar credenciales, ni aprovechar una sesión abierta, ni conocer por dentro la aplicación. Si el servidor expone una versión afectada, el atacante manda instrucciones y el servidor las ejecuta. Nada que robar. Nada que romper.
Esta pieza no repite el telediario. Responde lo que el telediario no responde: cómo saber si estás expuesto, qué se hace esta semana y quién ocupa cada parte del trabajo. Si diriges un equipo técnico con webs sobre PHP, propias, de clientes o heredadas, eso es lo que tienes delante, con la diferencia de que esta vez el calendario no lo fijó tu plan trimestral sino alguien publicando dos CVE un martes por la mañana.
php2shell son dos vulnerabilidades de PHP, CVE-2026-109618 y CVE-2026-109619, que permiten ejecutar código en el servidor sin autenticación. Se divulgaron el 20 y 21 de octubre de 2026 y el parche salió el mismo día 21: las versiones seguras son 8.5.12, 8.4.27, 8.3.36 y 8.2.35 en cada rama (Huntress, 2026). CISA pidió aplicarlas de inmediato porque la explotación empezó en horas, no en semanas. Aquí va cómo auditar qué superficies corren PHP, en qué orden parchear, qué revisar después (credenciales, logs, webshells) y qué tiene que ver con el ENS y con NIS2.
Qué es php2shell y por qué se parcheó en 24 horas
La secuencia fue rápida incluso para los estándares de este tipo de fallo. El 20 de octubre el proyecto PHP anunció una publicación fuera de calendario para el día siguiente; el 21, a las 14:00 UTC, salieron los detalles técnicos y las versiones corregidas casi a la vez (Huntress, 2026). El margen para inventariar lo expuesto antes de que exista exploit público fue prácticamente nulo, y no porque el proyecto PHP hiciera las cosas mal, sino porque el inventario de superficies de una organización media, repartido entre equipos de plataforma, desarrollo y un par de proveedores externos, no se hace en una tarde ni con buenas intenciones.
Las ramas afectadas son las que estaban en soporte activo: 8.2, 8.3, 8.4 y 8.5. Las versiones que cierran los dos CVE son las cuatro de la tabla. Si en algún entorno corre una 8.2 a 8.5 anterior a la suya, ese entorno está en zona de riesgo, y lo está aunque nadie lo tenga documentado, porque el mapa de lo que corre en producción y el mapa que el equipo cree que corre en producción llevan años divergiendo en cualquier empresa que haya heredado sistemas, absorbido proyectos o integrado equipos ajenos.
| Rama de PHP | Versión corregida (21 de octubre de 2026) |
|---|---|
| 8.2 | 8.2.35 |
| 8.3 | 8.3.36 |
| 8.4 | 8.4.27 |
| 8.5 | 8.5.12 |
La diferencia entre una ejecución de código que exige credenciales y una que no las exige es la diferencia entre un incidente y una campaña. La primera la explota quien ya entró. La segunda la explota cualquiera. Un script y una lista de direcciones bastan. El mismo día, a escala. Por eso la alerta de CISA (2026) no habla de riesgo potencial, y por eso en las horas posteriores ya se registraban intentos de explotación masivos sobre sitios sin actualizar (Help Net Security, 2026).
Por qué el descubrimiento lo hizo una IA, y qué significa
Las vulnerabilidades se localizaron en agosto de 2026 con ayuda de herramientas de análisis basadas en IA, según recoge la crónica del incidente (Wikipedia, 2026). Llevaban años ahí. Nadie las había visto. Nadie había mirado a esa escala.
Una semana antes del parche, CNBC (2026) contaba la otra pieza del mismo patrón: Mythos, el modelo de Anthropic dedicado a localizar y demostrar debilidades de software, había destapado suficientes fallos en Bank of America como para que el banco anunciara la contratación de 1.000 profesionales externos que apoyan al equipo interno de parcheado. Mil personas para remediar lo que un modelo encontró. La escala del remedio, con entornos heterogéneos, ventanas de mantenimiento que no dependen del equipo de seguridad y proveedores de alojamiento con calendarios propios, es lo que convierte un aviso de veinticuatro horas en un problema de semanas para una organización media.
La lectura operativa no es que la IA vaya a resolver la seguridad. Es que la IA ha abaratado encontrar fallos, y el trabajo que antes casi no existía, remediarlos a tiempo, pasa a decidir si una empresa acaba en la lista de víctimas. Black Kite (2026) contó 7.551 organizaciones publicadas como víctimas de ransomware en 2026, un 24,9% más que el año anterior. Cada fallo destapado alimenta esa máquina, y la máquina no distingue entre quien parcheó a tiempo y quien tenía la intención de parchear en cuanto acabara el sprint.
Cómo saber si tu web está expuesta
El inventario es la mitad del trabajo. Cinco preguntas lo ordenan.
- Qué versión de PHP sirve cada entorno. No la que dice la documentación: la que responde el servidor. Entornos públicos, staging olvidados, contenedores antiguos y aquel gestor de contenidos que nadie toca desde 2023.
- Si hay alguna entre 8.2 y 8.5 por debajo de la versión corregida de su rama. 8.2.35, 8.3.36, 8.4.27 y 8.5.12 son el corte (Huntress, 2026). Lo que esté por debajo, expuesto.
- Qué gestiona el hosting y qué gestionáis vosotros. En alojamiento compartido o gestionado, el motor PHP lo actualiza el proveedor. La pregunta no es si existe el parche, sino cuándo lo aplica y si avisa a los clientes, porque el calendario del proveedor y su política de avisos deciden aquí más que tu propia documentación de infraestructura.
- Qué pasa con WordPress y demás CMS. La vulnerabilidad está en el motor PHP, no en el CMS ni en sus plugins: actualizar plugins no parchea php2shell. El sitio queda cubierto cuando el servidor sirve una versión corregida, ni un minuto antes, y conviene pedir por escrito al proveedor la versión que sirve hoy y la fecha compromiso de actualización.
- Qué corre en ramas sin soporte, como PHP 7. Esas versiones no reciben este parche ni van a recibirlo. El riesgo acumulado no tiene fecha de caducidad y la salida razonable es planificar la migración.
Qué hacer esta semana
- Actualizar a las versiones corregidas en todas las superficies inventariadas, empezando por las expuestas a internet. CISA (2026) no matiza el orden: pide inmediatez. Sin ventana de gracia.
- Si alguna superficie no se puede tocar todavía, reducirla o aislarla mientras el parche llega, y vigilar qué le llega.
- Una vez parcheado, rotar credenciales, claves de API y secretos que vivían en el servidor, y revisar los logs de acceso y de ejecución en busca de webshells: cuando la ejecución ha sido posible sin autenticación, el parche cierra la puerta pero no mira quién entró antes. Es la parte que más equipos se saltan, y la que diferencia un cierre limpio de un incidente latente que revive en enero.
- Verificar con una prueba externa. Un parche aplicado es una afirmación; una prueba que intenta explotar la superficie y no puede es un hecho, y conviene que la ejecute alguien que no sea quien aplicó el parche, porque auditar el propio trabajo con las propias manos es la manera más cómoda de no encontrar nada. Es la misma lógica del red teaming: comprobar por ataque, no por declaración.
Y si la organización está sujeta a regulación, la gestión de estas vulnerabilidades no es una buena práctica voluntaria sino una obligación con nombre, como detalla nuestra guía de qué es la directiva NIS2 y la pieza de requisitos del Esquema Nacional de Seguridad.
El cuello de botella no es el parche, es quién lo aplica
El parche es gratuito. El tiempo, no. Lleva publicado días, y lo escaso es el tiempo de la gente capaz de inventariar entornos, actualizar motores, revisar logs y firmar que la superficie quedó cerrada. Y España no llegaba holgada a este octubre: NTT DATA (2026) contó 879 incidentes graves en el primer semestre de 2026, frente a 605 el semestre anterior, un 45% más. Cuando ese trabajo se acumula, aparece la cuenta que nadie presupuestó: horas de plataforma, horas de desarrollo y horas de revisión, todas compitiendo con el roadmap que ya estaba comprometido antes del martes.
El mercado laboral ya acusaba la tensión antes del evento. Según el análisis de mercado de Shakers, 2.003 de las 42.817 ofertas de tecnología activas en España el 26 de octubre de 2026 mencionan ciberseguridad, cerca del 5% del total, y no como responsabilidad secundaria de perfiles vecinos sino como requisito explícito en la descripción. Cuando un martes aparecen dos CVE con parche urgente, esa demanda no espera al ciclo anual de plantilla: se cubre con capacidad que empiece esta semana, no con una vacante aprobada para el trimestre que viene.
Para el inventario y el parcheado, formar equipo con un PHP developer senior que haya pasado por actualizaciones masivas es la vía rápida. Para lo que viene después, colaborar con un experto en ciberseguridad que audite la superficie y firme lo que quedó cerrado. Perfiles por proyecto, condiciones validadas y sin ampliar plantilla, que es la diferencia entre cubrir una emergencia de dos semanas y cargar un coste fijo de enero a diciembre.
Preguntas frecuentes sobre php2shell
- ¿Qué versiones de PHP son seguras después de php2shell?
Las publicadas el 21 de octubre de 2026: 8.5.12, 8.4.27, 8.3.36 y 8.2.35, cada una en su rama. Cualquier entorno con una versión anterior de PHP 8.2 a 8.5 sigue expuesto a los dos CVE, y las ramas sin soporte, como PHP 7, no tienen parche.
- ¿WordPress está afectado por php2shell?
La vulnerabilidad está en el motor PHP, no en WordPress ni en sus plugins. Un sitio sobre WordPress queda cubierto cuando el hosting o el servidor sirven una versión corregida de PHP. Actualizar plugins y temas no sustituye a ese parche.
- ¿Qué significa que sea un RCE sin autenticación?
Que un atacante puede lograr que el servidor ejecute código suyo sin usuario, contraseña ni sesión previos. No requiere credenciales robadas ni acceso inicial: basta con alcanzar la URL expuesta, y por eso se presta a campañas automáticas y masivas.
- ¿Se está explotando ya?
Sí. CISA pidió aplicar el parche de inmediato el 21 de octubre de 2026, y en las horas posteriores a la publicación de los detalles ya se registraban intentos de explotación masivos sobre sitios sin actualizar (Help Net Security, 2026).
- ¿Qué hago si no puedo actualizar esta semana?
Reduce la superficie expuesta mientras tanto: limita el acceso a los endpoints afectados, vigila qué les llega y ponle fecha cierta al parche. Y si el sistema corre una rama sin soporte, el parche nunca llegará: la salida es planificar la migración de versión.
