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

PHP2Shell ha encendido las alarmas en la comunidad de ciberseguridad tras la divulgación de dos vulnerabilidades críticas en el núcleo del intérprete PHP. Identificadas como CVE-2026-109618 y CVE-2026-109619, estas fallas pueden permitir que un atacante remoto ejecute código arbitrario en servidores vulnerables sin disponer de credenciales.

El problema es especialmente delicado porque afecta directamente al motor que procesa las solicitudes web. Esto significa que aplicaciones desarrolladas con WordPress, Drupal, Joomla y otros frameworks pueden quedar expuestas independientemente de que sus plugins, temas o código estén actualizados.

Las vulnerabilidades recibieron una puntuación de CVSS 9.2, correspondiente a severidad crítica. El proyecto PHP publicó las versiones corregidas el 21 de octubre de 2026 y recomendó actualizar inmediatamente todas las instalaciones afectadas.

En este artículo analizamos cómo funcionan PHP2Shell, qué sistemas están expuestos, cuáles son los riesgos para las organizaciones y qué medidas deben implementar los equipos de infraestructura y seguridad para reducir la superficie de ataque.

¿Qué es PHP2Shell y por qué representa una amenaza para los servidores?

PHP2Shell es el nombre utilizado públicamente para referirse a dos vulnerabilidades críticas que afectan al procesamiento interno de solicitudes en PHP.

A diferencia de los fallos tradicionales que afectan a una aplicación específica, estas vulnerabilidades se encuentran en el propio intérprete. Por lo tanto, el riesgo no depende exclusivamente de utilizar un CMS vulnerable, instalar un plugin comprometido o ejecutar código personalizado inseguro.

Los errores se producen durante la administración de memoria y el manejo del estado interno de las solicitudes HTTP.

En determinadas circunstancias, un atacante puede provocar que PHP trabaje con estructuras de memoria incompletas, referencias obsoletas o datos que ya deberían haberse liberado.

El escenario se vuelve especialmente peligroso cuando un proceso PHP reutiliza trabajadores (workers) para atender múltiples solicitudes. Un estado interno inconsistente puede afectar al procesamiento de solicitudes posteriores.

Entre los impactos potenciales se encuentran:

• Ejecución remota de código (RCE).
• Acceso a información almacenada en la memoria del proceso.
• Exposición de datos sensibles y credenciales.
• Compromiso de aplicaciones web.
• Alteración de archivos y componentes del servidor.
• Posible movimiento lateral si el proceso PHP dispone de permisos excesivos.

CVE-2026-109618: corrupción de memoria durante errores de agotamiento

La primera vulnerabilidad, CVE-2026-109618, está relacionada con el manejo de errores de memoria insuficiente (Out of Memory, OOM).

PHP incorpora un mecanismo denominado memory_limit, que establece la cantidad máxima de memoria que puede utilizar un script.

Cuando una solicitud supera ese límite, el intérprete puede interrumpir su ejecución. El problema aparece cuando esa interrupción ocurre mientras determinadas estructuras internas todavía están parcialmente inicializadas.

Durante la limpieza de recursos, PHP puede interpretar esos datos incompletos como estructuras válidas e intentar liberar o manipular memoria que no fue inicializada correctamente.

Este comportamiento puede provocar corrupción de memoria y abrir la puerta a escenarios de ejecución de código.

¿Cómo puede aprovecharlo un atacante?

Desde una perspectiva defensiva, el escenario puede describirse de la siguiente manera:

1. El atacante envía una solicitud HTTP especialmente construida.
2. La solicitud provoca una condición de agotamiento de memoria durante el procesamiento.
3. PHP interrumpe la operación mientras existen estructuras internas parcialmente inicializadas.
4. El proceso ejecuta rutinas de limpieza sobre un estado inconsistente.
5. La corrupción resultante puede permitir manipular el comportamiento del proceso.

