Alerta crítica · Motor de PHP

  • CVSS 9,2
  • RCE sin autenticación
  • Corregido el 21/10/2026

PHP2Shell: dos vulnerabilidades críticas en el motor de PHP.

CVE-2026-109618 y CVE-2026-109619 permiten ejecutar código de forma remota, sin autenticación, en cualquier servidor que sirva páginas en PHP. Así puedes saber en dos minutos si te afecta y cómo corregirlo.

Comprobar mis proyectos Ver los comandos

Actualizado el 22 de octubre de 2026 a las 10:30 · Fuentes: php.net, CERT-FR, CISA

Leer con una IA Versión .md

Lo esencial en 60 segundos

Afecta al motor, no a tu código.

Las dos vulnerabilidades están en el propio intérprete de PHP. Cualquier servidor que procese peticiones web con una versión sin corregir está expuesto.

Actualizar tu CMS no basta.

Tener al día WordPress, Symfony, Laravel o tus paquetes de Composer no cambia nada: hay que sustituir el binario de PHP del servidor.

Solo una acción corrige de verdad.

Pasar a 8.2.35, 8.3.36, 8.4.27 o 8.5.12 y reiniciar los procesos de PHP. Las medidas provisionales solo bloquean una parte de los ataques.

Qué está pasando

Dos fallos de memoria en el corazón del intérprete

Se activan al procesar una petición HTTP, antes incluso de que se ejecute tu aplicación.

CVE-2026-109618 CVSS 9,2

Corrupción de memoria por falta de memoria

Cuando falla una asignación durante el análisis de una petición, PHP interrumpe el procesamiento y deja estructuras a medio inicializar. La limpieza de fin de petición las reutiliza: un atacante puede tomar el control con una petición manipulada.

Apache con mod_php es la configuración más expuesta.

CVE-2026-109619 CVSS 9,2

Memoria liberada y reutilizada entre dos peticiones

Un mismo proceso de PHP atiende varias peticiones seguidas. Tras un error fatal, un estado interno sigue apuntando a memoria ya liberada, que la siguiente petición vuelve a leer. El seguimiento del progreso de las subidas de archivos (session.upload_progress, activo por defecto) es la vía de ataque conocida.

Afecta a PHP-FPM, mod_php, FrankenPHP y LiteSpeed.

A quién afecta

Tu rama de PHP y lo que debes hacer

El soporte de cada rama sale del calendario oficial de php.net. Una rama en fin de soporte ya no recibe versiones corregidas.

RamaVulnerableCorregido enSoporte oficialQué hacer
8.5 8.5.0 a 8.5.11 8.5.12 Activo · seguridad → 2029 Actualizar a 8.5.12
8.4 8.4.0 a 8.4.26 8.4.27 Activo · seguridad → 2028 Actualizar a 8.4.27
8.3 8.3.0 a 8.3.35 8.3.36 Solo seguridad → 2027 Actualizar a 8.3.36
8.2 8.2.0 a 8.2.34 8.2.35 Termina el 31/12/2026 Corregir hoy, migrar antes del 31/12
8.1 y anteriores Todas ninguna Terminó el 31/12/2025 Paquete corregido de tu distribución, o migrar a 8.3+

PHP 8.2 sale del soporte dentro de diez semanas

Corrige hoy a 8.2.35 y planifica después la migración a 8.3 u 8.4. Pasado el 31 de diciembre de 2026, una nueva vulnerabilidad del motor dejará sin corrección a los servidores con 8.2, como ocurre hoy con 8.1.

Comprobar en 2 minutos

Mira en dos sitios: el repositorio y el servidor

El repositorio indica qué versión de PHP espera el proyecto. El servidor indica cuál se está ejecutando de verdad. Importan las dos.

En el repositorio · versión declarada 
$ grep -E '"php"' composer.json
  "php": "^8.1"

$ composer show --platform | grep -E "^php "
php   8.1.29   The PHP interpreter
Qué significa 
"php": "^8.1"  → el proyecto acepta 8.1: rama en fin de soporte
"php": "^8.2"  → corregir a 8.2.35, migrar antes del 31/12/2026
"php": "^8.3"  → corregir a 8.3.36 o superior
En el servidor 
$ php -v
$ ps aux | grep -E 'php-fpm|lsphp'
En WordPress 
Herramientas › Salud del sitio › Información › Servidor

Los comandos «En tus servidores» y «WordPress» aparecen al hacer clic en el paso 2 o 3.

Lo que LibWatch hace por ti

Todos tus proyectos PHP revisados de golpe y vigilados cada noche.

  • Detecta la versión de PHP declarada por cada repositorio y por cada sitio WordPress, y la cruza con las vulnerabilidades y el fin de soporte.
  • Integra las alertas del CERT-FR sobre PHP: una versión exacta de PHP afectada (8.2.30, no ^8.2) se señala como muy tarde la noche siguiente.
  • Lo revisa todo de nuevo cada noche, incluso los proyectos que nadie toca, y avisa al equipo por correo, Slack, Zulip o webhook.

