PHP2Shell es el nombre que se ha dado a dos vulnerabilidades críticas de PHP (CVE-2026-109618 y CVE-2026-109619, gravedad 9,2 sobre 10) publicadas el 21 de octubre de 2026. Permiten a un atacante ejecutar código en el servidor sin usuario ni contraseña, y afectan a todas las versiones de PHP desde la 5. Se corrigen solo actualizando PHP en el servidor a la 8.2.35, 8.3.36, 8.4.27 o 8.5.12: actualizar WordPress, el tema o los plugins no sirve. Las versiones 7.4, 8.0 y 8.1 no tienen versión corregida oficial, y según WordPress.org, más del 35 % de las webs WordPress siguen en una versión de PHP sin soporte. Hubo ataques reales antes incluso de que saliera el parche. En las webs que mantenemos, la versión del servidor se comprobó esa misma semana.
Qué es PHP y por qué te afecta aunque no sepas lo que es
PHP es el lenguaje de programación en el que están hechos WordPress, WooCommerce, Joomla, PrestaShop y buena parte de las webs de empresa que existen. Cuando alguien entra en tu web, el servidor ejecuta PHP para montar la página que ve. Según cálculos de la PHP Foundation recogidos por la prensa, alrededor del 70 % de las webs del mundo funcionan sobre PHP.
Si tu web está hecha con WordPress, tu web funciona con PHP. No tienes que haberlo instalado tú ni saber que existe: viene con el alojamiento (el hosting) que contrataste.
Y aquí está la clave de todo este artículo: PHP no se actualiza desde el panel de WordPress. Vive en el servidor, un nivel por debajo. Puedes tener WordPress, el tema y los veinte plugins en su última versión, con todos los avisos en verde, y que el servidor siga funcionando con un PHP vulnerable.
Qué ha pasado exactamente con PHP2Shell
La cronología, con las horas que publicaron los propios equipos de seguridad:
| Fecha (2026) | Qué pasó |
|---|---|
| 17 de octubre | Amazon detecta los primeros intentos de explotación, cuatro días antes del aviso público (según CSIRT de Chile). |
| 20 de octubre | Se filtra en un foro que van a publicarse dos fallos graves. El equipo de PHP adelanta el aviso y anuncia el parche para el día siguiente. CERT-EU, el equipo de ciberseguridad de las instituciones europeas, publica su alerta. |
| 21 de octubre, mañana | Cloudflare informa de ataques en marcha y activa reglas de protección para todos sus clientes, incluidos los gratuitos. |
| 21 de octubre, 13:35 UTC | PHP publica las versiones corregidas: 8.2.35, 8.3.36, 8.4.27 y 8.5.12. |
| 23 de octubre | PHP publica un aviso adicional sobre un tercer fallo relacionado (CVE-2026-115560), con una medida temporal de configuración hasta el siguiente parche. |
Un detalle que ha dado mucho que hablar: según la prensa, el fallo lo localizó una empresa de seguridad usando un modelo de inteligencia artificial para revisar el código de PHP. Es una señal de hacia dónde va esto. Si una IA puede encontrar fallos que llevaban años escondidos, los atacantes también pueden usarla, y el tiempo entre que se descubre un fallo y se explota en masa se acorta. En este caso fueron horas, no semanas.
Qué puede hacer un atacante con este fallo
En lenguaje llano: enviar una petición manipulada a tu web y conseguir que el servidor ejecute las órdenes que él quiera. Sin entrar al panel, sin adivinar contraseñas, sin que tengas ningún plugin raro instalado.
A partir de ahí, lo habitual en este tipo de ataques es:
- Dejar una "puerta trasera" (un archivo oculto) para volver cuando quiera, aunque luego actualices.
- Crear un usuario administrador nuevo en WordPress.
- Inyectar enlaces o páginas de spam que Google acaba detectando, con la consiguiente caída de posicionamiento.
- Redirigir a tus visitantes a webs fraudulentas.
- En tiendas online, robar los datos de clientes que haya en la base de datos.
- Usar tu servidor para enviar correo basura o atacar a otros, lo que suele terminar con el hosting suspendiendo tu cuenta.
Por qué "actualizar plugins" no te protege esta vez
La mayoría de los servicios de "mantenimiento WordPress" consisten en lo mismo: entrar al panel, pulsar "actualizar todo" y hacer una copia de seguridad. Está bien y hay que hacerlo, pero frente a PHP2Shell no cambia nada, porque el fallo no está en WordPress, sino en el motor que lo ejecuta.
Lo explicamos en detalle en el artículo sobre plugins peligrosos en WordPress: la mayoría de vulnerabilidades del día a día están en los plugins. PHP2Shell es la excepción que demuestra por qué el mantenimiento tiene que mirar también lo que hay debajo.
| Capa de tu web | Qué es | ¿Se actualiza desde WordPress? | ¿Afectada por PHP2Shell? |
|---|---|---|---|
| Plugins y tema | Las funciones y el diseño | Sí | No |
| WordPress (núcleo) | El gestor de contenidos | Sí | No |
| PHP | El lenguaje que lo ejecuta todo | No: se cambia en el panel del hosting o lo hace el proveedor | Sí |
| Servidor (sistema operativo, Apache, LiteSpeed…) | La máquina y su software | No | Depende de la configuración |
El problema de fondo: las versiones viejas de PHP
Aquí está lo que de verdad importa para una pyme, y lo que casi ningún aviso explica bien.
PHP tiene "ramas" (7.4, 8.0, 8.1, 8.2, 8.3…). Cada rama recibe parches de seguridad durante un tiempo y después se abandona. Lo normal en un hosting compartido es que el proveedor aplique los parches dentro de la rama que tienes elegida, pero que la rama la elijas tú (o quien te montó la web) en el panel del hosting. Si nadie la cambió nunca, sigue la que se puso el día que se creó la web.
Y aquí viene el problema:
- PHP 8.2, 8.3, 8.4 y 8.5 tienen versión corregida. Si tu hosting es serio, ya la habrá aplicado.
- PHP 7.4, 8.0 y 8.1 ya no tienen soporte oficial. El equipo de PHP solo publicó un parche "en código fuente" para quien compila PHP por su cuenta, algo que un hosting compartido normal no hace. Algunos proveedores lo aplican por su cuenta y otros no.
- PHP 7.3 y anteriores: sin corrección de ningún tipo.
¿Cuántas webs están en esa situación? Según las estadísticas de WordPress.org, el 35,1 % de las webs WordPress funcionan con una versión de PHP sin soporte, y un 16,5 % siguen en PHP 7.4. En los recuentos de servidores expuestos a internet publicados durante la crisis, el 59 % de los que muestran su versión de PHP usaban una rama sin parche oficial.
¿Por qué hay tantas webs en versiones antiguas? Casi nunca es dejadez del propietario. Es que cambiar de rama de PHP puede romper la web. Un tema de hace cinco años o un plugin abandonado pueden dejar de funcionar en PHP 8.3, y la web aparece en blanco. Así que quien la montó la dejó en la versión en la que funcionaba, y nadie volvió a tocarla. El riesgo se va acumulando en silencio hasta que llega un PHP2Shell.
Fecha a apuntar: PHP 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si tu web está hoy en 8.2 está protegida contra PHP2Shell (con la 8.2.35), pero dentro de dos meses estará en la misma situación que las webs en 8.1. El siguiente fallo grave ya no tendrá parche para ella.
Cómo saber si tu web está afectada (en 10 minutos)
No necesitas ser técnico para hacer estas comprobaciones.
1. Mira la versión de PHP desde WordPress. Entra al panel de WordPress → Herramientas → Salud del sitio → pestaña Información → apartado Servidor. Ahí aparece la "versión de PHP". Si WordPress además te muestra un aviso de "tu sitio usa una versión obsoleta de PHP", tómalo en serio.
2. Compárala con esta tabla.
| Versión que ves | Situación frente a PHP2Shell |
|---|---|
| 8.5.12 o superior · 8.4.27 o superior · 8.3.36 o superior | Corregida |
| 8.2.35 o superior | Corregida, pero sin soporte a partir del 1 de enero de 2027 |
| 8.2, 8.3, 8.4 o 8.5 con un número inferior a los de arriba | Vulnerable: tu hosting no ha aplicado el parche. Contacta con ellos hoy. |
| 8.1, 8.0, 7.4 o anterior | En riesgo: no hay versión oficial corregida. Hay que cambiar de rama. |
3. Pregunta a tu proveedor de hosting, por escrito. Algo tan sencillo como: "¿Habéis aplicado los parches de PHP del 21 de octubre de 2026 (CVE-2026-109618 y CVE-2026-109619) en mi servidor?". Un buen proveedor te contestará en el día. Algunos, como Kinsta, lo comunicaron públicamente. Si no sabes quién es tu proveedor o no tienes acceso al panel, ese ya es un problema que conviene resolver.
4. Busca señales de que alguien ha entrado. Los ataques empezaron antes del parche, así que estar actualizado hoy no garantiza que nadie haya entrado antes. Revisa:
- Usuarios administradores en WordPress que no reconozcas.
- Páginas, entradas o enlaces que no has creado tú.
- Avisos de Google Search Console sobre "problemas de seguridad" o "contenido pirateado".
- Correos rebotados o quejas de que tu dominio envía spam.
- Si tienes un plugin de seguridad como Wordfence, ejecuta un análisis completo: detecta archivos modificados.
Qué hacer según lo que encuentres
Si tu versión ya está corregida: perfecto. Aun así, revisa el punto 4 de arriba y comprueba que tienes copias de seguridad recientes guardadas fuera del propio servidor.
Si tu hosting no ha aplicado el parche: pídeselo. Si no lo hace en un plazo razonable, es un buen momento para plantearte cambiar de proveedor. Un hosting que tarda días en aplicar un parche crítico tardará lo mismo con el siguiente.
Si estás en PHP 8.1 o anterior: hay que cambiar a 8.3 o 8.4. El orden correcto es:
- Copia de seguridad completa (archivos y base de datos) guardada fuera del servidor.
- Actualizar WordPress, tema y plugins a su última versión, antes de cambiar PHP.
- Si el hosting lo permite, probar la nueva versión de PHP en una copia de la web (un entorno de pruebas) antes de tocar la real.
- Cambiar la versión de PHP en el panel del hosting.
- Revisar la web entera: páginas principales, formularios, carrito y pago si es una tienda.
- Si algo se rompe, volver a la versión anterior mientras se corrige el plugin o tema culpable, que suele ser uno solo.
Si un plugin o tema no funciona en ninguna versión moderna de PHP, es una señal clara de que está abandonado y hay que sustituirlo, por seguridad y no solo por este fallo.
Qué hicimos en las webs que mantenemos
La semana del aviso revisamos todas las webs con PHP que tenemos en mantenimiento, incluida la de Coaching for Business, la web WordPress del caso real de rendimiento que ya hemos contado en este blog. La revisión fue la misma que te proponemos arriba:
- Versión de PHP que sirve realmente la web, no la que dice el panel. Hoy Coaching for Business responde con PHP 8.2.35, la versión corregida.
- Comparación con las copias de seguridad anteriores al aviso: archivos nuevos, archivos modificados y fechas de modificación. Los ataques empezaron antes del parche, así que no basta con actualizar: hay que comprobar que nadie dejó nada dentro antes.
- Copia de seguridad reciente antes de cualquier cambio.
Y queda un paso que la mayoría de las webs en 8.2 no tienen en el calendario: pasar a PHP 8.3 o superior antes del 31 de diciembre, cuando la rama 8.2 deja de recibir parches. Es exactamente el tipo de tarea que se olvida si nadie la tiene anotada.
¿Y la propia web de Kronexia? kronexia.com no usa PHP: es una web estática, construida con otra tecnología (te lo contamos en por qué migramos de WordPress a una web moderna), así que PHP2Shell no le afectaba. No significa que WordPress sea una mala opción. Para muchas empresas sigue siendo la mejor, y la mayoría de las webs que mantenemos lo son. Significa que cada tecnología tiene su propio mantenimiento, y hay que saber cuál es el de la tuya.
Lo que este fallo enseña sobre el mantenimiento web
PHP2Shell no es el primer fallo grave ni será el último. Lo que deja claro es la diferencia entre dos tipos de mantenimiento:
| Mantenimiento "de botón" | Mantenimiento de verdad |
|---|---|
| Pulsa "actualizar todo" una vez al mes | Actualiza, pero antes hace copia y después comprueba que todo funciona |
| Solo mira el panel de WordPress | Mira también el servidor: versión de PHP, hosting, certificados |
| Reacciona cuando la web ya está caída | Sigue los avisos de seguridad y actúa el mismo día |
| No sabe qué versión de PHP tienes | Sabe la versión, cuándo deja de tener soporte y tiene anotado el cambio |
| Te manda un "todo correcto" | Te explica qué se ha hecho y qué queda pendiente |
Este fallo, además, añade un elemento nuevo: si la inteligencia artificial acelera la búsqueda de vulnerabilidades, veremos más avisos como este y con menos margen de reacción. Contar con alguien que esté pendiente deja de ser un extra y pasa a formar parte de tener una web.
Si quieres que alguien se ocupe de esto por ti, en mantenimiento web WordPress explicamos qué incluye el nuestro. Y si solo quieres saber cómo está tu web hoy, escríbenos y te lo decimos.
Preguntas frecuentes sobre PHP2Shell
¿Qué es PHP2Shell?
Es el nombre popular de dos vulnerabilidades críticas de PHP, CVE-2026-109618 y CVE-2026-109619, publicadas el 21 de octubre de 2026 con una gravedad de 9,2 sobre 10. Permiten a un atacante sin credenciales ejecutar código en el servidor enviando una petición web manipulada. El riesgo es mayor en servidores que usan PHP como módulo de Apache (mod_php), aunque afecta también a otras configuraciones.
¿Mi web WordPress está afectada?
Si tu web funciona con una versión de PHP anterior a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, sí. Puedes verlo en WordPress → Herramientas → Salud del sitio → Información → Servidor. Las webs en PHP 8.1, 8.0, 7.4 o anteriores no tienen versión oficial corregida y deberían pasar a una rama con soporte.
¿Se arregla actualizando WordPress o los plugins?
No. El fallo está en PHP, el lenguaje que ejecuta WordPress, y PHP se actualiza en el servidor: lo hace el proveedor de hosting o se cambia desde su panel. Mantener WordPress y los plugins al día sigue siendo necesario para otros fallos, pero no corrige este.
¿Qué hago si mi hosting no me deja cambiar la versión de PHP?
Pregunta al proveedor si ha aplicado los parches por su cuenta. Algunos lo hacen incluso en versiones antiguas. Si no lo ha hecho y no ofrece versiones modernas de PHP, es motivo suficiente para cambiar de hosting: el siguiente fallo crítico te dejará igual de expuesto.
¿Puede romperse mi web al cambiar de versión de PHP?
Puede, sobre todo si usa un tema o plugins antiguos sin mantenimiento. Por eso hay que hacer antes una copia de seguridad completa, actualizar todo lo demás y, si es posible, probar en una copia de la web. Si algo falla, se vuelve a la versión anterior mientras se corrige o sustituye el elemento incompatible.
¿Cómo sé si alguien entró en mi web antes de que se aplicara el parche?
Revisa si hay usuarios administradores desconocidos, contenido o enlaces que no has puesto tú, avisos de seguridad en Google Search Console o quejas de spam desde tu dominio. Un plugin de seguridad como Wordfence puede detectar archivos modificados. Si encuentras algo, no basta con actualizar: hay que limpiar la web y cambiar todas las contraseñas.
¿Hasta cuándo es segura la versión 8.2 de PHP?
PHP 8.2.35 corrige PHP2Shell, pero la rama 8.2 deja de recibir parches de seguridad el 31 de diciembre de 2026. Si tu web está en 8.2, conviene planificar el paso a 8.3 o 8.4 en las próximas semanas, sin esperar al siguiente aviso.
¿Las webs que no usan PHP están a salvo de este fallo?
De este fallo concreto, sí. Las webs estáticas o hechas con otras tecnologías no ejecutan PHP. Pero eso no las libra de tener su propio mantenimiento: dependencias, hosting, dominio y certificados también necesitan revisión. Ninguna tecnología es "sin mantenimiento".
Fuentes: aviso de seguridad oficial de PHP (21 y 23 de octubre de 2026), alerta de CERT-EU y análisis de CybelAngel con datos de WordPress.org y Shodan.