PHP corrige dos vulnerabilidades críticas de RCE sin autenticación (CVE-2026-109618, CVE-2026-109619): actualiza ahora
22 de octubre de 2026
0 minutos de lecturaEl 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 recomienda: «No existen mitigaciones completas; actualizar es la única opción segura».
Se trata de errores en el runtime 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 a 8.5.12, 8.4.27, 8.3.36 o 8.2.35. Si usas la versión 8.1 o una anterior, obtén un paquete con una corrección retroportada de tu distribución o proveedor de soporte LTS, o actualiza.
Qué pasó
Todas las horas corresponden a UTC.
20 de octubre: El equipo de seguridad de PHP publicó un aviso anticipado sobre una versión de seguridad crítica programada para el 21 de octubre a las 14:00 UTC. Corrige dos vulnerabilidades con una calificación CVSS v4.0 de 9.2. El equipo se reservó el derecho de lanzarla 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 acciones que deberán tomar y para 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, se actualizan los avisos de Snyk con todos los detalles relevantes, incluidos los rangos afectados y las versiones corregidas.
Desde el 21 de octubre: Las distribuciones de Linux (que recibieron los parches por adelantado) empiezan 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.
Las dos vulnerabilidades
Ambas están en el ciclo de solicitudes del motor de PHP, por lo que se pueden alcanzar antes de que se ejecute cualquier código de la aplicación. Este es uno de los factores que hacen que estas vulnerabilidades sean tan generalizadas y peligrosas.
Detalles técnicos
CVE-2026-109618, RCE por corrupción de memoria ante falta de memoria: El manejo de la falta de memoria puede interrumpir PHP mientras los datos internos de la solicitud están parcialmente inicializados. Luego, al limpiar la solicitud, se tratan los datos no válidos como si fueran válidos. Un atacante que pueda llevar un proceso de trabajo a su límite de memoria mediante una solicitud maliciosa puede provocar la interrupción.
CVE-2026-109619, RCE por estado global obsoleto: El estado interno de una solicitud puede persistir después de que se haya liberado la memoria que lo respalda. Una solicitud posterior procesada por el mismo proceso de trabajo puede usar ese estado obsoleto antes de que la inicialización normal lo restablezca. En un modelo de procesos de trabajo de larga duración, esto constituye un uso después de liberar entre solicitudes.
Estos errores se detectaron con ayuda de IA en un runtime que lleva tres décadas en producción. En un mundo de LLM y agentes, todos siguen ejecutando servidores, y el modelo que los detectó es del mismo tipo que ahora tienen los atacantes. Esta es la premisa de Evo by Snyk: seguridad impulsada por IA para las aplicaciones que usan los agentes, no solo para los agentes mismos.
Quiénes se ven afectados
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, etc. Apache con mod_php es el más vulnerable: se demostró un exploit en el que una sola solicitud sin autenticación activa 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 lo que una instalación sin parches de 8.1, 8.0 o 7.4 no tiene una corrección del proyecto original. Dada la gravedad, el equipo de seguridad de PHP sí publicó correcciones mínimas del código fuente para las versiones 7.4, 8.0 y 8.1, para quienes compilan desde el código fuente o no cuentan con un proveedor LTS.
Qué debes hacer ahora
Actualiza. Las versiones corregidas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Ten en cuenta que la versión 8.2 llega al fin de su vida útil el 31 de diciembre de 2026. Si usas la 8.2, aprovecha también para planificar la actualización a la siguiente versión.
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 corregida de una distribución puede conservar un número de versión anterior, así que revisa también el aviso o el nivel de parche de la distribución.
Verifica qué se está ejecutando realmente. Comprueba la versión de PHP en cada host e imagen (
php -vo la etiqueta de la imagen). Los resultados del análisis por sí solos no pueden confirmar que una instalación esté corregida.Si hoy no puedes actualizar, PHP enumera medidas de mitigación que reducen la exposición a rutas específicas, pero no hacen que una instalación sea segura: configura memory_limit=-1 donde las aplicaciones no puedan anularlo, usa un post_max_size bajo, configura session.upload_progress.enabled=0 y reinicia todos los procesos de trabajo; en la versión 8.5, configura fatal_error_backtraces=0. Consulta el aviso correspondiente para conocer las salvedades de cada medida.
Si usas PHP 8.1 o una versión anterior, actualiza a una versión compatible u obtén un paquete con una corrección retroportada de tu distribución o proveedor LTS. Las correcciones del código fuente de PHP para 7.4, 8.0 y 8.1 son un último recurso para los equipos que compilan desde el código fuente.
El ecosistema de código abierto
El equipo de seguridad de PHP avisó al ecosistema con un día de anticipación, una hora fija, la gravedad y sin detalles sobre la explotación. Compartió los parches por adelantado con las distribuciones de Linux para que los paquetes corregidos pudieran publicarse junto con la versión del código fuente. Publicó correcciones retroportadas para versiones sin soporte (7.4, 8.0, 8.1). Avisó a los usuarios de un popular repositorio mantenido por voluntarios (rpms.remirepo.net) que no se actualizaría el primer día y les indicó qué hacer en su lugar. Además, sus indicaciones de mitigación explican con mucha transparencia qué no protege cada ajuste.
Así se ve 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 publicado permite que todos los equipos de la cadena de suministro se preparen.
Cómo funciona Snyk SCA
Snyk Open Source lee lo que declara tu aplicación en los 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 como "php": ">=8.2" en composer.json indica qué acepta la aplicación, pero no exactamente qué versión está implementada.
Cómo te ayuda la plataforma Snyk a encontrar PHP expuesto
Qué usas | Qué verás para CVE-2026-109618 y CVE-2026-109619 |
|---|---|
Snyk Open Source (CLI o integración con SCM) | Los CVE no se reportan porque el runtime de PHP no es una dependencia estándar en el archivo de manifiesto. En los proyectos PHP/Composer, Snyk muestra las dependencias declaradas de la aplicación, lo que puede ayudarte a identificar cuáles de tus proyectos son aplicaciones PHP. La restricción de versión de PHP declarada no indica qué versión está implementada. |
Snyk C/C++ análisis de componentes no administrados | Se reportan avisos cuando el runtime de PHP está presente en tu proyecto, y puedes filtrarlos por ID de CVE. |
Snyk Container | El PHP instalado desde paquetes de distribuciones de Linux se reporta una vez que la distribución publica su aviso. Algunas distribuciones compatibles ya publicaron avisos, disponibles en los resultados de las pruebas (por ejemplo, SNYK-RHEL10-PHP84-21392647 y SNYK-UBUNTU2604-PHP85-21373920). Estamos importando los avisos de otras distribuciones a medida que los publican; están disponibles aquí: CVE-2026-109618 CVE-2026-109619. Snyk Container no detecta PHP compilado desde el código fuente, incluidas las imágenes oficiales php: de Docker. |
Snyk API & Web | Las pruebas DAST examinan las aplicaciones en ejecución desde el exterior e identifican su pila tecnológica. |
Informe Zero Day | El informe Zero Day de Snyk compara tus proyectos con los avisos, por lo que solo puede incluir proyectos analizados mediante «análisis de componentes no administrados» o análisis de Container de paquetes de distribuciones. En los proyectos analizados únicamente con Open Source, no mostrará resultados. |
Encuentra la superficie de ataque de PHP con Snyk API & Web
Antes de aplicar los parches, necesitas la lista. La pestaña Discovery de Snyk API & Web enumera los activos encontrados en tus dominios e identifica su pila tecnológica. Abre Discovery, configura el filtro Tech en PHP y verás todos los hosts y endpoints detectados donde se identificó PHP, junto con su calificación 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, así que puedes filtrar de la misma manera las aplicaciones que agregaste para mostrar solo las que usan PHP.
Esto no te indica la versión de PHP. Te muestra dónde buscar, un paso fundamental para corregir el problema.
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 unos 30 minutos después.
Los avisos de las distribuciones se importan a medida que cada distribución de Linux los publica. Los de Ubuntu y Red Hat ya están disponibles.
Ya está disponible un informe Zero Day para este evento para proyectos de componentes no administrados 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 cuentas de Snyk o con Support.
Referencias
Todos los avisos de Snyk para CVE-2026-109618 y CVE-2026-109619
Documentación sobre el análisis de componentes no administrados de Snyk C/C++
INFORME
Estado de la adopción de la IA agéntica en 2026: volumen III
La lista de modelos aprobados muestra qué está implementado, no a qué puede acceder cada modelo. ¿Te preguntas por dónde empezar a auditar tus agentes?
