El 21 de octubre de 2026 el equipo de PHP publicó una actualización de emergencia que arregla dos fallos críticos conocidos ya como PHP2Shell. No es un aviso de seguridad más: es de las que saltan a prensa generalista, con alerta de CISA en EE. UU. y declaración conjunta de ENISA, la Comisión Europea, CERT-EU y Europol en Europa.
Si tienes una web hecha con WordPress, PrestaShop o cualquier sistema que corra en PHP —y casi todas corren en PHP—, esto te afecta aunque nunca hayas escrito una línea de código.
Qué es exactamente PHP2Shell
Son dos vulnerabilidades del motor PHP, no de ningún CMS ni plugin en concreto:
- CVE-2026-109618: corrupción de memoria cuando una petición alcanza el límite de memoria en el momento justo equivocado. PHP puede dejar datos internos a medio inicializar y luego tratarlos como válidos.
- CVE-2026-109619: estado global obsoleto. Tras un error fatal, un worker puede reutilizar memoria de una petición anterior que ya se había liberado.
Las dos comparten CVSS 9,2 (crítico) y el mismo efecto: un atacante sin usuario ni contraseña puede ejecutar código en tu servidor. En Apache con mod_php se demostró que una única petición, antes de que tu aplicación ejecute nada, basta para el ataque.
De ahí el nombre: de PHP a Shell. Del servidor a las manos del atacante sin pasar por el login.
Por qué esta vez es distinta
- Hay explotación real. La red de honeypots de watchTowr detectó intentos de explotación el mismo día del parche. No es teoría.
- El fallo está en el motor. No depende de que tengas un plugin desactualizado. Toca a PHP-FPM, Apache con mod_php, php-cgi, LiteSpeed y FrankenPHP: prácticamente todas las formas de servir PHP.
- La coordinación se torció. Los identificadores de los fallos se filtraron en foros el 20 de octubre, antes de tiempo y con datos erróneos (se hablaba de CVSS 10,0; el real es 9,2). El equipo de PHP adelantó su aviso y sacó los parches al día siguiente.
- Los organismos lo han puesto encima de la mesa. CISA, ENISA y el resto de CERTs europeos piden parchear de inmediato los sistemas expuestos a internet.
Qué versiones lo arreglan
Las versiones corregidas son:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Todo lo anterior a esas versiones, dentro de cada rama, es vulnerable. Y ojo con la parte difícil: PHP 8.1 y anteriores no tienen parche oficial, porque ya están fuera de soporte. Si tu web corre sobre una de esas versiones, el problema no se arregla con un clic: o tu proveedor aplica un parche propio de la distribución, o toca migrar.
¿Y WordPress, PrestaShop, Laravel?
Todos comparten el mismo motor debajo. Escanear plugins y actualizar el CMS está bien, pero no arregla esto: el fallo está una capa por debajo de tu aplicación, en el propio PHP.
La consecuencia práctica: quien tiene que actualizar es quien gestiona el servidor. En un hosting compartido, el proveedor. En un VPS propio, tú. El CMS no puede parchear lo que no gestiona.
¿Mi web está afectada?
Si tu web vive en un hosting compartido (Plesk, cPanel, DinaServer, SiteGround y similares), la respuesta corta es: depende de tu proveedor. La pregunta correcta no es «¿mi WordPress está parcheado?» sino «¿qué versión de PHP sirve mi web y está entre las corregidas?».
Si tienes VPS o servidor propio, eres tú quien tiene que actualizar hoy. Y si no sabes dónde vive tu web ni quién gestiona su servidor, ese ya es el primer problema que conviene arreglar.
Qué hacer hoy mismo
- Hosting compartido: abre ticket o llama preguntando si tu cuenta ya corre una versión corregida (8.2.35 o superior). Un proveedor serio lo habrá hecho o te dará fecha concreta.
- VPS o servidor propio: actualiza el paquete de PHP, reinicia los workers (php-fpm o Apache) y comprueba la versión con `php -v`.
- Si no puedes actualizar hoy: los organismos recomiendan aislar de internet lo que no se pueda parchear y, como medida parcial, un WAF. No es sustituto del parche: el propio equipo de PHP lo dice claro, ningún cambio de configuración mitiga del todo.
- Vigila señales: procesos de PHP que lanzan shells o descargan binarios, ficheros nuevos donde no toca, tareas programadas que no reconoces.
Lo que no hay que hacer
No vale «ya lo miramos la semana que viene». Cuando circulan pruebas de concepto, la ventana entre el parche y la explotación masiva se mide en horas, y en este caso los hay.
Tampoco hay que entrar en pánico ni tirar la web abajo por si acaso. Es un parche concreto con versiones concretas. Lo que pide la situación es orden: saber qué versión corre tu web, actualizar si toca y dejar escrito el procedimiento para la próxima.
La semana que viene publicamos la guía práctica: cómo saber en cinco minutos qué versión de PHP usa tu web, cómo actualizarla sin romperla y cómo revisar que nadie ha entrado ya.
Y si tu web depende de un servidor que nadie mira, ese es exactamente el tipo de problema que automatizamos: automatizaciones a medida con alertas y mantenimiento. O escríbenos desde contacto y te miramos la versión de PHP hoy mismo.