Su límite: LibWatch ve la versión declarada en el repositorio, no necesariamente la instalada en tus servidores. Comprueba también php -v en producción.

Comprobar mis proyectos O prueba un composer.lock sin cuenta →

Tu código se queda en tu casa: LibWatch lee tus archivos de dependencias y solo guarda la lista de tus paquetes y sus versiones. Cómo funciona →

Corregir

Tres pasos, y el segundo es el que se olvida

Solo actualizar PHP corrige las dos vulnerabilidades. Conserva tus registros de acceso y de errores: se vieron intentos de explotación desde el 17 de octubre.

Actualizar PHP, o reconstruir tus imágenes Docker

Actualizar el host no corrige el PHP que se ejecuta dentro de un contenedor: reconstruye la imagen desde una base corregida.

En Debian / Ubuntu 
$ sudo apt update && sudo apt install --only-upgrade 'php*'

# Docker: partir de una imagen base corregida
$ docker build --pull --no-cache -t mon-app:corrigee .

Reiniciar todos los procesos de PHP

Sin reinicio, la versión vulnerable antigua sigue cargada en memoria, aunque el paquete esté actualizado en el disco.

Reiniciar y comprobar 
$ sudo systemctl restart php8.3-fpm
$ sudo systemctl restart apache2

# la fecha de inicio debe ser posterior a la actualización
$ ps -eo pid,lstart,cmd | grep -E 'php-fpm|apache2'

Comprobar la versión servida

Verifica la versión que ve una petición web real, no solo la de la línea de comandos: pueden diferir.

Medidas provisionales

Si no puedes corregir en una hora

Bloquea

Desactivar el seguimiento de las subidas

  • — Las vías de ataque conocidas de CVE-2026-109619.
  • — Las subidas de archivos siguen funcionando con normalidad.
  • — Solo surte efecto tras reiniciar los procesos de PHP.
php.ini 
session.upload_progress.enabled = Off

No bloquea

Lo que deja abierto

  • — CVE-2026-109618, la corrupción de memoria por falta de memoria.
  • — Las demás vías posibles hacia la segunda vulnerabilidad.
  • — Las reglas WAF (Cloudflare, AWS, Azure…) reducen el riesgo, pero no sustituyen a la actualización.

Solo actualizar PHP corrige

Los responsables de PHP, el CERT-FR y la CISA coinciden: una medida provisional compra tiempo, nada más.

Cronología

Cinco días, del primer ataque a esta página

17/10/2026

Primer intento de explotación

Observado por Amazon Threat Intelligence, cuatro días antes de la corrección.

20/10/2026

Filtración y anuncio anticipado

Un mensaje eliminado anuncia un CVSS de 10, desmentido después: la puntuación oficial es 9,2.

21/10/2026

Correcciones y alertas

PHP publica 8.5.12, 8.4.27, 8.3.36 y 8.2.35. CERT-FR (ALE-014) y CISA alertan. Cloudflare despliega reglas WAF.

22/10/2026

Esta página

Se actualiza con cada novedad: inclusión en el catálogo KEV, puntuación EPSS, paquetes de las distribuciones.

Preguntas frecuentes

Lo que nos preguntan desde el 21 de octubre

¿Otra pregunta? Escríbenos →
¿Basta con actualizar WordPress, Symfony o Laravel?
No. La vulnerabilidad está en el motor de PHP del servidor, no en tu CMS ni en tus paquetes de Composer. Mientras PHP no esté en 8.2.35, 8.3.36, 8.4.27 u 8.5.12 y sus procesos no se hayan reiniciado, el sitio sigue expuesto.
Estoy en un alojamiento compartido o en WordPress gestionado: ¿qué hago?
Es tu proveedor de alojamiento quien actualiza PHP. Comprueba la versión servida en Herramientas › Salud del sitio › Información › Servidor: si es anterior a 8.2.35, 8.3.36, 8.4.27 u 8.5.12, pide la actualización a tu proveedor o elige una versión corregida en tu área de cliente, si lo permite.
¿Por qué una puntuación de 9,2 y no 10 como se anunció al principio?
El 20/10/2026, un mensaje que después se eliminó anunciaba un CVSS de 10. Se desmintió más tarde: la puntuación oficial es 9,2 (CVSS v4.0), para cada una de las dos vulnerabilidades.
¿Cómo sé si mi servidor fue atacado antes de la actualización?
Conserva tus registros de acceso y de errores: se vieron intentos de explotación desde el 17 de octubre, cuatro días antes de la corrección. La actualización cierra las vulnerabilidades, pero no borra una intrusión anterior: si tienes dudas, haz que analicen esos registros.
¿Necesita LibWatch acceder a mi código para detectar la vulnerabilidad?
No. LibWatch lee tus archivos de dependencias y solo guarda la lista de tus paquetes y sus versiones. Su límite: LibWatch ve la versión declarada en el repositorio, no necesariamente la instalada en tus servidores. Comprueba también php -v en producción.

Fuentes

Verificadas el 22/10/2026. Corregimos esta página en cuanto cambia una fuente.