Fallos RCE críticos en PHP: parches CVE-2026-109618 y 109619

El 21 de octubre de 2026, el equipo de desarrollo de PHP publicó las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas conocidas en la comunidad de seguridad como “php2shell”: CVE-2026-109618 y CVE-2026-109619. Ambos fallos pueden permitir la ejecución remota de código (RCE) sin autenticación en servidores web expuestos. El mensaje de los mantenedores de PHP es contundente: actualizar el entorno de ejecución de PHP es la única solución completa.

Dado que PHP impulsa cerca del 70 % de los sitios web que utilizan lenguajes de servidor conocidos, el anuncio activó alertas inmediatas de centros oficiales de respuesta a incidentes, incluidos CERT-EU (aviso de seguridad 2026-018) y el Centro Nacional de Ciberseguridad de los Países Bajos (NCSC-NL). En toda Europa y a nivel internacional, numerosos portales públicos y servicios empresariales activaron temporalmente el modo de mantenimiento mientras aplicaban los parches.

Filtración previa, cronología del descubrimiento y causa raíz

Según el análisis técnico de The PHP Foundation, el comportamiento de falta de memoria (OOM) detrás de CVE-2026-109618 se observó por primera vez durante una auditoría externa en 2024 financiada por Sovereign Tech Agency y realizada por OSTIF y Quarkslab. En aquel momento, la explotación parecía teórica y los cambios propuestos amenazaban la compatibilidad con extensiones existentes. La situación cambió tras la incorporación de PHP al programa Patch the Planet a finales de julio de 2026: el 11 de agosto de 2026, el investigador Ryan Austin de Calif (bajo la dirección de Thai Duong) demostró una vía de ejecución remota de código incondicional y la reportó a Volker Dusch en The PHP Foundation. OpenAI informó de manera independiente la misma causa raíz ese mismo día, seguida de vectores adicionales reportados por Wiz el 24 de agosto y OpenAI el 18 de septiembre.

El proceso de divulgación coordinada se vio alterado unas 24 horas antes del lanzamiento previsto. Hacia las 15:00 UTC del 20 de octubre, los dos identificadores CVE y sus títulos se filtraron en fuentes públicas antes de que existieran paquetes corregidos. Esta filtración llevó a CERT-EU y NCSC-NL a emitir alertas preventivas urgentes. Cabe destacar un matiz importante: la desconexión temporal de numerosos sitios web entre el 20 y el 21 de octubre respondió a cierres preventivos realizados por los propios administradores mientras esperaban el parche, y no a caídas masivas provocadas por ataques.

En el plano técnico, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, NVD) se produce cuando ocurre una condición de falta de memoria (OOM) mientras PHP analiza los datos de una solicitud entrante, dejando estructuras parcialmente inicializadas que permiten corromper la memoria y ejecutar código (CWE-119, CWE-787). Por su parte, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, NVD) es un fallo use-after-free (CWE-416) en el que ciertos estados internos del progreso de carga de sesiones o trazas de error persisten tras liberarse la memoria de la solicitud. PHP califica ambos fallos con 9,2 (Crítico) en CVSS v4.0, mientras que NVD les asigna 9,8 (Crítico) en CVSS v3.1.

Configuraciones expuestas y versiones corregidas

El aviso oficial de PHP advierte que cualquier instalación de PHP que atienda solicitudes web está expuesta, incluidos PHP-FPM, Apache mod_php, php.exe, CGI/FastCGI y entornos de trabajadores persistentes como FrankenPHP, RoadRunner y Swoole. El mayor nivel de riesgo recae sobre Apache mod_php, donde todos los hilos comparten el mismo espacio de memoria.

Quienes utilizan PHP-FPM tampoco deben confiarse. Aunque FPM ofrece mayor aislamiento frente a CVE-2026-109618, el seguimiento de progreso de subida de sesiones implicado en CVE-2026-109619 viene activado por defecto y puede explotarse en instalaciones estándar de FPM sin necesidad de un script personalizado. Los investigadores confirmaron la ejecución remota de código tanto en mod_php como en FPM. Además, el informe técnico de Tenable recuerda que el proceso maestro de FPM reinicia automáticamente los trabajadores que fallan, por lo que un servicio aparentemente estable puede haber sufrido intentos de explotación; Tenable también alerta sobre repositorios falsos en GitHub que simulan ser pruebas de concepto (PoC) de “php2shell” para distribuir malware ladrón de información (infostealers).

Las versiones oficiales que corrigen ambas vulnerabilidades son PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 y PHP 8.2.35. Dada la gravedad del problema, el equipo de PHP también publicó ramas con parches mínimos en código fuente para PHP 7.4, 8.0 y 8.1. En distribuciones Linux como Debian y Ubuntu, los parches se integran mediante backports sobre las versiones del paquete de la distribución, por lo que debe comprobarse la versión exacta del paquete instalado frente a los boletines de la distribución en lugar de confiar únicamente en la salida de php -v (Debian Security Tracker, Ubuntu Security).

Lista de verificación y medidas temporales de mitigación

1. Inventario de entornos PHP: Identifique todas las instancias de PHP que procesan tráfico HTTP externo o interno —incluidos pools de FPM, Apache mod_php, contenedores y trabajadores de FrankenPHP, RoadRunner o Swoole— y retire cualquier página pública con phpinfo().

2. Actualización y reinicio de procesos: Actualice a PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35 (o al paquete parcheado de su distribución Linux) y reinicie tanto el servidor web como todos los procesos trabajadores de PHP-FPM para asegurar que ningún binario vulnerable siga activo en memoria.

3. Mitigaciones temporales (solo mientras se aplica el parche): PHP subraya que los ajustes de configuración solo reducen ciertas rutas de ataque y no hacen segura una instalación sin parchear. Mientras se programa la actualización, puede reducirse la superficie de CVE-2026-109618 fijando memory_limit=-1 mediante php_admin_value (para impedir cambios con ini_set() o .user.ini) y reduciendo post_max_size y upload_max_filesize, asegurándose de no definir límites RLIMIT_AS ni RLIMIT_DATA en el sistema operativo, ya que provocarían fallos de memoria aún antes. Para CVE-2026-109619, desactive session.upload_progress.enabled=0 y, en PHP 8.5, establezca fatal_error_backtraces=0, teniendo presente que el operador @ sigue generando estructuras internas de error incluso con error_reporting y display_errors desactivados.

4. Revisión de registros de fallos: Analice los registros de FPM y del servidor web en busca de caídas repetidas de procesos trabajadores, solicitudes multipart inusualmente grandes y actividad sospechosa de carga de sesiones. Unos registros de acceso HTTP limpios no garantizan por sí solos la ausencia de intentos, ya que las solicitudes que abortan el proceso antes de finalizar rara vez quedan registradas de forma habitual.

Perspectiva de LeakData: Cómo proteger credenciales y datos tras vulnerabilidades críticas en servidores

En primer lugar, queremos transmitir tranquilidad a nuestros usuarios y clientes: la plataforma y los servicios de LeakData no están afectados por CVE-2026-109618 ni por CVE-2026-109619. Tras la publicación de los boletines internacionales, nuestro equipo de seguridad verificó todos los controles perimetrales y confirmó la plena protección de nuestros servicios. Sin embargo, para las organizaciones que operan aplicaciones web, el riesgo real de vulnerabilidades RCE como php2shell suele materializarse semanas después en forma de filtraciones de credenciales y bases de datos.

Cuando un atacante logra ejecutar código en un servidor web vulnerable, su prioridad inmediata suele ser extraer archivos de configuración, credenciales de bases de datos, claves de API, tokens de sesión activos y tablas de usuarios. Incluso después de actualizar PHP a una versión segura, las credenciales corporativas y los datos robados durante la ventana de exposición suelen aparecer poco después en registros de infostealers, canales de Telegram y foros de filtraciones.

Desde LeakData ayudamos tanto a usuarios individuales como a equipos de seguridad corporativos a detectar rápidamente esa exposición secundaria. Una vez aplicados los parches en sus servidores, puede utilizar LeakData para comprobar si las direcciones de correo de su dominio, cuentas de administración o contraseñas aparecen en conjuntos de datos filtrados recientes, así como activar la supervisión continua de dominios e identidades para recibir alertas tempranas y rotar contraseñas o claves de inmediato. Puede consultar todos los detalles en nuestra página Cómo funciona.