PHP2Shell: los dos fallos críticos de PHP y cómo protegerte

Si tienes una web hecha con PHP (y si es un WordPress, la tienes), deja lo que estés haciendo y lee esto. El 21 de octubre el proyecto PHP publicó un parche de emergencia para dos fallos que permiten a cualquiera ejecutar código en tu servidor sin iniciar sesión. Sin usuario, sin contraseña, sin nada.

Y no es un riesgo teórico. Cloudflare ya ha visto tráfico de ataque contra sus clientes, porque la vulnerabilidad se filtró antes de la fecha oficial del parche. Los investigadores la han bautizado PHP2Shell, que dicho en cristiano es “de PHP a una consola en tu servidor”.

Llevo treinta años programando y PHP ha pasado por mis manos más veces de las que me gustaría admitir. Así que vamos al grano: qué es, a quién afecta y qué tienes que hacer hoy.

Qué ha pasado exactamente

El 20 de octubre el equipo de seguridad de PHP avisó de que al día siguiente, a las 14:00 UTC, publicaría una versión de seguridad crítica. Y la publicó. Según el aviso de INCIBE, son dos vulnerabilidades del núcleo de PHP, las dos con una puntuación CVSS de 9,2 sobre 10:

• CVE-2026-109618: ejecución remota de código por corrupción de memoria cuando PHP se queda sin memoria a mitad de una petición. Uno de los caminos para provocarlo son los envíos de formularios con muchos campos o adjuntos (peticiones POST multipart).
• CVE-2026-109619: ejecución remota de código por usar un estado interno que se ha quedado viejo entre una petición y la siguiente. Depende de un error fatal o de una operación de sesión, y de que el mismo proceso de PHP atienda peticiones seguidas.

No te voy a mentir: los detalles técnicos son de los que hay que leer dos veces. Lo importante es la consecuencia, y la consecuencia es que un atacante desde fuera puede acabar ejecutando lo que quiera con los permisos de tu web.

Un detalle curioso que recoge Snyk: los fallos se encontraron con ayuda de Inteligencia Artificial, en un lenguaje que lleva tres décadas en producción.

A quién afecta

A casi todo el que sirve una web con PHP. El aviso oficial incluye las instalaciones que usan PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed, y señala que Apache con mod_php es el caso más expuesto.

Estas son las versiones que corrigen el fallo, una por rama:

Tu rama de PHP	Versión segura
8.5	8.5.12 o superior
8.4	8.4.27 o superior
8.3	8.3.36 o superior
8.2	8.2.35 o superior
8.1, 8.0 y 7.4	sin versión oficial, solo parches de código retroportados

Si estás en PHP 8.1 o anterior, el proyecto ya no saca versiones para esas ramas: ha publicado parches de código fuente, y algunas distribuciones o proveedores de soporte los aplican por su cuenta. Siendo realistas, si sigues en 7.4 en 2026, el problema no es este fallo, es todo lo demás.

Cómo saber si tu web está a salvo

Depende de cómo tengas montada la web:

• Hosting compartido o WordPress gestionado: entra en el panel (cPanel, Plesk o el de tu proveedor) y busca algo como “Versión de PHP” o “MultiPHP”. Apunta el número completo, por ejemplo 8.3.36, no solo “8.3”. Si el panel solo muestra la rama, pregunta a soporte si han aplicado la corrección del 21 de octubre. Es lo que recomienda también Xataka.
• Servidor propio: php -v en la terminal. Ojo, que la versión de la línea de comandos puede no ser la que usa el servidor web. Para ver esa, una página temporal con <?php phpinfo(); ?> te lo dice, pero bórrala nada más mirarla, que ese fichero enseña media vida de tu servidor a quien lo encuentre.
• Paquetes de tu distribución: las distribuciones de Linux recibieron los parches por adelantado y publican sus propias versiones. Puede que tu paquete no llegue a 8.3.36 pero lleve la corrección: mira el aviso de seguridad de tu distribución, no solo el número.

