php2shell: la vulnerabilidad crítica de PHP que se filtró antes del parche

21 de octubre de 2026

El martes 20 de octubre a la mañana apareció un post en Hacker News anunciando que dos vulnerabilidades críticas de PHP estaban a punto de hacerse públicas. Lo bajaron rápido, pero las capturas ya circulaban, junto con una imagen de una herramienta de explotación llamada PHP2Shell. Ese mismo día, el equipo de PHP confirmó en su sitio que publicaría una actualización de seguridad crítica el miércoles 21 a las 14:00 UTC (11:00 de Argentina). Hoy salió el aviso oficial, con un título que no deja lugar a dudas: "Critical remote code execution vulnerabilities, update now". Para ese momento ya había atacantes probando sitios en todo el mundo. No es una falla de WordPress, de Laravel ni de un plugin puntual: está en el núcleo del lenguaje. Eso significa que cualquier servidor web que ejecute PHP está potencialmente expuesto, sin importar qué framework o CMS corra encima.

Qué se sabe de las dos fallas

Según el aviso oficial de PHP, las dos fallas permiten ejecutar código de forma remota sin autenticarse:

CVE-2026-109618, "RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w): cuando PHP se queda sin memoria (out-of-memory), el manejo de ese error puede interrumpir el proceso mientras los datos internos de la petición están inicializados a medias. Después, la limpieza de la petición trata esos datos inválidos como si fueran válidos.
CVE-2026-109619, "RCE via stale global state" (GHSA-6wmf-4rv5-p3rp): un estado interno de una petición puede sobrevivir después de que se liberó la memoria que lo respaldaba, y una petición posterior atendida por el mismo proceso puede usarlo antes de que se reinicie.

PHP calificó a las dos con 9,2 sobre 10 en CVSS v4.0, la categoría crítica (algunos reportes iniciales hablaban de un 10, pero el puntaje oficial es 9,2). El detalle más incómodo lo aclara el propio equipo de PHP: el riesgo es mayor con mod_php, donde ya hay un exploit demostrado en el que una petición sin autenticar dispara el ataque antes de que se ejecute cualquier línea de código de la aplicación. Por eso no importa qué tan bien esté escrito tu sistema: la falla se dispara antes de llegar a él.

A quién afecta

El aviso oficial dice que están afectadas todas las instalaciones de PHP que atienden peticiones web, incluidas PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Y el problema viene de lejos: Sansec habla de todas las versiones desde PHP 5.4, y el NCSC del Reino Unido, de "PHP 5 en adelante". Eso incluye prácticamente todo WordPress, WooCommerce, Drupal, Magento, Joomla y cualquier aplicación Laravel o PHP a medida que esté expuesta a internet. Las versiones corregidas son:

PHP 8.5 → 8.5.12
PHP 8.4 → 8.4.27
PHP 8.3 → 8.3.36
PHP 8.2 → 8.2.35

El problema más serio lo tienen los servidores viejos. PHP ya no da soporte a la versión 8.1 ni a las anteriores, así que no hay versiones oficiales nuevas para ellas. El equipo publicó el código del parche adaptado a 7.4, 8.0 y 8.1, pero aplicarlo implica compilar PHP a mano o depender de que tu distribución o proveedor lo haga. Y en la práctica, mucho hosting compartido, sistemas internos y sitios "que nadie toca desde hace años" siguen corriendo justamente esas versiones.

Ya hay ataques en curso

Acá las fuentes no coinciden del todo, y vale la pena decirlo. watchTowr, que logró reproducir una de las fallas en laboratorio, todavía no había registrado explotación real al momento de su última actualización, y Huntress tampoco la había visto el 20 de octubre. Pero el 21 a la mañana, Cloudflare informó que ya veía ataques tempranos contra sitios PHP y desplegó reglas de firewall para todos sus planes, incluido el gratuito. Patchstack, por su parte, recibió reportes de intentos de explotación activa de varios proveedores de hosting. Sansec estimó que los ataques masivos iban a arrancar a los 15 minutos de publicado el parche, porque comparar el código antes y después de la corrección le da a cualquier atacante el mapa exacto de dónde está la falla. Varios sitios importantes de Países Bajos, entre ellos el del Parlamento y el del propio NCSC neerlandés, se desconectaron preventivamente el 21 de octubre.