El problema no consiste simplemente en provocar un error de memoria o una caída del servicio. Bajo las condiciones necesarias, puede convertirse en una vulnerabilidad de ejecución remota de código.

CVE-2026-109619: reutilización de estado global obsoleto

La segunda vulnerabilidad, CVE-2026-109619, está relacionada con el uso de referencias a memoria que ya fue liberada (Use After Free).

PHP utiliza estructuras y variables internas para administrar el estado de cada solicitud.

En determinadas condiciones, ese estado puede sobrevivir a la liberación de la memoria que lo respaldaba. Si una operación posterior vuelve a utilizar esas referencias antes de que el intérprete las reinicialice correctamente, puede producirse un acceso a memoria inválida.

El riesgo aumenta cuando un mismo worker procesa varias solicitudes consecutivas.

¿Qué consecuencias puede tener?

Dependiendo de las condiciones de explotación, un atacante podría:

• Provocar comportamientos inesperados en el intérprete.
• Acceder a información residual de memoria.
• Manipular el flujo de ejecución.
• Conseguir ejecución remota de código.

Este tipo de vulnerabilidad recuerda a otros incidentes históricos relacionados con errores de administración de memoria, aunque PHP2Shell tiene mecanismos técnicos diferentes.

¿Qué versiones de PHP están afectadas?

El proyecto PHP publicó actualizaciones de seguridad el 21 de octubre de 2026.

Las versiones corregidas son:

Rama	Versión vulnerable	Versión corregida
PHP 8.5	Hasta 8.5.11	8.5.12
PHP 8.4	Hasta 8.4.26	8.4.27
PHP 8.3	Hasta 8.3.35	8.3.36
PHP 8.2	Hasta 8.2.34	8.2.35

Las ramas PHP 8.1 y anteriores también requieren atención. Al encontrarse fuera del ciclo de soporte oficial, no reciben necesariamente una actualización estándar del proyecto PHP. Algunos proveedores pueden ofrecer parches retroportados.

Importante: no basta con comprobar el número de versión. Algunas distribuciones Linux incorporan correcciones de seguridad mediante parches retroportados sin modificar la versión principal del software.

Por eso es necesario verificar la versión y compilación del paquete instalado, así como los avisos de seguridad del proveedor.

¿Por qué WordPress, Drupal y Joomla también están en riesgo?

PHP es una de las tecnologías más utilizadas para desarrollar y ejecutar aplicaciones web.

Entre las plataformas que pueden verse afectadas cuando utilizan un intérprete vulnerable se encuentran:

• WordPress.
• Drupal.
• Joomla.
• Magento y Adobe Commerce.
• Laravel.
• Symfony.
• Aplicaciones PHP desarrolladas a medida.

El hecho de que una aplicación esté actualizada no significa que el servidor sea seguro.

Por ejemplo, una instalación de WordPress puede tener todos sus plugins actualizados, utilizar un tema legítimo y contar con buenas prácticas de desarrollo, pero continuar expuesta si el PHP que procesa las solicitudes HTTP no está corregido.

La vulnerabilidad se encuentra en una capa inferior de la arquitectura.

PHP-FPM, Apache y mod_php: dónde revisar la exposición

Las vulnerabilidades pueden afectar a diferentes formas de ejecutar PHP en entornos web:

• PHP-FPM: administra procesos PHP mediante FastCGI y es habitual en instalaciones con Nginx o Apache.
• Apache mod_php: ejecuta PHP directamente dentro de los procesos de Apache. El equipo de PHP identificó esta configuración como especialmente riesgosa.
• php-cgi: ejecuta PHP mediante la interfaz CGI.
• FrankenPHP: servidor de aplicaciones que integra el runtime PHP.
• LiteSpeed: también puede utilizar PHP mediante sus mecanismos de integración.

Una organización puede tener varias instalaciones de PHP en el mismo servidor. Por ejemplo, una versión para la consola, otra para PHP-FPM y otra para Apache.

