php2shell: dos vulnerabilidades críticas en PHP permiten ejecutar código sin autenticación

Acción inmediata requerida

Si tienes cualquier servidor que ejecute PHP, esto va antes que todo lo demás:

# ¿Qué versión de PHP sirve tus peticiones web? (no solo la del CLI)
php -v

# Versiones corregidas:
#   PHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35

# Debian/Ubuntu
sudo apt update && sudo apt upgrade php*

# Reinicia los workers después de actualizar
sudo systemctl restart php8.3-fpm   # ajusta a tu versión
sudo systemctl restart apache2      # si usas mod_php

Importante: php -v te dice la versión del CLI. La que importa es la que atiende peticiones HTTP (PHP-FPM, mod_php, etc.), y puede ser distinta. Confírmala con phpinfo() desde un entorno controlado o con tu proveedor de hosting.

Qué ocurrió

El 20 de octubre de 2026 se filtró en Internet que PHP estaba a punto de publicar dos vulnerabilidades críticas. La publicación original fue eliminada, pero las capturas ya circulaban, y Huntress documentó que watchTowr confirmó la filtración ese mismo día. El equipo de PHP adelantó la publicación y el 21 de octubre de 2026 a las 14:00 UTC lanzó los parches.

Las dos vulnerabilidades, apodadas colectivamente php2shell:

CVE	Tipo	CVSS v4.0
CVE-2026-109618	Use-after-free (deserializador de upload progress)	9.2
CVE-2026-109619	Use-after-free (backtrace de errores fatales) + type confusion en OPcache	9.2

Ambas son ejecución remota de código (RCE) sin autenticación, con los privilegios del proceso web. Algunas fuentes iniciales hablaban de CVSS 10.0, pero la puntuación oficial del equipo de PHP es 9.2.

Lo que lo hace especialmente grave: el fallo vive en el motor de PHP, no en tu código. Se dispara mientras PHP procesa la petición, antes de que WordPress, Laravel, Craft CMS o cualquier framework llegue a ejecutarse. Que tu aplicación esté perfectamente escrita no te protege.

Cómo funcionan técnicamente

Según el análisis de Sansec y Huntress, ambos bugs comparten una raíz común: un error fatal durante una petición (típicamente falta de memoria al superar memory_limit) interrumpe código nativo antes de que termine de limpiar su estado.

CVE-2026-109618: memoria a medio inicializar

Un error de memoria durante la preparación de la petición deja datos parcialmente inicializados. La rutina de limpieza posterior los trata como válidos, y eso abre un camino a la ejecución de código. Sansec lo sitúa en el deserializador del upload progress de sesiones, y señala un efecto secundario muy desagradable: ese manejador puede devolver memoria liberada del worker dentro de una cookie PHPSESSID en la respuesta.

Esa memoria puede contener contraseñas, tokens de sesión, API keys o incluso claves privadas TLS. Sansec lo compara con Heartbleed. Como el manejador corre antes del código de la aplicación, funciona aunque tu app nunca llame a session_start().

CVE-2026-109619: estado que sobrevive a su memoria

PHP conserva estado específico de la petición después de que la memoria que lo respaldaba fue liberada. Si el mismo worker atiende una petición posterior, puede usar ese estado obsoleto antes de la inicialización normal. El resultado es un use-after-free en el heap, que permite divulgación de memoria y ejecución de código.

El vector conocido

El disparador documentado hasta ahora son las peticiones multipart/form-data, que PHP parsea antes de pasar el control a tu aplicación. Según PHP, se validó RCE completo por HTTP contra mod_php con los límites de memoria y entrada por defecto.

A quién afecta

Esta es la parte donde las fuentes no coinciden del todo, así que conviene ser preciso:

Confirmado por PHP: todas las instalaciones que sirven peticiones web están en riesgo: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
Versiones corregidas: 8.5.12, 8.4.27, 8.3.36 y 8.2.35.
Código vulnerable: Sansec indica que el código afectado se remonta a PHP 5.4.0 (2012), y CERT-EU considera que podrían estar afectadas todas las versiones desde PHP 5. No es una lista oficial de rangos afectados.
Versiones sin soporte (8.1 y anteriores): no reciben parche oficial en las ramas estables. Huntress menciona que PHP publicó backports mínimos en código fuente para 7.4, 8.0 y 8.1, pensados para quien compila desde fuente o no tiene un proveedor LTS. Algunas distribuciones también harán sus propios backports.

En la práctica, el software PHP más popular entra en el radio de impacto. Patchstack recoge que Wiz Research demostró RCE sin autenticación contra las imágenes de contenedor más recientes de WordPress. Y Sansec lista aplicaciones como Magento, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel y Symfony como parte del ecosistema expuesto.

Si trabajas con Craft CMS o cualquier stack sobre PHP, la regla es simple: Craft, Laravel y WordPress son tan seguros como el PHP que tienen debajo.

Estado de explotación

Hay que leerlo con cuidado, porque los reportes son contradictorios y cambian por horas:

Cloudflare dijo estar viendo “early attacks emerging” y desplegó reglas WAF para los vectores de explotación conocidos, disponibles para todos los clientes, incluido el plan gratuito. Ellos mismos lo llaman un parche provisional.
Sansec reportó los primeros ataques a las 07:43 UTC del 21 de octubre, antes de la publicación del parche.
Patchstack recibió reportes de incidentes activos de socios de hosting y, a las 13:57 UTC, solo veía sondeos sin evidencia firme de brechas, aunque esperaba que eso cambiara.
Huntress no había observado explotación en su base de socios a media mañana (hora del este).
Circula código de exploit público sin verificar. No ejecutes PoCs descargados de redes sociales: podrían contener malware.

