Seguridad · 21 de octubre de 2026

PHP2Shell: dos fallas críticas en PHP y qué hacer hoy

El 21 de octubre el equipo de PHP publicó los parches de CVE-2026-109618 y CVE-2026-109619, calificadas 9.2 de 10: permiten ejecutar comandos en el servidor sin usuario ni contraseña. Qué versiones instalar y qué se sabe de los ataques.

Publicado el 21 de octubre de 2026 · Las fuentes van al final

Qué pasó

Entre agosto y octubre de 2026, varios investigadores reportaron por separado al equipo de seguridad de PHP dos fallos en el núcleo del lenguaje. Sansec fecha el primer reporte el 11 de agosto y el de Wiz Research el 24 de agosto. PHP preparó los parches para publicarlos de forma coordinada, pero el 20 de octubre se filtraron los detalles y watchTowr confirmó que los fallos eran reales. Ese mismo día php.net anunció una versión de seguridad urgente para el 21 de octubre a las 14:00 UTC, las 08:00 en la Ciudad de México. A esa hora salieron PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, y los investigadores publicaron sus análisis con el nombre PHP2Shell.

Qué permiten

Los dos fallos están en cómo PHP maneja un error fatal, sobre todo el de memoria agotada, mientras procesa una petición. Con CVE-2026-109618, el error interrumpe a PHP con los datos de la petición a medio construir, y la limpieza posterior los trata como válidos. Con CVE-2026-109619, parte del estado de una petición sobrevive después de liberar su memoria, y la siguiente petición que atiende el mismo proceso lo reutiliza. En los ataques conocidos, la petición es un formulario multipart/form-data, el formato de subir archivos. PHP lo procesa antes de ejecutar el código del sitio, así que no importa qué aplicación corra encima.

El aviso de PHP dice que permiten ejecutar código de forma remota, sin autenticación y con los permisos del proceso web. Las dos tienen 9.2 de 10 en CVSS 4.0. Con Apache y mod_php está demostrado en la configuración por defecto; en PHP-FPM está demostrado para CVE-2026-109619 a través del manejo de sesiones, y para CVE-2026-109618 el análisis del código lo considera vulnerable sin que exista todavía un exploit completo. Wiz demostró también la lectura de memoria: el proceso de PHP devuelve, dentro de una cookie PHPSESSID, datos de otras peticiones, como contraseñas, tokens de sesión y llaves de API, aunque la aplicación nunca llame a session_start().

A quién afecta

A cualquier instalación de PHP que atienda peticiones web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. Según Wiz, casi todas las versiones desde PHP 5.4, de 2012, tienen al menos uno de los dos fallos. Wiz ejecutó código sin autenticarse contra las imágenes oficiales de WordPress, Drupal y Joomla. PHP considera que el riesgo mayor está en Apache con mod_php, donde una sola petición dispara el ataque antes de que corra el código de la aplicación.

Qué hacer

