Qué pasó
El 21 de octubre, el proyecto PHP publicó correcciones para dos vulnerabilidades, CVE-2026-109618 y CVE-2026-109619. Ambas tienen una puntuación CVSS de 9.2 y, según el análisis de Arctic Wolf, pueden permitir que un atacante no autenticado ejecute código en un servidor que procesa peticiones web con PHP.
Los bugs están en el propio ciclo de procesamiento de peticiones de PHP, no en un framework ni en un plugin:
- CVE-2026-109618 es una corrupción de memoria que se produce cuando una condición de falta de memoria interrumpe PHP mientras los datos de la petición solo están parcialmente preparados.
- CVE-2026-109619 es un use-after-free: el estado de una petición puede sobrevivir y ser leído por una petición posterior en el mismo worker, lo que además puede filtrar contenido de la memoria.
Ese segundo punto merece una pausa. Qualys señala que la memoria filtrada de un worker puede contener contraseñas, tokens y API keys. Así que, aunque nadie consiga una shell en tu servidor, los secretos pueden salir por la puerta.
Todo fue muy rápido después del parche, y la escala es enorme: The Hacker News cita estimaciones de Censys de más de 32 millones de servicios PHP que siguen ejecutando una versión afectada.
- El equipo de inteligencia de amenazas de Amazon dijo que los ataques empezaron cuatro días antes de que se publicaran las correcciones, según informa BleepingComputer.
- El 24 de octubre, un investigador de Perplexity confirmó la ejecución de código con éxito contra honeypots (The Hacker News).
- El 26 de octubre, CISA añadió ambos CVE a su catálogo de vulnerabilidades explotadas conocidas (KEV) y dio a las agencias federales de EE. UU. hasta el 29 de octubre para corregirlas.
Por qué importa incluso en apps pequeñas
Aquí los atacantes no eligen objetivos por el tamaño de la empresa. Escanean internet buscando cualquier cosa que responda como PHP y prueban el exploit. Un proyecto olvidado en un VPS es tan accesible como una gran tienda online.
Algunos detalles hacen que este caso merezca especialmente tu atención:
- No depende de tu código. Arctic Wolf destaca que, como los fallos están en el procesamiento de peticiones de PHP, la exposición no depende de qué aplicación ejecutes. Una app Laravel perfectamente escrita sobre una build antigua de PHP sigue expuesta.
- Muchas configuraciones de servidor están afectadas. Apache con mod_php se considera el mayor riesgo, pero PHP-FPM, php-cgi, FrankenPHP y LiteSpeed también figuran como afectados, igual que productos y appliances que incluyen PHP.
- El PHP antiguo es habitual. Qualys informa de que alrededor del 71% de las instalaciones de PHP cuya versión pudo identificar ya estaban fuera de soporte. Si usas 8.1 o anterior, no hay una corrección oficial regular para ti.
Cómo comprobar tu app
Buscas una respuesta por servidor: ¿hay algo sirviendo peticiones web con PHP y, en ese caso, qué versión exacta?
1. Haz una lista de todo lo que alojas. No solo la app principal. Incluye webs de marketing, blogs, documentación, entornos de staging, herramientas de administración y cualquier cosa en un subdominio. Los olvidados son los peligrosos.
2. Mira los encabezados de respuesta. Muchas instalaciones de PHP se anuncian en un encabezado X-Powered-By o Server. Que no haya encabezado no significa que no haya PHP (se puede desactivar con expose_php = Off), pero un encabezado es un sí rápido. Las páginas de error detalladas son otra pista: un stack trace de PHP en producción le dice a un atacante exactamente qué ejecutas.
curl -sI https://your-site.example | grep -i -E 'x-powered-by|server'
# X-Powered-By: PHP/8.3.20 <- PHP, and an old patch level3. Comprueba la versión que sirve el tráfico web, no solo la CLI. php -v en el servidor puede mostrar una build distinta de la que usan realmente Apache o PHP-FPM; Qualys lo advierte expresamente. Revisa el binario de FPM o el módulo PHP de tu servidor web, o pregunta a tu proveedor de hosting.
php-fpm8.3 -v # or php-fpm -v, depending on your distro
apache2ctl -M | grep php # is mod_php loaded?4. Compara con las versiones corregidas. Si instalas PHP desde tu distribución Linux, la corrección puede venir como backport en un paquete con un número de versión aparentemente más antiguo, así que consulta el aviso de seguridad de tu distro en lugar de fiarte solo del número de versión. Si no, necesitas como mínimo:
- PHP 8.5: 8.5.12
- PHP 8.4: 8.4.27
- PHP 8.3: 8.3.36
- PHP 8.2: 8.2.35
5. ¿Hosting gestionado? Si estás en un hosting gestionado de WordPress o en un PaaS, revisa su página de estado o su changelog en busca de un aviso sobre PHP2Shell. La mayoría parcheará por ti, pero "la mayoría" no es "todos", y un VPS autogestionado depende por completo de ti.
Cómo solucionarlo
Parchea y luego reinicia. Actualizar PHP es la única solución completa.
El reinicio importa: los workers en ejecución mantienen el código antiguo en memoria hasta que se sustituyen. Con Docker, reconstruye sobre una imagen base actualizada (por ejemplo, un tag actual de php:8.3-fpm) y vuelve a desplegar. No te limites a reiniciar el contenedor antiguo.
En Debian o Ubuntu con PHP-FPM, suele ser algo así:
sudo apt update && sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2 # if you use mod_phpSi no puedes parchear hoy, Qualys resume las mitigaciones provisionales de PHP. Reducen el riesgo, pero no hacen seguro un servidor sin parchear. Configúralas en php.ini o en la configuración del pool de FPM (no en .user.ini ni con ini_set) y reinicia todos los workers.
Si un servicio sigue sin parchear y no necesita ser público, ponlo detrás de una VPN o de una lista de IP permitidas, o desconéctalo hasta que puedas actualizar.
; php.ini or FPM pool config (not .user.ini or ini_set)
session.upload_progress.enabled = 0
post_max_size = 8M ; 32M if you need uploads
upload_max_filesize = 6M ; keep below post_max_sizeSi usas PHP 8.1 o anterior, planifica la actualización ya. Existen backports limitados para algunas ramas antiguas, pero dependes de la suerte cada vez que aparece algo así.
Busca señales de compromiso. Revisa procesos inesperados, archivos nuevos en los directorios web, cron jobs desconocidos y conexiones salientes desde el servidor web. Arctic Wolf también señala que muchas peticiones "PHP2Shell" en los logs reutilizan técnicas antiguas, así que una línea de log alarmante no significa automáticamente una intrusión con éxito.
Rota los secretos si estuviste expuesto. Como CVE-2026-109619 puede filtrar memoria de los workers, trata como posiblemente vistos los secretos que pasaron por un proceso PHP sin parchear y expuesto a internet. Eso incluye contraseñas de bases de datos, API keys, claves de firma de sesiones y claves de proveedores de pago. Laravel y frameworks similares los guardan en .env, así que confirma también que ese archivo nunca fue accesible desde la web.
Checklist rápido
Repásalo para cada dominio que tengas:
- Todos tus dominios y subdominios están en la lista, incluidas las webs antiguas de marketing y de staging.
- Sabes cuáles usan PHP y la versión exacta que sirve el tráfico web.
- Cada uno está en 8.5.12, 8.4.27, 8.3.36, 8.2.35 o en una build parcheada por el proveedor.
- Los workers de PHP y los servidores web se reiniciaron después de actualizar.
- Todo lo que sigue sin parchear está restringido o desconectado, con las mitigaciones aplicadas.
- Se han rotado los secretos de los hosts expuestos.
- Producción ya no anuncia su versión de PHP ni muestra stack traces.
La lección de fondo
PHP2Shell quedará parcheado y olvidado en pocas semanas. El patrón, no. El margen entre "corrección publicada" y "explotación activa" ahora es de días, a veces negativo. Los equipos pequeños no pueden ganar esa carrera a base de heroicidades. Lo que funciona es saber qué ejecutas y darte cuenta rápido cuando algo cambia.
Es la misma idea detrás de nuestro checklist de lanzamiento para apps creadas con IA: la mayoría de los incidentes reales vienen de cosas fáciles de comprobar, si de verdad las compruebas.
AppSafe escanea tu sitio en producción desde fuera, como lo vería un atacante. Busca problemas como encabezados de seguridad ausentes, un encabezado X-Powered-By que revela tu stack, archivos expuestos y errores detallados, y te da soluciones en lenguaje claro. Cuando hayas parcheado, lanza un escaneo gratuito en cada uno de tus dominios para detectar las demás mejoras fáciles de paso.