PHP2Shell: fallas críticas en PHP permiten invadir servidores sin login. Cómo actualizar ahora

El 21 de octubre de 2026, el proyecto PHP publicó una actualización de seguridad fuera de calendario para corregir dos fallas críticas en el propio intérprete: CVE-2026-109618 y CVE-2026-109619, apodadas PHP2Shell. Ambas tienen nota 9.2 en CVSS v4.0 y, en ciertas condiciones, permiten ejecución remota de código sin autenticación: cualquier persona en internet puede ejecutar comandos en tu servidor sin iniciar sesión y sin depender de ninguna falla de tu sitio.

No es un problema de WordPress, Laravel o Magento. Es de PHP. Si tu servidor responde peticiones web con PHP, está en riesgo. En este artículo reunimos lo que confirmaron las fuentes oficiales, qué hacer ahora y cómo mitigar si no puedes actualizar hoy.

Resumen para quien tiene prisa

Actualiza ahora a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 y reinicia todos los procesos de PHP.
Toda instalación que atiende peticiones web está afectada: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.
PHP 8.1 o anterior ya no recibe corrección oficial. Busca el paquete corregido de tu distribución o de soporte extendido, o migra de versión.
Las mitigaciones temporales son parciales. Según el propio equipo de PHP, solo la actualización lo resuelve.
¿Usas WordPress? No hay actualización de WordPress para esto. Lo que hay que actualizar es el PHP del servidor.

Qué son las fallas

Las dos fallas están en la gestión de memoria y en el manejo de errores del motor de PHP, código por el que pasa prácticamente toda petición. Por eso el impacto es tan amplio.

CVE	Qué ocurre	Disparador
CVE-2026-109618	Un error de falta de memoria (OOM) interrumpe PHP mientras los datos internos de la petición están solo parcialmente inicializados. En la limpieza de la petición, esos datos inválidos se tratan como válidos.	Una petición que lleva el proceso al `memory_limit` en el momento justo
CVE-2026-109619	Un estado interno de una petición sobrevive después de liberar su memoria (use-after-free). La siguiente petición atendida por el mismo worker usa ese estado antiguo antes de la inicialización normal.	Un error fatal o timeout que el atacante puede provocar

El escenario más grave, según el anuncio oficial, es Apache con mod_php: se demostró un exploit que se activa con una petición no autenticada antes de que se ejecute cualquier código de la aplicación. Plugins actualizados, un firewall de aplicación dentro del CMS y código limpio no impiden el ataque.

Sansec, empresa de investigación en seguridad de e-commerce, informó haber reproducido la ejecución remota sin login contra versiones recientes de WordPress, Drupal, Joomla, Magento, Laravel, Symfony, Nextcloud, phpMyAdmin, Roundcube, MediaWiki y WHMCS. Según la misma investigación, todos los disparadores conocidos llegan por peticiones multipart/form-data, y el código vulnerable existe desde PHP 5.4, de 2012.

Por qué la corrección salió con prisa

La divulgación no salió como estaba previsto. Según la PHP Foundation, el primer indicio del problema de memoria apareció en 2024, durante una auditoría externa, pero la corrección quedó trabada durante meses entre enfoques en competencia. Entre agosto y septiembre de 2026, auditorías e investigadores independientes reportaron la misma causa raíz con exploits funcionales.

20/10, ~15:00 UTC: se filtraron los números de los CVE, con fecha y nota equivocadas (10.0 en lugar de 9.2).
20/10, 19:30 UTC: PHP adelantó el aviso y movió el lanzamiento del 22 al 21 de octubre.
20/10, ~20:00 UTC: se publicó por error un video de prueba de concepto que se difundió.
21/10, 14:00 UTC: salen las versiones corregidas.

Al momento del lanzamiento, el equipo de PHP dijo no haber encontrado exploits funcionales en circulación. Sansec, en cambio, compartió un reporte de Cloudflare de intentos de ataque a las 07:43 UTC del día 21, antes del lanzamiento. Ante la duda, trátala como una falla bajo explotación activa: eso justifica la urgencia.

Paso 1: averigua qué PHP usas

El PHP de la línea de comandos no siempre es el que atiende el sitio. Comprueba lo que usa realmente el servidor web:

WordPress: en Herramientas > Salud del sitio > Información > Servidor.
Panel del hosting (cPanel, Plesk, aaPanel etc.): normalmente en "Versión de PHP" o "Selector de PHP".
Servidor propio: por los binarios instalados y los servicios en ejecución.

# versiones instaladas y servicios FPM activos
php -v
ls /usr/sbin/php-fpm* 2>/dev/null
systemctl list-units --type=service | grep -i php

# ¿Apache con mod_php?
apachectl -M 2>/dev/null | grep -i php

Atención con las distribuciones Linux: Debian, Ubuntu, RHEL y derivados suelen aplicar la corrección en el paquete sin cambiar el número de versión a 8.3.36, por ejemplo. En ese caso, la forma fiable de saber si está corregido es buscar el CVE en el changelog del paquete:

# Debian / Ubuntu (paquete instalado)
zcat /usr/share/doc/php8.3-fpm/changelog.Debian.gz | grep -E "CVE-2026-10961(8|9)"

# RHEL / AlmaLinux / Rocky
rpm -q --changelog php-fpm | grep -E "CVE-2026-10961(8|9)"

Paso 2: actualiza y reinicia

Las distribuciones y los proveedores de soporte extendido recibieron las correcciones con antelación. Actualiza con el gestor de paquetes y reinicia los procesos de PHP: mientras un worker antiguo siga vivo, sigue siendo vulnerable.