La conclusión práctica: asume que la explotación activa es cuestión de horas, no de días.

Cómo mitigar

1. Actualizar (la única solución completa)

Gina Peter Banyard, desarrolladora del core de PHP, lo resumió así según Tenable: “the only mitigation is patching / upgrading PHP”.

# Docker: reconstruye con la imagen oficial parcheada
docker pull php:8.3-fpm
docker compose build --no-cache && docker compose up -d

# Verifica la versión dentro del contenedor
docker compose exec app php -v

Notas útiles:

Los repositorios de terceros pueden tardar. Sansec y Huntress señalan que Remi no tenía los paquetes disponibles el día del lanzamiento; considera los paquetes de tu distribución o compilar desde fuente.
Software que trae su propio PHP (Plesk, paneles de control, appliances, software Windows) necesita su propia actualización. Plesk ya publicó un aviso para sus builds.
En hosting compartido no controlas PHP: escribe a tu proveedor y pregunta explícitamente por el estado del parche.

2. Inventario de todos tus PHP

Busca instalaciones olvidadas: servidores de staging, contenedores antiguos, apps internas, herramientas como phpMyAdmin. El NCSC del Reino Unido pide empezar por los sistemas expuestos a Internet.

3. Mitigaciones temporales (solo si no puedes parchear ya)

Patchstack lo deja claro: estas medidas reducen exposición pero no hacen segura una instalación. Y Joe Ferguson, release manager de PHP 8.6, advirtió que “ini settings won’t save you”.

; php.ini o configuración del pool de PHP-FPM
; NO usar ini_set() ni .user.ini: la aplicación podría sobrescribirlos
session.upload_progress.enabled = 0

; En PHP 8.5
fatal_error_backtraces = 0

; Recomendado por Patchstack
post_max_size = 8M

# Bloqueo temporal de multipart/form-data (rompe subida de archivos)
if ($http_content_type ~* "multipart/form-data") {
    return 403;
}

Después de cualquier cambio, reinicia todos los workers y verifica los valores desde una petición real a PHP-FPM, no desde el CLI. Sansec también menciona poner memory_limit = -1 como medida temporal, pero hay un riesgo claro: una sola petición podría consumir toda la memoria del servidor. Si lo haces, monitoriza y restáuralo tras parchear.

4. Aísla lo que no puedas parchear

Si estás en PHP 8.1 o anterior sin backport disponible, CERT-EU recomienda aislar las aplicaciones expuestas de redes públicas: ponerlas detrás de una VPN, un WAF o directamente fuera de línea hasta migrar.

5. Evita los “parches milagro”

Patchstack advierte contra plugins y snippets copiados de foros que prometen arreglar esto. No están verificados y pueden romper tu sitio o meter algo peor.

Cómo detectar si te intentaron explotar

Todavía no hay indicadores de compromiso (IoCs) confirmados, pero hay señales de comportamiento útiles:

En los logs web:

Picos de peticiones multipart/form-data desde el 21 de octubre, aprox. 07:43 UTC.
Errores por límite de memoria seguidos de respuestas HTTP 500 repetidas.
Cookies PHPSESSID inusualmente grandes o malformadas.
Reinicios inexplicables de workers de PHP.

En el sistema (Huntress recomienda vigilar procesos hijos de PHP):

php-fpm, php-cgi, httpd, apache2  →  spawning:
  sh, bash, cmd.exe, powershell.exe
  python, perl, curl, wget, nc
  patrones: /dev/tcp/, fsockopen, mkfifo

Un servidor web que ejecuta whoami, id o uname -a es una señal de alarma clara.

Después de un posible compromiso: busca webshells y archivos nuevos en el directorio web, cron jobs o cuentas nuevas, y preserva los logs antes de limpiar nada.

Y como el fallo permite leer memoria del worker, considera rotar credenciales y claves que el servidor manejara: API keys, contraseñas de base de datos, secretos de aplicación y, si aplica, claves TLS.

Por qué importa más allá de este parche

Este incidente tiene tres lecciones que van más allá del CVE:

El runtime también es superficie de ataque. Pasamos años endureciendo plugins, dependencias y código propio, pero este fallo está debajo de todo eso. Mantener el runtime actualizado es parte de la seguridad, no solo mantenimiento.
Las versiones sin soporte tienen un costo real. Cada sitio atascado en PHP 7 u 8.0 por “no romper compatibilidad” hoy depende de que alguien publique backports. La deuda técnica se paga con intereses en el peor momento.
El tiempo entre la filtración y la explotación ahora se mide en horas. Según Sansec, el ciclo empezó a las 07:43 UTC, seis horas antes del parche. Tener un proceso para desplegar actualizaciones de runtime rápido (imágenes Docker reproducibles, CI/CD, inventario claro) es lo que separa un susto de un incidente.

Conclusión

php2shell no es un fallo en un plugin ni en un framework: es el motor sobre el que corre una enorme parte de la web. Actualiza a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, reinicia los workers, verifica la versión que realmente atiende peticiones y, si no puedes parchear hoy, aísla el servicio y aplica las mitigaciones como puente, no como solución.

Los detalles siguen evolucionando: varias fuentes se publicaron el mismo día del lanzamiento y se actualizan constantemente. Revisa los avisos oficiales de PHP y de tu proveedor antes de dar el tema por cerrado.