Por eso, ejecutar únicamente php -v no permite confirmar que todos los servicios web estén utilizando una versión corregida.

Cómo comprobar si tu servidor Linux está afectado

La primera medida consiste en identificar las versiones de PHP instaladas.

Ejecuta:

php -v

Para listar los paquetes PHP instalados en Debian y Ubuntu:

dpkg -l | grep -E 'php[0-9.-]*'

Para identificar los servicios PHP-FPM:

systemctl list-units --type=service | grep php

También puedes comprobar los procesos activos:

ps aux | grep -E 'php-fpm|apache2|httpd' | grep -v grep

En Debian y Ubuntu, revisa los paquetes disponibles:

apt update
apt list --upgradable 2>/dev/null | grep php

En sistemas RHEL, Rocky Linux o AlmaLinux:

rpm -qa | grep '^php'

Y para consultar las actualizaciones:

dnf check-update 'php*'

Verificar la versión utilizada por PHP-FPM

Es importante comprobar los servicios y sus configuraciones:

systemctl status php8.4-fpm

Ajusta el nombre del servicio a la versión instalada.

También puedes revisar los sockets y procesos:

ss -lntp | grep php

La verificación debe realizarse sobre el runtime que atiende las solicitudes web, no únicamente sobre el ejecutable PHP de consola.

Remediación: cómo proteger los servidores PHP

La medida más importante es instalar las versiones corregidas y reiniciar los procesos que ejecutan PHP.

1. Actualizar PHP en Debian y Ubuntu

En sistemas que utilizan los paquetes oficiales de la distribución:

sudo apt update
sudo apt upgrade

Para actualizar paquetes PHP concretos:

sudo apt install --only-upgrade php8.4 php8.4-fpm

Adapta el comando a los paquetes instalados y a la versión que ofrece tu proveedor.

Después de actualizar, reinicia PHP-FPM:

sudo systemctl restart php8.4-fpm

Si utilizas Apache:

sudo systemctl restart apache2

En instalaciones con Nginx, también conviene validar y recargar su configuración:

sudo nginx -t
sudo systemctl reload nginx

2. Actualizar PHP en RHEL, Rocky Linux y AlmaLinux

En distribuciones basadas en RPM:

sudo dnf update 'php*'

Después, reinicia el servicio correspondiente:

sudo systemctl restart php-fpm

La actualización debe proceder de repositorios confiables y contar con los parches correspondientes a las vulnerabilidades.

3. Desactivar session.upload_progress

Una de las medidas temporales documentadas para reducir determinadas rutas de explotación de CVE-2026-109619 es desactivar el seguimiento del progreso de las cargas de archivos.

En php.ini:

session.upload_progress.enabled = Off

También puede configurarse en el pool correspondiente de PHP-FPM.

Después de modificar la configuración, reinicia todos los workers afectados.

Esta medida no elimina todas las posibilidades de explotación ni sustituye la actualización.

4. Revisar los límites de memoria y las cargas HTTP

Para reducir determinadas condiciones relacionadas con CVE-2026-109618, deben revisarse los límites de solicitudes y cargas.

Por ejemplo:

post_max_size = 32M
upload_max_filesize = 30M

Estos valores son orientativos y deben adaptarse a las necesidades de cada aplicación.

CERT-EU también documenta una mitigación específica basada en memory_limit=-1, aplicada mediante configuración administrativa del pool o del servidor, y acompañada de límites externos de recursos mediante cgroups.

Esta configuración requiere especial cuidado: eliminar el límite de PHP sin establecer controles de memoria a nivel del sistema operativo puede provocar problemas de disponibilidad.

No debe aplicarse indiscriminadamente en producción.

Protección adicional con AWS WAF

Para organizaciones que alojan aplicaciones PHP en AWS, AWS WAF puede ayudar a reducir la exposición mientras se completa el proceso de actualización.

Sin embargo, es fundamental entender que AWS WAF no corrige el intérprete PHP.

La protección debe considerarse una capa adicional de defensa.

