PHP corrige dos vulnerabilidades críticas de RCE sin autenticación (CVE-2026-109618, CVE-2026-109619): [Actualizado para CVE-2026-115560]

El miércoles 21 de octubre de 2026 a las 14:00 UTC, el proyecto PHP lanzó PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos vulnerabilidades críticas, ambas con una calificación CVSS v4.0 de 9.2, que pueden permitir la ejecución remota de código sin autenticación. El equipo de seguridad de PHP advierte: «No hay mitigaciones completas; actualizar es la única opción segura».

Se trata de errores en el entorno de ejecución de PHP, no en un paquete de Composer. Esto cambia la forma de detectarlos y corregirlos, como explicamos a continuación.

En resumen Si usas PHP para atender solicitudes web (PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed), actualiza hoy mismo a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usas 8.1 o una versión anterior, obtén un paquete con el backport de tu distribución o proveedor LTS, o actualiza.

Qué ocurrió

Todas las horas están en UTC.

• 20 de octubre: El equipo de seguridad de PHP publicó un aviso previo sobre una versión de seguridad crítica programada para el 21 de octubre a las 14:00 UTC. Corrige dos vulnerabilidades evaluadas con CVSS v4.0 de 9.2. Se reservó el derecho de lanzar la versión antes si se filtraban detalles o se detectaba explotación activa.

• 21 de octubre, antes de las 14:00 UTC: Snyk publicó avisos para ambos CVE, SNYK-UNMANAGED-PHP-21347795 (CVE-2026-109618) y SNYK-UNMANAGED-PHP-21347796 (CVE-2026-109619), para alertar a los clientes sobre las medidas que deberán tomar y lograr que los proyectos monitoreados reciban una alerta en cuanto se conozcan las versiones corregidas.

• 21 de octubre, 14:00 UTC: Se publican el aviso de seguridad de PHP y las cuatro versiones corregidas. En unos 30 minutos, Snyk actualiza sus avisos con todos los detalles pertinentes, incluidos los rangos afectados y las versiones corregidas.

• A partir del 21 de octubre: Las distribuciones de Linux (que recibieron los parches por adelantado) comienzan a publicar sus propios avisos. Snyk publica avisos para ellas a medida que aparecen, por ejemplo, SNYK-UBUNTU2604-PHP85-21373920. La lista actualizada está en CVE-2026-109618 y CVE-2026-109619.

Actualización del 23 de octubre: mantén session.upload_progress.enabled=0

El 23 de octubre, el proyecto PHP publicó un aviso informativo para CVE-2026-115560, un CVE reservado pero aún no asignado. Describe una vía de evasión parcial para CVE-2026-109619. La configuración que la evita, session.upload_progress.enabled=0, ya figuraba como mitigación para CVE-2026-109619.

PHP no está apresurando una corrección de emergencia porque las condiciones previas para la explotación son poco frecuentes y es improbable que se den en la mayoría de las implementaciones. Una aplicación debe configurar session.serialize_handler como php_binary or php_serialize y luego cambiarlo a php en tiempo de ejecución con ini_set() antes de llamar a session_start(), mientras está habilitado el seguimiento del progreso de carga de sesiones. Las aplicaciones que nunca cambian el controlador de serialización en tiempo de ejecución pueden mantener la función habilitada.

Las vulnerabilidades

Ambas se encuentran en el ciclo de vida de las solicitudes del motor de PHP, por lo que se puede llegar a ellas antes de que se ejecute cualquier código de la aplicación. Este es uno de los factores que hace que estas vulnerabilidades sean tan extendidas y peligrosas.

Detalles técnicos

CVE-2026-109618, RCE por corrupción de memoria agotada: El manejo de memoria agotada puede interrumpir PHP cuando los datos internos de una solicitud solo se inicializaron parcialmente. Después, la limpieza de la solicitud trata los datos no válidos como si fueran válidos. Un atacante que pueda llevar un proceso de trabajo al límite de memoria con una solicitud maliciosa puede provocar la interrupción.

CVE-2026-109619, RCE por estado global obsoleto: El estado interno propio de una solicitud puede persistir después de que se haya liberado la memoria que lo respalda. Una solicitud posterior gestionada por el mismo proceso de trabajo podría usar ese estado obsoleto antes de que la inicialización normal lo restablezca. En un modelo con procesos de trabajo de larga duración, esto constituye un uso después de liberar entre solicitudes.

Estos errores se encontraron con ayuda de IA, en un entorno de ejecución que lleva tres décadas en producción. En un mundo de LLM y agentes, todos seguimos usando servidores, y el modelo que encontró estas vulnerabilidades es del mismo tipo que ahora tienen los atacantes. Esa es la premisa de Evo by Snyk: seguridad impulsada por IA para las aplicaciones que ejecutan los agentes, no solo para los propios agentes. El descubrimiento asistido por IA también explica por qué PHP2Shell no será la última falla de este tipo y por qué los tiempos de respuesta ahora se miden en horas.

A quién afecta

Todas las instalaciones de PHP que atienden solicitudes web están en riesgo. Esto incluye PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP, LiteSpeed, entre otros. Apache con mod_php es el más vulnerable: se demostró un exploit en el que una sola solicitud sin autenticación desencadena el ataque antes de que se ejecute el código de la aplicación.

PHP 8.1 y las versiones anteriores ya no reciben actualizaciones del proyecto PHP. Por eso, una instalación sin parches de 8.1, 8.0 o 7.4 está afectada y no tiene una corrección upstream. Dada la gravedad, el equipo de seguridad de PHP sí publicó backports mínimos del código fuente para 7.4, 8.0 y 8.1, destinados a quienes compilan desde el código fuente o no tienen un proveedor LTS.