Qué hacer hoy, en orden

El propio equipo de PHP lo dice sin vueltas: "no hay mitigaciones completas, actualizar es la única opción segura". Todo lo demás sirve para ganar tiempo:

Hacer inventario. Identificar cada instalación de PHP que tengas: producción, staging, contenedores, el panel de hosting, ese sistema interno viejo y el software de terceros que trae PHP incluido.
Actualizar a la versión parcheada de tu rama (8.5.12, 8.4.27, 8.3.36 u 8.2.35). Las distribuciones de Linux y los proveedores con soporte extendido recibieron los parches por adelantado, así que conviene revisar si tu sistema o tu hosting ya tienen el paquete actualizado.
Si no podés actualizar ya, poné el sitio detrás de un WAF o CDN (como Cloudflare) y restringí el servidor de origen para que solo acepte tráfico de ese proveedor.
Como medida temporal, aplicá las mitigaciones del aviso oficial en php.ini, en el pool de FPM o en la configuración de Apache (no sirven ini_set() ni .user.ini), y reiniciá todos los workers:
Ini
```
; CVE-2026-109619
session.upload_progress.enabled = 0
; CVE-2026-109618
memory_limit = -1
post_max_size = 8M   ; 32M si el sitio necesita subir archivos
```
En PHP 8.5 también se recomienda fatal_error_backtraces = 0. PHP aclara que estas medidas reducen la exposición a ciertos caminos de ataque, pero no dejan la instalación segura, y que ocultar errores con display_errors o @ no ayuda.
En casos extremos, bloquear las peticiones multipart desde nginx o Apache, sabiendo que eso rompe cualquier subida de archivos y algunos formularios de checkout.
Si quedaste expuesto, revisá si ya entraron. Huntress recomienda buscar procesos de php-fpm, php-cgi, httpd o apache2 que lancen sh, bash, curl, wget o powershell, que es la huella típica de un webshell.
Si el servidor corre PHP 8.1 o anterior, el plan no es esperar una versión oficial que no va a llegar: es migrar a una rama con soporte, o como mínimo aislarlo detrás de un WAF hasta hacerlo.

En resumen

php2shell combina las tres cosas que convierten una vulnerabilidad en un problema serio: está en el núcleo de un lenguaje que corre en una parte enorme de la web, permite ejecutar código sin autenticación, y se filtró antes de que existiera el parche. Para quien administra sitios en PHP, la prioridad de esta semana no es otra que actualizar. Y para quien todavía tiene servidores con versiones sin soporte, es la confirmación más clara de que "si anda, no lo toques" deja de ser una estrategia el día en que aparece una falla que nadie va a parchear por vos.

Fuentes

PHP (aviso oficial) — Security advisory: Critical remote code execution vulnerabilities, update now. Descripción de ambas fallas, versiones corregidas, SAPIs afectados y mitigaciones oficiales.
PHP en GitHub — Avisos de seguridad de php-src (GHSA-w8hw-w9fx-j79w y GHSA-6wmf-4rv5-p3rp).
NCSC (Reino Unido) — Critical security issue affecting PHP. Alcance de las versiones afectadas y recomendaciones del gobierno británico.
Sansec — Critical PHP RCE: CVE-2026-109618 and CVE-2026-109619. Cronología de la filtración, versiones afectadas y mitigaciones para nginx, Apache y PHP-FPM.
Patchstack — Major security alert: PHP vulnerable to critical RCE, attacks ongoing. Puntaje CVSS oficial, reportes de explotación activa y medidas temporales.
watchTowr — PHP Remote Code Execution FAQ: CVE-2026-109618. Preguntas frecuentes y estado de la explotación.
Huntress — Rapid Response: php2shell, Leaked Critical PHP Vulnerabilities. Cómo se filtró y qué buscar para detectar un compromiso.

Compartir en: