VulnAudit
Crítica CVSS 9.8 CVE-2026-109618 CVE-2026-109619

PHP: dos RCE críticas sin autenticación (CVE-2026-109618 y CVE-2026-109619), explotadas activamente

PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 corrigen dos fallos de memoria en el núcleo que permiten ejecutar código de forma remota sin autenticación, ya en el catálogo KEV de CISA. Versiones afectadas, cómo comprobarlo y cómo mitigarlo.

devadmin 6 min de lectura

Resumen: el 21 de octubre de 2026 el proyecto PHP publicó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas de ejecución remota de código sin autenticación: CVE-2026-109618 y CVE-2026-109619. NVD indica que ambas figuran en el catálogo KEV de CISA (explotación activa) desde el 26 de octubre de 2026. Si ejecutas PHP en un servidor expuesto a Internet, actualiza ya.

Qué ha pasado

El 20 de octubre de 2026 php.net publicó un preaviso y, al día siguiente, el aviso "Security advisory: Critical remote code execution vulnerabilities, update now" junto con nuevas versiones de todas las ramas con soporte. Los detalles técnicos están en dos avisos de seguridad de GitHub del repositorio php/php-src:

Ambos fallos están en el núcleo de PHP (gestor de memoria de Zend y ciclo de vida de la petición), no en una extensión opcional, por lo que afectan a prácticamente cualquier instalación.

CVE-2026-109618: corrupción tras un fallo de memoria (OOM)

Cuando PHP se queda sin memoria (al superar memory_limit o por un fallo de asignación), aborta la ejecución con longjmp(). Según el aviso, en algunos contextos la memoria de la petición es accesible antes de estar completamente inicializada: si la asignación falla justo en ese momento, el apagado de la petición lee o toma decisiones a partir de esa memoria, lo que deriva en corrupción de memoria explotable (NVD la clasifica como CWE-416, use-after-free).

Lo grave es que un atacante remoto puede provocar el OOM a voluntad, por ejemplo con peticiones multipart sin Content-Length, con cabeceras de parte ilimitadas, con campos de archivo vacíos y nombres de campo anidados, o con asignaciones grandes que dependan de la aplicación. El aviso señala que mod_php (Apache) es explotable directamente, y que por análisis de código FPM y FrankenPHP también son susceptibles.

La corrección sustituye el longjmp() por un soft OOM diferido (que salta en el siguiente punto seguro de la máquina virtual) y un hard OOM inmediato con _exit() a un umbral superior.

CVE-2026-109619: estado global obsoleto entre peticiones

Parte del estado global de PHP (errores, sesión, objetos, extensiones) apunta a memoria de la petición y no se reinicia antes de liberar el heap cuando la petición termina de forma anómala: errores fatales, timeouts, require fallidos u OOM. Un proceso persistente reutilizado (worker de FPM o de Apache) usa ese estado en la siguiente petición antes de la inicialización normal: un use-after-free que, con un heap preparado, permite ejecutar código.

Los casos confirmados por el aviso son los backtraces de errores fatales de PHP 8.5 (fatal_error_backtraces) contra mod_php, y el ciclo de vida de session upload progress contra mod_php y FPM.

Versiones afectadas y corregidas

RamaVulnerableCorregida
PHP 8.5< 8.5.128.5.12
PHP 8.4< 8.4.278.4.27
PHP 8.3< 8.3.368.3.36
PHP 8.2< 8.2.358.2.35
PHP 8.1 y anterioresTodasSin release oficial (fin de soporte). El proyecto publicó backports mínimos en código fuente para 7.4, 8.0 y 8.1.

Las distribuciones aplican el parche a sus propias versiones. En Ubuntu, el aviso USN-8948-1 (21 de octubre de 2026) publica estos paquetes corregidos:

UbuntuPaquete fuenteVersión corregida
26.10php8.58.5.9-0ubuntu2.1
26.04 LTSphp8.58.5.4-0ubuntu1.5
24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13
22.04 LTSphp8.18.1.2-1ubuntu2.28

Para versiones con soporte ESM (Ubuntu Pro) existe además USN-8948-2. Fíjate en que el número de versión de Ubuntu (p. ej. 8.3.6) no coincide con el de php.net: lo que importa es el sufijo del paquete.

Puntuación CVSS

CVECNA PHP Group (CVSS 4.0)NVD (CVSS 3.1)
CVE-2026-1096189.2 Crítica9.8 Crítica — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CVE-2026-1096199.2 Crítica8.1 Alta — AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

El vector CVSS 4.0 del CNA es CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N para ambas. En NVD, las dos entradas incluyen los campos de CISA KEV: añadidas el 26 de octubre de 2026 con fecha límite de remediación el 29 de octubre para agencias federales de EE. UU.

¿Estoy afectado? Cómo comprobarlo

Comprueba la versión del intérprete que sirve la web, no solo la del CLI (pueden ser distintas):

# Versión del CLI
php -v

# Versión de PHP-FPM (en Debian/Ubuntu el binario lleva la rama)
php-fpm8.3 -v

# ¿Se usa mod_php en Apache? (el caso de mayor riesgo)
apache2ctl -M 2>/dev/null | grep -i php

# Paquetes instalados y versión candidata en Debian/Ubuntu
dpkg -l 'php*' | grep -E '^ii'
apt-cache policy php8.3-common php8.3-fpm libapache2-mod-php8.3

# Ubuntu Pro: comprobar y corregir CVE concretos
pro fix CVE-2026-109618
pro fix CVE-2026-109619

Si expose_php está activo, la cabecera X-Powered-By revela la versión desde fuera (y conviene desactivarla):

curl -sI https://tu-sitio.com | grep -i x-powered-by

Y para revisar si las mitigaciones temporales están aplicadas:

php -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled|fatal_error_backtraces'

Cómo corregirlo

1. Actualizar (la única solución completa)

# Ubuntu / Debian
sudo apt update && sudo apt install --only-upgrade 'php8.*'
# Reiniciar TODOS los workers para cargar el binario nuevo
sudo systemctl restart php8.3-fpm     # si usas FPM (ajusta la rama)
sudo systemctl restart apache2        # si usas mod_php

En RHEL/derivados, contenedores oficiales (php:8.x) o compilaciones propias, sube a 8.5.12, 8.4.27, 8.3.36 u 8.2.35 y reconstruye las imágenes. Si sigues en PHP 8.1 o anterior sin soporte de tu distribución, planifica la migración: los backports publicados son mínimos y solo en código fuente.

2. Mitigaciones temporales (si no puedes actualizar hoy)

El propio aviso de php.net advierte que estas medidas reducen la exposición a caminos de ataque concretos pero no hacen segura la instalación:

  • CVE-2026-109618: memory_limit=-1 mediante php_admin_value (para que la aplicación no pueda cambiarlo); post_max_size bajo (8M sin subidas de archivos, 32M con subidas) y upload_max_filesize por debajo; límites en el proxy o servidor web para tamaño decodificado, número de campos, partes multipart, cabeceras y profundidad de anidamiento (también para peticiones sin Content-Length); y límites de contenedor o cgroup. No uses RLIMIT_AS ni RLIMIT_DATA, que pueden provocar justo el fallo vulnerable.
  • CVE-2026-109619: session.upload_progress.enabled=0 en php.ini o en el pool de FPM y reiniciar todos los workers (no sirve ini_set() ni .user.ini); en PHP 8.5, fatal_error_backtraces=0; y corregir errores fatales y timeouts alcanzables por un atacante.
; Ejemplo de pool FPM (/etc/php/8.3/fpm/pool.d/www.conf) — solo mientras actualizas
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off

Relacionado

El 23 de octubre de 2026 php.net publicó un aviso informativo adicional sobre session upload progress (CVE-2026-115560), ligado a una configuración concreta que cambia session.serialize_handler en tiempo de ejecución con ini_set(); recomienda mantener session.upload_progress.enabled=0 hasta la próxima versión de corrección. Su aviso completo se publicará con esa versión.

Cómo te ayuda VulnAudit

El escaneo de VulnAudit identifica la versión de PHP expuesta (cabeceras y huellas del servidor) y la cruza con vulnerabilidades conocidas; con el monitoreo continuo y las alertas por WhatsApp sabrás en minutos si un sitio queda caído tras reiniciar los workers.

Referencias

Publicaciones relacionadas