Vulnerabilidades de PHP en 2026: PHP2Shell, PHP 8.2 y cómo proteger tu web

¿Qué es PHP2Shell y a quién afecta?

PHP2Shell es el nombre con el que se conocen dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619. Las dos tienen una puntuación de 9,2 sobre 10 en la escala CVSS 4.0 y permiten la ejecución remota de código, es decir, que un atacante haga correr sus propias instrucciones en tu servidor (php.net).

Afectan a casi cualquier instalación de PHP que sirva páginas web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Según el aviso oficial, el riesgo es mayor con mod_php. El propio proyecto aclara que no hay una mitigación completa y que actualizar es la única opción segura (php.net).

Cloudflare informó que vio tráfico de ataque contra estos fallos y que activó reglas de protección en su firewall para todos los planes, incluido el gratuito, unas nueve horas antes de que los fallos se hicieran públicos (Cloudflare). Ese firewall ayuda, pero no reemplaza la actualización.

¿Qué versiones de PHP tienen soporte hoy?

Fuente: php.net, versiones con soporte. Cada versión tiene dos años de soporte activo y dos años más de parches de seguridad.

Hay algunos parches mínimos para 7.4, 8.0 y 8.1 publicados por la comunidad, y ciertos proveedores ofrecen soporte extendido. Son soluciones de transición y no un motivo para quedarse en esas versiones.

¿Cuántos sitios usan una versión vieja?

Más de los que parece. En enero de 2026, WordPress publicó qué versiones de PHP usaban sus instalaciones: un 22,2 % seguía en PHP 7.4 y un 27,3 % en PHP 8.2 (WordPress). Sumando las ramas 8.1 e inferiores, casi la mitad de los sitios WordPress de ese momento corría en versiones que ya no recibían parches. WordPress recomienda PHP 8.3 y, desde la versión 7.0, exige como mínimo PHP 7.4.

En la web en general, W3Techs estima que PHP se usa en el 69,2 % de los sitios cuyo lenguaje de servidor se puede identificar, y que un 34,3 % de ellos todavía usa PHP 7 o PHP 5 (W3Techs).

¿Cómo sé qué versión de PHP usa mi sitio?

1. En WordPress, entra en Herramientas > Salud del sitio > Información > Servidor. Ahí figura la versión de PHP.
2. En cPanel, busca Seleccionar versión de PHP o MultiPHP Manager.
3. Si no tienes acceso, pregúntale a tu proveedor de hosting: “¿Qué versión exacta de PHP usa mi sitio y ya tiene el parche del 21 de octubre de 2026?”.

Fíjate en el número completo. Por ejemplo, 8.3.36 está corregida y 8.3.30 no.

¿Qué hago si mi versión está desactualizada?

1. Haz una copia de seguridad completa (archivos y base de datos) y guárdala fuera del servidor.
2. Prueba la nueva versión en una copia del sitio antes de cambiarla en el sitio real. Los saltos grandes, como de 7.4 a 8.3, pueden romper plugins o temas viejos.
3. Actualiza WordPress, el tema y los plugins antes de cambiar PHP, porque las versiones nuevas suelen ser las compatibles.
4. Cambia la versión de PHP y revisa las páginas clave: inicio, formularios, carrito y panel.
5. Si algo falla, vuelve a la versión anterior desde el mismo panel y corrige el plugin o el tema que dio error.

Si tu sitio está en 8.2 y funciona bien, actualízalo ahora a 8.2.35 y planifica el paso a 8.3 o 8.4 antes de fin de año.

¿Qué más puede dejar mi web expuesta?

La versión de PHP es una parte del problema. En los sitios WordPress, la mayoría de las vulnerabilidades que se publican cada año están en plugins y temas, no en el núcleo. Estos son los riesgos que la guía OWASP Top 10 de 2025 señala como más comunes en aplicaciones web (OWASP):

• Plugins, temas y librerías con fallos conocidos (fallos en la cadena de suministro). Un plugin abandonado puede quedar sin parche para siempre.
• Contraseñas débiles y cuentas sin doble verificación (fallos de autenticación).
• Formularios que aceptan cualquier archivo, que pueden usarse para subir código al servidor.
• Inyección SQL y XSS, cuando el código no valida lo que escribe el visitante.
• Configuración insegura, como mostrar errores en pantalla o permisos de archivos demasiado abiertos.

Lista de revisión para tu sitio

• Versión de PHP corregida (8.5.12, 8.4.27, 8.3.36 u 8.2.35 o posterior) y plan para dejar 8.2 antes del 31/12/2026.
• Copias de seguridad automáticas fuera del servidor, con una restauración probada.
• Plugins y temas actualizados. Borrar los que no se usan y los que llevan más de un año sin actualizarse.
• Nunca instalar plugins o temas “nulled” (versiones pagas pirateadas).
• Doble verificación (2FA) para administradores, contraseñas únicas y cuentas viejas eliminadas.
• Un firewall de aplicaciones web delante del sitio, como el de Cloudflare o el de tu hosting.
• Errores de PHP ocultos en producción, ejecución de PHP bloqueada en la carpeta de subidas y el editor de archivos de WordPress desactivado.
• Alguien responsable de aplicar parches críticos en menos de 24 horas.

Preguntas frecuentes