Recomendaciones para AWS WAF

1. Asociar una Web ACL con CloudFront, Application Load Balancer o el recurso compatible que publica la aplicación.
2. Revisar el grupo de reglas administradas de PHP de AWS.
3. Mantener actualizada la versión del grupo de reglas.
4. Si se fijó manualmente una versión antigua, evaluar su actualización.
5. Activar los registros de AWS WAF para investigar solicitudes bloqueadas y patrones sospechosos.
6. Revisar las métricas y configurar alertas ante incrementos anormales de solicitudes bloqueadas.

AWS informó que estaba incorporando protecciones para estas vulnerabilidades en su grupo de reglas administradas de PHP.

Las instalaciones que utilizan la versión predeterminada reciben las actualizaciones administradas automáticamente, mientras que quienes fijaron una versión específica deben comprobar si necesitan actualizarla.

Arquitectura recomendada

Una arquitectura defensiva puede incorporar:

• AWS WAF delante de la aplicación.
• CloudFront como capa de distribución y protección.
• Security Groups con acceso restringido.
• PHP actualizado en EC2, contenedores o servicios administrados.
• CloudWatch para monitoreo.
• IAM con privilegios mínimos.
• AWS Secrets Manager para gestionar secretos.
• Segmentación de redes y aislamiento de servicios.

La recomendación fundamental sigue siendo actualizar PHP. Las reglas WAF no deben utilizarse como sustituto del parche.

PHP2Shell en contenedores Docker y Kubernetes

Los entornos basados en contenedores también requieren atención.

Actualizar PHP en el host no garantiza que los contenedores estén protegidos.

Es necesario identificar todas las imágenes que incorporan versiones vulnerables del runtime.

Para Docker:

docker images

Para revisar los contenedores activos:

docker ps

Una vez identificada la imagen afectada:

1. Actualizar la imagen base de PHP.
2. Reconstruir la imagen de la aplicación.
3. Ejecutar pruebas de seguridad y funcionamiento.
4. Publicar la nueva imagen en el registro.
5. Desplegar los contenedores actualizados.
6. Retirar las instancias anteriores.

En Kubernetes, también deben revisarse los deployments, los tags de las imágenes y las políticas de actualización.

No es suficiente reiniciar un contenedor si continúa utilizando una imagen vulnerable.

Detección de posibles compromisos: qué deben revisar los equipos SOC

Instalar el parche no garantiza que un servidor no haya sido comprometido previamente.

Las organizaciones deben realizar una revisión retrospectiva para identificar posibles señales de explotación.

1. Revisar registros de Apache y Nginx

Buscar patrones anormales de solicitudes, especialmente ráfagas de errores, respuestas inesperadas y tráfico repetitivo desde las mismas direcciones IP.

Ejemplo:

sudo grep -Ei 'POST|multipart|upload|500|502|503' \
/var/log/nginx/access.log

Para Apache:

sudo grep -Ei 'POST|multipart|upload|500|502|503' \
/var/log/apache2/access.log

Estos patrones no demuestran por sí mismos una explotación, pero pueden ayudar a identificar actividad que merece investigación.

2. Buscar archivos PHP inesperados

Los atacantes que consiguen comprometer una aplicación pueden intentar instalar web shells o modificar archivos legítimos.

Para localizar archivos PHP creados recientemente:

sudo find /var/www -type f -name '*.php' -mtime -7 -ls

También conviene revisar directorios de cargas:

sudo find /var/www -type f \
-path '*/uploads/*' -name '*.php' -ls

La presencia de un archivo PHP en una carpeta de cargas no confirma automáticamente una intrusión, pero requiere validación.

3. Comprobar procesos sospechosos

ps aux --sort=-%cpu | head -20

Presta atención a procesos inesperados ejecutados por usuarios como www-data, apache o nginx.

4. Revisar conexiones de red

sudo ss -tunap

Busca conexiones salientes inusuales, destinos desconocidos y procesos web que establezcan comunicaciones no esperadas.

