Vulnerabilidades críticas en PHP (CVE-2026-109618 y CVE-2026-109619): qué son y cómo proteger tu web

 

Resumen rápido

El 21 de octubre de 2026, el proyecto PHP publicó actualizaciones de emergencia para corregir dos vulnerabilidades críticas de ejecución remota de código (RCE), identificadas como CVE-2026-109618 y CVE-2026-109619 y conocidas como "PHP2Shell". Ambas tienen una puntuación CVSS v4 de 9.2 y afectan al núcleo de PHP, no a un framework o CMS concreto. Si tu web usa PHP, esto te afecta.

Qué debes hacer: actualizar PHP a una versión corregida (8.5.12, 8.4.27, 8.3.36 u 8.2.35) y reiniciar los servicios. Si no puedes actualizar hoy, aplica las mitigaciones temporales que se explican más abajo.

Qué ha pasado

El 20 de octubre, el equipo de PHP avisó de que prepararía versiones de seguridad fuera de calendario. Ese mismo día se filtraron en un foro público datos sobre los fallos, antes de la divulgación coordinada, y el lanzamiento se mantuvo para el 21 de octubre. Según PHP, todas las instalaciones que sirven peticiones web están en riesgo: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed.

El riesgo es mayor con mod_php, porque existe un exploit demostrado en el que una petición sin autenticar puede activar el fallo antes de que se ejecute una sola línea del código de tu aplicación. PHP-FPM también se considera vulnerable, así que no conviene dejarlo para después.

A fecha de redacción, varias fuentes indican que se ha publicado una prueba de concepto, pero no habían confirmado explotación activa generalizada. Eso puede cambiar rápido, por lo que conviene actuar ya.

Los dos fallos, explicados

CVE-2026-109618: corrupción de memoria por falta de memoria (OOM). Cuando una petición supera el memory_limit, PHP aborta la petición de forma abrupta. Un atacante puede provocar ese error en un momento en que la memoria de la petición no está completamente inicializada, corromperla y acabar ejecutando código con los permisos del proceso del servidor web.

CVE-2026-109619: estado interno obsoleto (use-after-free). Parte del estado interno de la petición sobrevive más tiempo que la memoria de la que depende. Si no se limpia correctamente antes de liberar esa memoria, se puede acceder a ella después, lo que permite ejecutar código.

En ambos casos, el impacto potencial es el control del proceso web: leer archivos de tu sitio, robar credenciales de la base de datos, modificar contenido o instalar puertas traseras.

Versiones afectadas y versiones corregidas

Rama de PHP	Vulnerable si es anterior a	Actualiza a
8.5	8.5.12	8.5.12
8.4	8.4.27	8.4.27
8.3	8.3.36	8.3.36
8.2	8.2.35	8.2.35

Las ramas 8.1 y anteriores ya no reciben actualizaciones oficiales de la comunidad. Por la gravedad del caso, el equipo de PHP creó retroadaptaciones mínimas del parche para 7.4, 8.0 y 8.1, pero la recomendación es migrar a una versión con soporte, usar los paquetes de tu distribución o compilar desde el código fuente.

Cómo saber si estás afectado

1. Comprueba la versión que usa tu servidor web, no solo la de la consola. Un php -v muestra la versión de línea de comandos, que puede ser distinta de la que usa PHP-FPM o Apache. Revisa también el panel de tu hosting.
2. Ten en cuenta los parches retroadaptados. Algunas distribuciones (Debian, Ubuntu, RHEL y derivadas) corrigen el fallo sin cambiar el número de versión. En ese caso, confirma el estado en el aviso de seguridad de tu distribución o en el changelog del paquete.
3. Inventaría todo lo que incluya PHP: contenedores Docker, imágenes base, aplicaciones empaquetadas, entornos de pruebas y servidores olvidados.

Cómo solucionarlo

Opción 1: servidor propio (Debian/Ubuntu)

sudo apt update
sudo apt upgrade

Después, reinicia los servicios para que los procesos antiguos no sigan en memoria (ajusta el nombre a tu versión):

sudo systemctl restart php8.3-fpm
sudo systemctl restart apache2   # o nginx, según tu caso

Opción 2: Docker