Qué debes hacer ahora

1. Actualiza. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Ten en cuenta que 8.2 llega al final de su vida útil el 31 de diciembre de 2026; si usas 8.2, también es momento de planificar la siguiente actualización.

2. Consulta a tu proveedor. Las distribuciones de Linux y los proveedores LTS recibieron los parches antes del lanzamiento. Instala sus paquetes actualizados en lugar de esperar a compilar desde el código fuente. Una compilación de la distribución con parches podría conservar un número de versión anterior, así que consulta también el aviso o el nivel de parche de la distribución.

3. Verifica qué se está ejecutando realmente. Comprueba la versión de PHP en cada host e imagen (php -v o la etiqueta de la imagen). Los resultados de los análisis por sí solos no confirman que una instalación esté corregida.

4. Si hoy no puedes actualizar, PHP recomienda mitigaciones que reducen la exposición a rutas específicas, pero no hacen que una instalación sea segura: configura memory_limit=-1 en un lugar que las aplicaciones no puedan sobrescribir, usa un post_max_size bajo, establece session.upload_progress.enabled=0 y reinicia todos los procesos de trabajo; en 8.5, configura fatal_error_backtraces=0. Consulta el aviso correspondiente para conocer las limitaciones de cada opción.

5. Hayas actualizado o no, mantén session.upload_progress.enabled=0 hasta la próxima versión regular de corrección de errores si tu aplicación cambia session.serialize_handler en tiempo de ejecución. Consulta la actualización anterior para obtener más detalles.

6. Si usas PHP 8.1 o una versión anterior, actualiza a una versión compatible u obtén un paquete con backport de tu distribución o proveedor LTS. Los backports del código fuente de PHP para 7.4, 8.0 y 8.1 son el último recurso para los equipos que compilan desde el código fuente.

El lado del código abierto

El equipo de seguridad de PHP avisó al ecosistema con un día de anticipación e indicó una hora fija, la gravedad y que no compartiría detalles de explotación. Compartió los parches con las distribuciones de Linux para que pudieran publicar las correcciones empaquetadas junto con la versión del código fuente. Publicó backports para versiones sin soporte (7.4, 8.0, 8.1). También avisó a los usuarios de un popular repositorio comunitario (rpms.remirepo.net) que no se actualizaría el primer día y les indicó qué hacer en su lugar. Además, sus recomendaciones de mitigación explican con transparencia qué no protege cada configuración.

Así luce una divulgación coordinada bien hecha por un proyecto gestionado por voluntarios. También por eso, en Snyk pudimos publicar los avisos antes del lanzamiento y completarlos poco después: un calendario público permite que todos los equipos posteriores se preparen.

Comportamiento de Snyk SCA

Snyk Open Source lee lo que declara tu aplicación en archivos de manifiesto o compilación, como composer.json y composer.lock. El intérprete de PHP no es una dependencia declarada. Se instala mediante un Dockerfile, un paquete de distribución, una imagen de plataforma o manualmente. Una restricción "php": ">=8.2" en composer.json indica qué acepta la aplicación, pero no qué versión está implementada exactamente.

Cómo te ayuda la plataforma Snyk a encontrar instancias de PHP expuestas

Encuentra tu superficie de ataque de PHP con Snyk API & Web

Antes de aplicar parches, necesitas una lista. La pestaña Discovery de Snyk API & Web enumera los activos encontrados en tus dominios y obtiene una huella de su stack tecnológico. Abre Discovery, configura el filtro Tech como PHP y verás todos los hosts y endpoints detectados donde se identificó PHP, con su nivel de riesgo, puntuación y fecha de última detección, listos para analizar o agregar como objetivo.

El mismo filtro Tech también está disponible en la lista de Targets, para que puedas filtrar de la misma manera las aplicaciones que agregaste.

Esto no indica la versión de PHP. Te muestra dónde buscar, un paso fundamental para corregir el problema.

Prueba la vulnerabilidad con Snyk API & Web

Snyk API & Web te permite analizar tus aplicaciones y API, y detectar si son vulnerables a PHP2Shell.

Un análisis con un perfil completo ahora prueba la vulnerabilidad PHP2Shell. Además, puedes crear un perfil de análisis personalizado que solo compruebe PHP2Shell, para saber rápidamente si tus aplicaciones son vulnerables o si ya aplicaste la corrección.

Qué estamos haciendo

• Los avisos para ambos CVE se publicaron antes del lanzamiento de PHP a las 14:00 UTC y se actualizaron con las versiones afectadas y los detalles de las correcciones en unos 30 minutos.

• También se publicó un aviso para CVE-2026-115560, que se actualizará cuando se publiquen más detalles y su corrección.

• Estamos importando los avisos de las distribuciones a medida que los publica cada distribución de Linux. Ubuntu y Red Hat ya están disponibles.

• Ya está disponible un informe Zero Day sobre este evento para proyectos Unmanaged y Container.

Como siempre, el equipo de investigación de seguridad de Snyk está siguiendo esta divulgación y actualizará los avisos a medida que reciba información nueva. Si tienes preguntas, comunícate con tu equipo de cuenta de Snyk o con Support.

Referencias

• Aviso de seguridad de PHP: vulnerabilidades críticas de ejecución remota de código; actualiza ahora (21 de octubre de 2026)

• Aviso informativo de PHP: progreso de carga de sesiones (23 de octubre de 2026)

• Aviso de Snyk Unmanaged para CVE-2026-109618

• Aviso de Snyk Unmanaged para CVE-2026-109619

• Todos los avisos de Snyk para CVE-2026-109618 y CVE-2026-109619

• Documentación de Snyk Open Source

• Documentación del análisis de dependencias no administradas de Snyk C/C++