# Debian / Ubuntu (ajusta a tu versión)
sudo apt update
sudo apt install --only-upgrade 'php8.3*'
sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # si usas mod_php

# RHEL / AlmaLinux / Rocky
sudo dnf upgrade 'php*'
sudo systemctl restart php-fpm httpd

Algunos puntos que suelen quedar pendientes:

Docker: la imagen no se actualiza sola. Descarga la imagen base nueva, reconstruye y vuelve a publicar todos los servicios.
Repositorio Remi: el anuncio oficial avisó que rpms.remirepo.net, mantenido por voluntarios, no tendría paquetes el día del lanzamiento. Usa los paquetes de la distribución o compila desde el código fuente.
Hosting compartido y gestionado: muchas empresas ya están actualizando y aplicando reglas de WAF, pero confírmalo con soporte. En paneles con selector de PHP, cada versión disponible debe estar corregida.
Productos que incluyen PHP: paneles de control, appliances y sistemas de terceros dependen del proveedor. Sigue los avisos de cada uno.

Paso 3: si usas PHP 8.1 o anterior

El proyecto PHP solo da soporte de seguridad a partir de 8.2, y el propio 8.2 llega al fin de su vida el 31 de diciembre de 2026. Para versiones antiguas hay tres caminos:

Paquete corregido del proveedor: algunas distribuciones y empresas de soporte extendido hicieron backport de la corrección.
Compilar con el parche: PHP publicó backports mínimos 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.
Desconectar hasta migrar: es la recomendación del NCSC, la agencia de ciberseguridad del Reino Unido, cuando la corrección inmediata no es viable.

Si tu aplicación no funciona en PHP 8.2 o superior, es el momento de planificar la migración. También mejora el rendimiento, pero el motivo principal ahora es tener correcciones de seguridad.

Mitigación temporal: solo si no puedes actualizar hoy

El anuncio oficial enumera medidas que reducen la exposición a caminos de ataque específicos, pero deja claro que no hacen segura la instalación. Aplícalas en php.ini, en el pool de FPM o en la configuración de Apache, nunca con ini_set() ni .user.ini, y reinicia todos los workers.

; PHP-FPM: /etc/php/8.x/fpm/pool.d/www.conf
; php_admin_value impide que la aplicación sobrescriba el valor

; CVE-2026-109618 (OOM)
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M        ; 32M si necesitas subir archivos
php_admin_value[upload_max_filesize] = 7M  ; siempre menor que post_max_size

; CVE-2026-109619 (estado reutilizado)
php_admin_value[session.upload_progress.enabled] = 0

; solo en PHP 8.5
php_admin_value[fatal_error_backtraces] = 0

# Apache con mod_php
php_admin_value memory_limit -1
php_admin_value post_max_size 8M
php_admin_value session.upload_progress.enabled 0

Cuidados con estas medidas:

memory_limit = -1 abre espacio a un consumo excesivo de memoria. Compénsalo con límites en el servidor web o proxy (tamaño del cuerpo, número de campos, partes del multipart y cabeceras) y con un límite de memoria por contenedor o cgroup. PHP recomienda no usar RLIMIT_AS ni RLIMIT_DATA, que pueden disparar justamente la falla.
Ocultar errores no ayuda. display_errors, error_reporting o el operador @ no bloquean la CVE-2026-109619. Lo que reduce el riesgo es corregir errores fatales y timeouts que un visitante puede provocar.
Medida drástica: Sansec sugiere bloquear las peticiones multipart/form-data en el borde hasta actualizar. Esto rompe subidas de archivos y formularios y, en tiendas, puede afectar el checkout. Pruébalo antes.

En cuanto PHP esté actualizado, deshaz las medidas temporales, sobre todo memory_limit = -1.

Cómo comprobar si el servidor fue comprometido

Si el servidor estuvo expuesto con una versión vulnerable, actualizar cierra la puerta, pero no saca a quien ya entró. Huntress recomienda observar principalmente:

Procesos de PHP abriendo shells o herramientas de red: php-fpm, php-cgi, apache2 o httpd iniciando sh, bash, python, perl, curl, wget o nc.
Comandos de reconocimiento como whoami, id y uname -a lanzados desde el servidor web.
Archivos nuevos en la carpeta pública (webshells), cron jobs, tareas programadas o usuarios que nadie creó.

# archivos .php modificados en los últimos 3 días en la raíz web
find /var/www -name "*.php" -mtime -3 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

# cron jobs del usuario del servidor web
sudo crontab -l -u www-data

¿Encontraste algo sospechoso? Aísla el servidor, preserva los logs del servidor web y de PHP antes de tocar nada y cambia las credenciales guardadas en él: base de datos, claves de API y contraseñas de administrador. Para sitios WordPress, la guía oficial "FAQ My site was hacked" ayuda con la limpieza.

Checklist

Inventariar todos los servidores, contenedores y productos con PHP, empezando por los expuestos a internet
Actualizar a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, o confirmar el CVE en el changelog del paquete
Reiniciar PHP-FPM y Apache, y reconstruir las imágenes Docker
Plan para 8.1 o anteriores: paquete corregido, backport o desconectar
Mitigaciones temporales solo donde no se pueda actualizar, y retiradas después
Búsqueda de señales de intrusión en los servidores que estuvieron expuestos
Planificar la salida de PHP 8.2, que pierde soporte el 31/12/2026

Fuentes

¿Necesitas ayuda?

¿No sabes qué PHP usa tu sitio, usas una versión antigua o no estás seguro de si quedaste expuesto? Habla con nosotros: verificamos la versión, actualizamos sin tumbar el sitio y buscamos señales de intrusión. Y si prefieres dejar este tipo de mantenimiento a quien cuida el servidor, conoce el hosting de CPW.