Actualiza la imagen base de PHP a una etiqueta corregida, reconstruye la imagen y vuelve a desplegar los contenedores. No basta con reiniciar un contenedor existente.

Opción 3: hosting compartido o gestionado

Entra en el panel (cPanel, Plesk u otro), cambia la versión de PHP a una rama corregida y, si tu proveedor aún no ha publicado la actualización, escríbele para preguntar por su calendario de parcheo.

Opción 4: WordPress, Drupal, Moodle, Laravel y otros

Estas aplicaciones no tienen el fallo, lo tiene el PHP sobre el que se ejecutan. Actualizar el CMS no soluciona el problema: hay que actualizar PHP en el servidor.

Si no puedes actualizar todavía: mitigaciones temporales

El propio proyecto PHP insiste en que actualizar es la única solución completa. Mientras tanto, estas medidas reducen el riesgo, pero no sustituyen al parche. Aplícalas en un lugar que la aplicación no pueda sobrescribir (por ejemplo, php_admin_value en el pool de PHP-FPM o en la configuración de Apache) y reinicia todos los procesos de PHP.

Ajuste	Para qué fallo	Nota
memory_limit = -1	CVE-2026-109618	Elimina el límite de memoria por petición. Comprueba que ningún pool, directorio o aplicación vuelva a fijar un límite finito.
post_max_size = 8M (32M si necesitas subir archivos) y upload_max_filesize por debajo	CVE-2026-109618	Mantiene pequeño el tamaño de las peticiones.
session.upload_progress.enabled = 0	CVE-2026-109619	Bloquea las vías confirmadas con sesiones, pero no todas las variantes posibles.
fatal_error_backtraces = 0 (solo PHP 8.5)	CVE-2026-109619	Bloquea la vía confirmada de trazas de errores fatales.

Importante: quitar el límite de memoria tiene un coste. Un script defectuoso o un atacante podrían consumir toda la RAM del servidor. Compénsalo limitando el tamaño de las peticiones en el servidor web o proxy (por ejemplo, client_max_body_size en Nginx o LimitRequestBody en Apache), fijando límites de memoria a nivel de contenedor o del sistema, y vigilando el consumo. Revierte estos cambios cuando hayas actualizado.

Medidas adicionales mientras llega el parche:

• Poner un cortafuegos de aplicaciones web (WAF) delante del sitio.
• Restringir el acceso por IP o añadir autenticación a nivel de red en paneles y áreas internas.
• Si es viable, sacar temporalmente de línea los servicios PHP expuestos a internet que no sean esenciales.

Cómo detectar si ya te han atacado

Tras actualizar, revisa si hubo actividad sospechosa durante los días de exposición:

• Procesos o comandos inesperados lanzados por el usuario del servidor web (www-data, apache, nginx).
• Archivos nuevos o modificados en el directorio web, sobre todo archivos .php desconocidos.
• Cuentas de usuario nuevas, tareas programadas (cron) que no reconozcas o claves SSH añadidas.
• Conexiones salientes extrañas desde el servidor.
• Picos de errores de memoria o peticiones anómalas muy grandes en los registros.

Si encuentras algo sospechoso, aísla el servidor, restaura desde una copia limpia anterior a la exposición y cambia contraseñas, claves de API y credenciales de base de datos.

Lista de comprobación final

• Identificar todas las instalaciones de PHP (servidores, contenedores, hosting).
• Actualizar a 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o confirmar el parche de tu distribución.
• Reiniciar PHP-FPM, Apache o el servidor que corresponda.
• Si usas PHP 8.1 o anterior, planificar la migración a una versión con soporte.
• Aplicar mitigaciones temporales si el parche no es inmediato, y revertirlas después.
• Revisar registros y archivos en busca de actividad sospechosa.
• Mantener copias de seguridad recientes y probadas.

Conclusión

Se trata de fallos en el propio intérprete de PHP, con un exploit demostrado y una prueba de concepto circulando. La buena noticia es que existe parche oficial y que aplicarlo es sencillo en la mayoría de los casos. Actualiza cuanto antes, reinicia los servicios y comprueba que la versión corregida es la que realmente atiende las peticiones de tu web.