5. Revisar integridad de archivos

Compara los archivos de la aplicación con copias de seguridad confiables o con los paquetes originales.

También es recomendable revisar:

• Archivos PHP modificados recientemente.
• Nuevos usuarios del sistema.
• Cambios en tareas programadas.
• Claves SSH agregadas.
• Alteraciones en archivos .htaccess.
• Cambios en configuraciones de PHP-FPM.
• Accesos sospechosos a bases de datos.

Indicadores de compromiso y respuesta ante incidentes

No existe un único indicador que permita identificar todos los intentos de explotación de PHP2Shell.

Los equipos de seguridad deben correlacionar diferentes fuentes:

Fuente	Qué investigar
Logs web	Solicitudes anormales y errores repetitivos
PHP-FPM	Errores OOM y fallos de workers
Sistema operativo	Procesos inesperados
EDR	Ejecución de comandos desde procesos web
Firewall	Conexiones salientes inusuales
Sistema de archivos	Nuevos scripts PHP
IAM	Accesos o cambios de privilegios no autorizados

Si se confirma una intrusión, las acciones recomendadas incluyen aislar el servidor, preservar evidencias, rotar credenciales y secretos potencialmente expuestos, investigar el alcance del incidente y reconstruir el entorno desde imágenes confiables.

¿Qué deben hacer las organizaciones ahora?

La respuesta a PHP2Shell debe abordarse como una tarea de gestión de vulnerabilidades de infraestructura, no únicamente como una actualización de aplicaciones.

Las prioridades son:

1. Inventariar todos los servidores que ejecutan PHP.
2. Identificar las versiones y paquetes instalados.
3. Verificar PHP-FPM, mod_php, CGI y otros runtimes.
4. Actualizar a versiones corregidas o aplicar los parches oficiales del proveedor.
5. Reiniciar todos los procesos afectados.
6. Reconstruir imágenes de contenedores vulnerables.
7. Aplicar controles temporales de reducción de exposición.
8. Revisar logs y buscar indicios de explotación previa.
9. Rotar secretos si existe evidencia de compromiso.
10. Documentar la remediación y verificar nuevamente los activos.

PHP2Shell demuestra que la seguridad debe comenzar en el runtime

Las vulnerabilidades CVE-2026-109618 y CVE-2026-109619 demuestran que incluso una aplicación correctamente desarrollada puede quedar expuesta cuando su infraestructura depende de componentes vulnerables.

PHP2Shell es especialmente relevante porque afecta a una tecnología ampliamente utilizada y puede permitir ejecución remota de código sin autenticación.

La principal lección para los equipos de seguridad es que la protección de WordPress, Drupal, Joomla o cualquier otra aplicación PHP no termina con la actualización de sus componentes.

También es necesario mantener actualizado el intérprete, controlar los procesos que ejecutan las solicitudes, proteger la infraestructura y vigilar los posibles indicios de compromiso.

Actualizar PHP a una versión corregida es la única solución completa. Los controles WAF, las restricciones de red y las configuraciones adicionales ayudan a reducir el riesgo, pero no sustituyen la corrección del software vulnerable.

La seguridad de una aplicación depende tanto de su código como de todas las capas que hacen posible su ejecución.

---

Fuentes y referencias técnicas

• PHP – Security Advisory y versiones corregidas: https://www.php.net/archive/2026.php
• CERT-EU – Security Advisory 2026-018: https://www.cert.europa.eu/publications/security-advisories/2026-018
• CVE.org – CVE-2026-109619: https://www.cve.org/CVERecord?id=CVE-2026-109619
• AWS – Security Bulletin 2026-143: https://aws.amazon.com/security/security-bulletins/2026-143-aws/
• Google Cloud – Responding to core PHP vulnerabilities: https://cloud.google.com/blog/products/identity-security/responding-to-core-php-vulnerabilities-cve-2026-109618-cve-2026-109619