Actualizar a PHP 8.5.12, 8.4.27, 8.3.36 u 8.2.35. En Ubuntu el parche ya está en los paquetes normales, sin Ubuntu Pro: 22.04 lo trae en php8.1 8.1.2-1ubuntu2.28, 24.04 en php8.3 8.3.6-0ubuntu0.24.04.13 y 26.04 en php8.5 8.5.4-0ubuntu1.5 (aviso USN-8948-1). Ubuntu conserva el número base, así que php -v seguirá diciendo 8.3.6; la prueba está en el sufijo del paquete. Debian 13 publicó php8.4 8.4.27-1~deb13u1 (DSA 6574-1); Debian 12, con php8.2, no tenía aviso al cierre de esta entrada. En las demás distribuciones, apt list --upgradable o su equivalente.
Reiniciar php-fpm o Apache. Los procesos que ya estaban corriendo siguen con el código viejo. En Debian y Ubuntu el paquete de php-fpm se reinicia solo al actualizar; Apache con mod_php no siempre.
Si el servidor corre PHP 8.1 o anterior, el proyecto PHP ya no publica versiones. Las salidas son subir a 8.2 o superior, instalar el paquete parchado de la distribución o, para quien compila desde fuente, aplicar los parches mínimos que el equipo de seguridad publicó para 7.4, 8.0 y 8.1 en las ramas PHP-7.4-CVE-2026-109618-109619, PHP-8.0-CVE-2026-109618-109619 y PHP-8.1-CVE-2026-109618-109619 de php-src. Ubuntu 20.04 lo tiene en php7.4 7.4.3-4ubuntu2.29+esm5, pero solo con Ubuntu Pro; lo mismo pasa con 18.04 y 16.04.
Con Docker, las imágenes oficiales php de Docker Hub se reconstruyeron el 21 de octubre a partir de las 17:23 UTC con las versiones corregidas. Compruebe la suya con docker run --rm php:8.3-fpm php -v y vuelva a construir la imagen de su aplicación.
En hospedaje compartido o cPanel, el cliente no puede actualizar; los paquetes llegan como ea-php por EasyApache. Pida al proveedor por escrito la versión instalada y la fecha en que la aplicó.
Si hoy no se puede actualizar, php.net describe medidas que reducen la exposición sin dejar el servidor seguro: memory_limit=-1 fijado con php_admin_value en el pool de FPM o en la configuración de Apache; post_max_size bajo (8M si no hay subida de archivos, 32M si la hay); session.upload_progress.enabled=0 con php_admin_flag en el pool o en php.ini, nunca con ini_set() ni .user.ini; en PHP 8.5, también fatal_error_backtraces=0. Después, reiniciar todos los procesos. Si el sitio no recibe archivos, se puede rechazar multipart/form-data en nginx o Apache. No conviene limitar la memoria con RLIMIT_AS ni RLIMIT_DATA, porque provocan el fallo de asignación que el ataque necesita.

Cómo saber si ya entraron

Los indicios están por debajo de la aplicación, así que sus propios registros pueden no mostrar nada. Hay que buscar en los del servidor web y de PHP: peticiones multipart seguidas de errores fatales de memory_limit o de ráfagas de respuestas 500, cookies PHPSESSID de tamaño anormal en las respuestas, reinicios de procesos de php-fpm sin explicación, y procesos de php-fpm o apache que lancen sh, curl o wget. Si aparece algo de eso: aislar el servidor, conservar los registros, buscar archivos nuevos en la raíz web y tareas programadas nuevas, y cambiar todas las credenciales que vivían en ese servidor, incluido el certificado TLS. Si el sistema trata datos personales, el artículo 19 de la LFPDPPP obliga a informar a las personas afectadas cuando la vulneración afecta de forma significativa sus derechos patrimoniales o morales.

Qué se sabe de los ataques

Al cierre de esta entrada, la noche del 21 de octubre (22:00 UTC), hay intentos y no hay brechas confirmadas. Cloudflare informó a las 07:43 UTC de los primeros ataques contra sus clientes y publicó reglas de WAF para todos sus planes, incluido el gratuito. Patchstack recibió a las 07:34 UTC reportes de explotación de proveedores de hospedaje, pero a las 13:57 UTC su telemetría mostraba «solo sondeos, sin evidencia firme de brechas». Los honeypots de watchTowr registraron intentos de explotación contra los dos fallos durante el día. Huntress no había visto explotación entre sus clientes a las 10:00, hora del este. Los dos CVE no están en el catálogo KEV de CISA.

Circula mucho código público: más de cien repositorios en GitHub dicen explotar los fallos. Ninguna firma ha confirmado que alguno funcione, algunos admiten que no logran ejecutar código, Cloudflare y Tenable avisan de que parte de ese código lleva malware, y los autores del exploit que sí funciona no lo publicaron. Sansec espera explotación masiva ahora que los análisis técnicos son públicos. Esta entrada se corregirá con fecha conforme cambien los hechos.