30 Oct PHP2Shell: cómo corregir las vulnerabilidades críticas CVE-2026-109618 y CVE-2026-109619
PHP publicó actualizaciones de emergencia para dos vulnerabilidades críticas que pueden permitir ejecución remota de código sin autenticación. En esta guía explico el impacto, las versiones corregidas, cómo verificar tu instalación y qué medidas temporales aplicar mientras completas el parcheo.
Introducción
El 21 de octubre de 2026, el equipo de PHP publicó una actualización de seguridad urgente para corregir dos vulnerabilidades críticas en el intérprete. Ambas están calificadas con una puntuación CVSS v4.0 de 9.2 y podrían permitir que un atacante remoto ejecute código en un servidor PHP sin autenticarse.
El problema no se limita a WordPress. También puede afectar aplicaciones propias, APIs, plataformas de comercio electrónico y servicios que utilicen PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP o LiteSpeed.
La recomendación principal es clara: actualiza PHP a una versión corregida o instala el paquete de seguridad publicado por el proveedor de tu sistema operativo. Las mitigaciones temporales reducen determinadas rutas de ataque, pero no sustituyen el parche.
Fuentes oficiales: aviso de PHP y aviso de Ubuntu USN-8948-1
¿Qué vulnerabilidades se corrigieron?
CVE-2026-109618: corrupción asociada a falta de memoria (OOM)
La vulnerabilidad está relacionada con el manejo de una condición de falta de memoria (out of memory, OOM). En una ruta vulnerable, PHP puede interrumpir el procesamiento de una petición cuando parte de sus datos internos todavía no está inicializada por completo. La limpieza posterior puede tratar esos datos como válidos.
CVE-2026-109619: estado interno obsoleto entre peticiones
La segunda vulnerabilidad se relaciona con el estado interno de una petición que puede sobrevivir después de liberarse la memoria que lo respaldaba. Si un worker reutilizado procesa otra petición, podría llegar a utilizar ese estado obsoleto antes de que se restablezca la inicialización normal.
Ambas vulnerabilidades podrían desembocar en ejecución remota de código. PHP señala que el riesgo es especialmente alto en Apache con mod_php, porque existe una ruta demostrada que puede activarse antes de que se ejecute el código de la aplicación.
¿Qué versiones de PHP están corregidas?
Las versiones upstream publicadas para corregir ambos problemas son:
| Rama | Versión corregida |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Si utilizas una distribución Linux, no asumas que debes ver exactamente esos números en php -v. Distribuciones como Ubuntu o Debian pueden incorporar la corrección mediante un backport: aplican el parche y actualizan la revisión del paquete sin cambiar el número base de PHP.
Por eso, consulta el aviso de seguridad de tu distribución y verifica la revisión del paquete instalado. PHP 8.1 y las ramas anteriores ya no reciben correcciones upstream ordinarias para estos problemas; revisa la disponibilidad de backports de tu proveedor y planifica la migración a una rama soportada.
Paso 1. Identifica qué PHP utiliza tu servidor
Empieza por conocer la versión de CLI y los paquetes instalados:
php -v
command -v php
php --ini
# Ubuntu / Debian
dpkg-query -W -f='${binary:Package}\t${Version}\n' 'php*' 2>/dev/null
# RHEL, Rocky, AlmaLinux, Fedora y otras distribuciones RPM
rpm -qa | grep -i '^php'
Ten en cuenta que php -v muestra el intérprete de línea de comandos. Puede no ser el mismo que ejecuta tu sitio web. Verifica también PHP-FPM, Apache mod_php, el contenedor o el runtime administrado que recibe las peticiones.
No dejes un archivo phpinfo() expuesto públicamente para comprobarlo. Si necesitas una página de diagnóstico temporal, úsala en un entorno controlado y elimínala inmediatamente.
Paso 2. Instala la actualización de seguridad
Ubuntu
sudo apt update # Revisa la revisión candidata del paquete (debe ser la parcheada) apt-cache policy php8.3-fpm # Opción A (recomendada para parcheo urgente): actualizar SOLO PHP sudo apt install --only-upgrade 'php8.3*' # Opción B: actualizar todo el sistema # sudo apt upgrade
Para una respuesta a incidente urgente conviene la opción A: actualiza solo los paquetes PHP, de forma acotada y predecible, sin arrastrar otros cambios. La opción B (apt upgrade) también aplica las correcciones, pero actualiza todo lo pendiente del sistema; úsala cuando tengas una ventana de mantenimiento más amplia.
Antes de confirmar una actualización en producción, revisa qué paquetes se van a cambiar. La versión del paquete depende de la release de Ubuntu y de los repositorios habilitados.
Consulta el aviso oficial: USN-8948-1: PHP vulnerabilities.
Debian
sudo apt update apt-cache policy php-fpm php-cli php-common apt list --upgradable 2>/dev/null | grep -i php
Comprueba el estado de seguridad para tu release de Debian y aplica la revisión publicada por el proveedor. No uses el número upstream como único criterio.
RHEL, Rocky Linux y AlmaLinux
sudo dnf makecache dnf check-update 'php*' dnf info php php-fpm php-cli
Actualiza los paquetes corregidos según el repositorio y el procedimiento de cambios de tu organización. Si utilizas repositorios externos, confirma que el proveedor ya haya publicado la actualización.
Docker y Kubernetes
Actualiza la imagen base a una etiqueta corregida, reconstruye la imagen y vuelve a desplegarla. Actualizar el registro de imágenes no cambia los contenedores que ya están en ejecución.
Ejemplo:
FROM php:8.3.36-fpm
Y después:
docker compose build --pull docker compose up -d --force-recreate docker compose exec php php -v
Verifica que la etiqueta corresponda a la rama y al modo de ejecución de tu aplicación. En Kubernetes, comprueba el rollout y el digest de la imagen que ejecuta cada pod.
Paso 3. Reinicia los procesos que utilizan PHP
Después de instalar el paquete corregido, reinicia el servicio que realmente ejecuta PHP. Los procesos que ya estaban en memoria pueden continuar utilizando el binario anterior hasta ser reiniciados.
Ejemplos; adapta los nombres a tu sistema:
# Ubuntu / Debian con PHP-FPM 8.3 sudo systemctl restart php8.3-fpm # Apache con mod_php sudo systemctl restart apache2 # RHEL y derivados sudo systemctl restart httpd # Validar Nginx si cambiaste su configuración sudo nginx -t sudo systemctl reload nginx
Si utilizas Apache con PHP-FPM, reinicia el pool de PHP-FPM y valida la configuración de Apache. Si usas contenedores, recrea los contenedores o pods con la imagen corregida.
Comprueba los servicios y sus logs:
sudo systemctl status php8.3-fpm --no-pager sudo journalctl -u php8.3-fpm -n 100 --no-pager
Paso 4. ¿Qué hacer si no puedes actualizar inmediatamente?
PHP documenta mitigaciones temporales para reducir la exposición a rutas de explotación concretas. No ofrecen protección completa, por lo que deben utilizarse solo como puente hasta completar el parcheo.
Para CVE-2026-109618
El aviso recomienda configurar memory_limit=-1 en un contexto administrativo que la aplicación no pueda sobrescribir, junto con límites de tamaño de petición. Esta medida elimina la ruta vinculada al límite de memoria controlable por PHP, pero una asignación de memoria que falle por otras causas todavía puede alcanzar una ruta vulnerable.
Ejemplo orientativo de PHP-FPM:
; Mitigación temporal: evaluar riesgos antes de aplicar php_admin_value[memory_limit] = -1 php_admin_value[post_max_size] = 32M php_admin_value[upload_max_filesize] = 24M
Advertencia: memory_limit=-1 elimina el límite de memoria de PHP. Sin límites externos apropiados, una petición puede consumir demasiada memoria y perjudicar la disponibilidad del servidor. Utiliza cgroups o límites de contenedor dimensionados y monitorizados. El aviso de PHP desaconseja sustituirlos por RLIMIT_AS o RLIMIT_DATA, ya que pueden provocar la condición vulnerable.
Ajusta post_max_size según tu aplicación: PHP recomienda 8M para aplicaciones que no necesitan subidas y 32M cuando son necesarias, manteniendo upload_max_filesize por debajo de post_max_size. Los límites deben ser coherentes también en Nginx, Apache y cualquier proxy intermedio.
Para CVE-2026-109619
PHP recomienda deshabilitar el progreso de subidas de sesión antes del parseo de la petición:
php_admin_value[session.upload_progress.enabled] = 0
Para PHP 8.5, también recomienda esta medida temporal para una ruta confirmada relacionada con backtraces de errores fatales:
php_admin_value[fatal_error_backtraces] = 0
La segunda directiva es específica de PHP 8.5 en este contexto. No la agregues indiscriminadamente a otras ramas.
Después de cambiar la configuración, reinicia todos los workers afectados. No dependas de ini_set() o .user.ini para aplicar estas medidas antes del parseo. Desactivar display_errors o utilizar @ no corrige las vulnerabilidades.
Paso 5. Comprueba Nginx o Apache
En Nginx, client_max_body_size limita el tamaño máximo del cuerpo de la petición. En cambio, client_body_buffer_size controla el buffer y no constituye un límite máximo de tamaño.
Ejemplo orientativo dentro del bloque server existente:
client_max_body_size 32m; client_body_timeout 10s; client_header_timeout 10s; large_client_header_buffers 4 8k;
Valida antes de recargar:
sudo nginx -t && sudo systemctl reload nginx
En Apache, las directivas de límite deben ubicarse en un contexto permitido. Las directivas PHP específicas de mod_php no controlan PHP-FPM y no deben copiarse a .htaccess suponiendo que funcionarán en todos los entornos.
Si usas un WAF, sus reglas pueden aportar una capa adicional, pero no sustituyen la actualización del runtime.
Paso 6. Verifica que la corrección está aplicada
No te quedes únicamente con la salida de php -v. Confirma:
- La revisión del paquete o la versión corregida de la imagen.
- El aviso de seguridad del proveedor para tu sistema operativo.
- El reinicio de todos los procesos, pools o contenedores que atienden tráfico.
- El estado de los servicios y la ausencia de errores nuevos en los logs.
- El funcionamiento de login, administración, formularios, subidas de archivos, importaciones y tareas programadas.
En WordPress, revisa también que los plugins y temas funcionen correctamente. Si bloqueas xmlrpc.php, hazlo solo si tu instalación no lo necesita: esa medida trata otros riesgos y no corrige estos CVE.
Recomendaciones finales
- Prioriza los servidores PHP expuestos a Internet.
- Mantén un inventario de las versiones de PHP en hosts, contenedores y servicios administrados.
- Utiliza repositorios oficiales o proveedores confiables y verifica sus avisos.
- Aplica actualizaciones con pruebas, respaldo y un plan de reversión.
- Monitoriza consumo de memoria, reinicios de workers, errores PHP y disponibilidad.
- Documenta las mitigaciones temporales y retíralas cuando el parche esté instalado y validado.
- Planifica la migración de las ramas de PHP fuera de soporte.
En AWS, puedes complementar este trabajo con Systems Manager para inventario y operaciones, CloudWatch para monitorización, escaneo de imágenes de contenedor y AWS WAF cuando corresponda. Estas herramientas ayudan a reducir exposición y detectar anomalías, pero no sustituyen el parche de PHP.
Fuentes oficiales
- PHP: archivo oficial de avisos de 2026
- PHP: página de descargas con las versiones corregidas
- Ubuntu: USN-8948-1
- Ubuntu: tracker CVE-2026-109618
- Ubuntu: tracker CVE-2026-109619
- NCSC-UK: Critical security issue affecting PHP
Este artículo tiene fines informativos. Comprueba siempre las instrucciones actuales del proveedor de tu distribución y prueba los cambios en un entorno controlado antes de aplicarlos en producción.
Happy Hacking!