Qué hacer si no puedes actualizar hoy

La solución de verdad es actualizar, y no hay atajo que la sustituya. Dicho eso, el aviso oficial recoge medidas temporales que reducen los caminos de ataque conocidos, pero no los cubren todos:

• Para CVE-2026-109619: desactivar session.upload_progress.enabled y reiniciar los procesos de PHP. En PHP 8.5, desactivar también fatal_error_backtraces.
• Para CVE-2026-109618: el aviso propone configurar memory_limit=-1 de forma administrativa y comprobar que ninguna aplicación lo vuelve a cambiar. Es una medida con su propio riesgo (sin límite de memoria, un proceso descontrolado puede tumbar el servidor), así que no la dejaría puesta ni un día más de lo necesario.
• Si tu web está detrás de Cloudflare, sus reglas de cortafuegos (WAF) ya bloquean los intentos conocidos, según cuenta la propia Cloudflare, siempre que no hayas cambiado el nombre del campo de progreso de subida (session.upload_progress.name). Y aun así insisten en que actualices.

Y esconder los avisos con error_reporting o display_errors no sirve de nada contra el segundo fallo. Lo dice el aviso, y lo repito porque es la típica “solución” que se le ocurre a cualquiera.

Por qué esto es más serio que otras veces

Cada pocos meses sale “una vulnerabilidad crítica en X” y la gente se acostumbra a ignorarlas. Esta tiene tres ingredientes que la hacen distinta: no hace falta autenticarse, afecta a casi cualquier web con PHP y ya hay ataques. Según Xataka, los investigadores han confirmado la ejecución remota de código contra Magento 2, una plataforma de tiendas online muy extendida.

Y eso, en mi experiencia, significa que en las próximas semanas veremos bots probando el fallo contra todo lo que tenga pinta de PHP. Las webs que no se actualicen van a caer por pura estadística.

Si llevas la web de tu negocio y no tienes claro si tu proveedor ha hecho los deberes, cuéntame tu situación.

Preguntas frecuentes

¿Mi WordPress está afectado por PHP2Shell?

Si tu WordPress funciona con una versión de PHP anterior a las corregidas (8.5.12, 8.4.27, 8.3.36 o 8.2.35), sí. El fallo está en PHP, no en WordPress, así que lo que hay que actualizar es la versión de PHP del servidor. En un hosting compartido, pregunta a soporte si han aplicado el parche del 21 de octubre.

¿Hace falta que el atacante tenga usuario en mi web?

No. Los dos fallos permiten ejecutar código sin autenticarse, y por eso tienen una puntuación tan alta.

¿Basta con tener Cloudflare delante?

Ayuda, pero no basta. Cloudflare bloquea los intentos conocidos si usas el nombre por defecto del campo de progreso de subida, y aun así recomienda actualizar PHP. Las reglas cubren ataques conocidos, no todas las variantes posibles.

Estoy en PHP 7.4 u 8.1, ¿qué hago?

Esas ramas ya no tienen versiones oficiales. PHP ha publicado parches de código fuente que algunos proveedores aplican, pero lo sensato es planificar el salto a una rama mantenida (8.2 o superior) cuanto antes.

Fuentes

• INCIBE-CERT: Múltiples vulnerabilidades en PHP (actualización del 21 de octubre de 2026)
• PHP: aviso de seguridad del 21 de octubre de 2026
• Snyk: PHP patches critical unauthenticated RCEs
• Cloudflare: protección WAF frente a las vulnerabilidades de PHP
• Xataka: PHP2Shell, cómo comprobar que tu sitio es seguro

Compártelo si te ha resultado útil, sobre todo con quien te lleva la web.

¿Has comprobado ya qué versión de PHP tiene tu servidor? Cuéntame.

Y… a actualizar, que hoy no es día de dejarlo para mañana.