El 21 de octubre de 2026 el equipo de seguridad de PHP publicó los parches para las dos vulnerabilidades críticas de ejecución remota de código, conocidas como PHP2Shell (CVE-2026-109618 y CVE-2026-109619). PHP las califica con 9.2 sobre 10 en la escala CVSS v4.0, un atacante no necesita tener acceso previo para explotarlo. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
¿Qué es PHP2Shell?
PHP2Shell es el nombre con el que se conoce a dos fallas de PHP que permiten ejecutar comandos en un servidor desde una sola petición web. El nombre alude a la shell, es decir, el acceso de terminal al sistema operativo, quien la obtiene puede ejecutar cualquier comando con los permisos de la cuenta que corre el servicio web.
Según el aviso de PHP, las dos fallas tienen un origen parecido: la memoria de PHP puede quedar en estado corrupto cuando una petición termina de forma anormal. CVE-2026-109618 permite ejecutar código con los permisos del proceso web. CVE-2026-109619 permite usar memoria ya liberada, leer memoria que no corresponde y también ejecutar código sin autenticación. La firma watchTowr las puntúa con 10,0.
¿A quiénes afecta?
Afecta a toda instalación de PHP que atienda peticiones web como PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El propio equipo de PHP indica que el riesgo es mayor en mod_php, donde una petición sin autenticación puede disparar el ataque antes de que se ejecute código de la aplicación.
Sistemas como WordPress, Magento, WooCommerce, Drupal, Joomla y MediaWiki que son los más usados tienen un mayor alcance de explotación. Según VirusTotal, hay más de 5,1 millones de hosts PHP expuestos en internet.
En cuanto a versiones, Wiz sitúa el origen del problema en PHP 5.4 y el aviso de PHP considera afectadas todas las versiones anteriores a las corregidas.
¿Cómo se filtró antes de tiempo?
La divulgación coordinada estaba pensada para después del parche, pero la noticia se filtró en Hacker News y empezaron a circular exploits y explicaciones técnicas antes de tiempo. PHP había avisado a los administradores, dos días antes, que se prepararan para instalar los parches apenas estuvieran listos.
El 21 de octubre los avisos de seguridad aparecieron en GitHub a las 13:34 UTC (10:34 en Argentina), 26 minutos antes de la hora anunciada de las 14:00 UTC (11:00 en Argentina). Poco después, PHP actualizó su sitio con los parches. Las vulnerabilidades fueron descubiertas de forma independiente por la firma Calif, en el marco del proyecto “Patch the Planet” de OpenAI, y por Wiz.
¿Ya se están explotando?
Cloudflare informó que observó ataques tempranos contra ambas vulnerabilidades, incluso con reglas de WAF activas que bloquean los métodos conocidos y advirtió que esa protección es temporal. Otras fuentes no coinciden sobre si hay explotación confirmada, así que lo más prudente es asumir que sí la hay y actuar rápidamente.
El NCSC del Reino Unido pidió a las organizaciones actualizar de inmediato o si no pueden hacerlo considerar desconectar los sistemas afectados. Cloudflare desplegó reglas de WAF para los vectores conocidos, disponibles para todos sus clientes incluso los del plan gratuito.
¿Cómo me protejo?
La solución real es actualizar PHP a una versión corregida:
| Rama de PHP | Versión corregida |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
Para PHP 7.4, 8.0 y 8.1, que ya no reciben actualizaciones, el equipo de seguridad de PHP publicó solo parches mínimos de código fuente pensados para quienes compilan PHP o no cuentan con un proveedor de soporte extendido. Si usás una de esas versiones, consultá si tu distribución o proveedor ofrece un parche propio. Quienes usan el repositorio de Remi (rpms.remirepo.net) no van a tener actualizaciones ese día y deberían pasar a los paquetes de su distribución o compilar desde el código fuente.
Si todavía no podés actualizar PHP, el equipo propone medidas temporales que reducen el riesgo, pero no lo eliminan:
- Para CVE-2026-109618: fijar
memory_limit=-1de modo que las aplicaciones no puedan cambiarlo, usar unpost_max_sizebajo (8M, o 32M si necesitás subir archivos) y aplicar límites de contenedor o cgroup. - Para CVE-2026-109619: poner
session.upload_progress.enabled=0y reiniciar los procesos de PHP, además en la versión 8.5 tenés que cambiar afatal_error_backtraces=0.
Ocultar errores con display_errors, error_reporting o el operador @ no sirve como protección.
¿Qué está haciendo G2K?
En G2K la seguridad de tu servicio es una prioridad. Nuestro equipo técnico ya tiene cubiertas las distintas plataformas que ofrecemos a nuestros clientes y seguimos atentos a cada actualización de PHP para aplicarla apenas esté disponible. Si tu hosting o servidor está gestionado por G2K, no necesitás hacer nada. Y si tenés alguna duda sobre tu servicio, nuestro equipo de soporte está para ayudarte.