PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35 cierran dos RCE críticos

⏱️ Lectura: 11 min

El equipo de seguridad de PHP acaba de publicar cuatro versiones de emergencia (8.5.12, 8.4.27, 8.3.36 y 8.2.35) para cerrar dos vulnerabilidades críticas que permiten ejecución remota de código sin autenticación. El aviso oficial no deja margen de duda: actualizar es la única solución segura, y cualquier servidor que corra PHP-FPM, mod_php, php-cgi, FrankenPHP o LiteSpeed queda expuesto mientras no lo haga.

📑 En este artículo

1. TL;DR
2. Qué es PHP
3. Qué pasó
4. Contexto e historia
5. Detalles técnicos
6. Impacto de las vulnerabilidades críticas de PHP en producción
7. Qué sigue
8. Preguntas frecuentes
   1. ¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?
   2. ¿Qué hace explotable a mod_php frente a las fallas críticas de PHP-FPM?
   3. ¿Alcanza con ajustar php.ini si no puedo actualizar PHP de inmediato?
   4. ¿PHP 8.1 y versiones anteriores reciben este parche?
   5. ¿Cómo sé si mi servidor sigue expuesto a los RCE no autenticados de PHP?
9. Referencias
   1. 📚 Artículos relacionados

El riesgo más alto golpea a mod_php. Según el propio equipo de PHP ya existe un exploit que dispara el ataque antes de que corra una sola línea de código de la aplicación. Ni el framework más blindado salva al sitio si el intérprete que corre debajo está vulnerable.

TL;DR

• PHP lanza las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 para corregir dos RCE críticos sin autenticación.
• CVE-2026-109618 corrompe memoria por un fallo de OOM; CVE-2026-109619 reutiliza estado global obsoleto.
• El riesgo más alto recae en mod_php, con un exploit demostrado antes de que corra código de la aplicación.
• Parches mínimos de backport llegaron a PHP 7.4, 8.0 y 8.1, aunque esas versiones ya no reciben soporte oficial.
• No existe mitigación completa: actualizar es la única solución segura según el aviso oficial.

Qué es PHP

PHP es el lenguaje de programación de propósito general para desarrollo web del lado del servidor, creado en 1994 y mantenido por el PHP Group; corre detrás de blogs, tiendas y buena parte de los sitios más visitados del mundo, lo que agrava las vulnerabilidades críticas de PHP reveladas esta semana.

El proyecto sostiene en paralelo varias ramas activas: 8.5, 8.4, 8.3 y 8.2, cada una con su propio calendario de soporte y de seguridad. Esa política explica por qué el parche salió el mismo día en cuatro números de versión distintos en lugar de uno solo.

Qué pasó

El equipo de seguridad de PHP confirmó que ambas fallas permiten a un atacante remoto, sin credenciales, ejecutar código arbitrario en el servidor. La primera, identificada como CVE-2026-109618, corrompe memoria cuando el manejo de condiciones de falta de memoria (OOM) interrumpe una petición a medio inicializar; la limpieza posterior trata esos datos inválidos como si fueran válidos. La segunda, CVE-2026-109619, deja que el estado interno de una petición anterior sobreviva después de que su memoria ya se liberó, y un worker que atiende la siguiente petición puede usar ese estado viejo antes de que la inicialización normal lo resetee.

El propio aviso marca a mod_php como el escenario de mayor riesgo, porque ahí existe un exploit demostrado capaz de disparar el ataque antes de que corra cualquier código de la aplicación. También quedan expuestos PHP-FPM, php-cgi, FrankenPHP y LiteSpeed: en síntesis, cualquier forma estándar de servir PHP en producción.

Contexto e historia

Los RCE no autenticados de PHP son raros: la mayoría de los reportes de seguridad del proyecto corrige fugas de memoria, denegaciones de servicio o fallos que requieren cierta configuración previa del atacante. Que dos bugs de este calibre aparezcan juntos, y que uno de ellos ya tenga una ruta de explotación probada contra mod_php, es lo que empujó a liberar cuatro versiones el mismo día en lugar de esperar al ciclo mensual habitual de parches.

El PHP Group mantiene simultáneamente las ramas 8.5, 8.4, 8.3 y 8.2 bajo soporte activo, además de una ventana de soporte de seguridad para versiones ya retiradas. PHP 8.1 y anteriores dejaron de recibir actualizaciones oficiales del proyecto, aunque algunas distribuciones Linux y proveedores LTS siguen aplicando parches propios con retraso. Dada la gravedad de este caso, el equipo de seguridad decidió además publicar backports mínimos para PHP 7.4, 8.0 y 8.1, pensados para quien compila desde el código fuente y no depende de un vendor con soporte extendido.

Detalles técnicos

El mecanismo detrás de CVE-2026-109618 vive en el manejo de memoria agotada. Cuando PHP se queda sin memoria a mitad de procesar una petición, el motor interrumpe la ejecución y dispara la limpieza de los datos de esa petición. El problema es que la interrupción puede caer justo cuando esos datos todavía están a medio construir: la rutina de limpieza no distingue entre una estructura completa y una a medio inicializar, y termina liberando o reutilizando punteros que nunca se llegaron a asignar correctamente. Un atacante que logra forzar ese agotamiento de memoria en el momento preciso convierte una condición de error en una corrupción de memoria explotable.

CVE-2026-109619 es distinto. No depende de que falle la memoria, sino de que el estado interno de una petición sobreviva más de lo que debería. PHP-FPM reutiliza procesos worker entre peticiones para ahorrar el costo de arrancar un intérprete nuevo cada vez. Si una petición termina de forma anómala (por ejemplo, un error fatal durante el procesamiento de una subida de archivo) sin que el worker limpie por completo cierto estado global, la siguiente petición que atienda ese mismo worker puede heredar datos que no le pertenecen. El aviso señala rutas confirmadas a través de session.upload_progress y, en PHP 8.5, a través de los backtraces de errores fatales (fatal_error_backtraces).

; Mitigacion parcial mientras se actualiza (NO reemplaza el parche)
memory_limit = -1
post_max_size = 8M
session.upload_progress.enabled = 0
fatal_error_backtraces = 0 ; solo aplica en PHP 8.5

Estos cuatro ajustes, aplicados vía php_admin_value en el pool de FPM o en la configuración de Apache (nunca con ini_set() ni con .user.ini, porque corren después de que arranca el procesamiento de la petición), cierran las rutas de explotación ya confirmadas por el equipo de PHP. No cierran variantes todavía no descubiertas, así que el propio aviso insiste en que solo la actualización es una solución completa.

Para confirmar qué versión corre tu servidor, ejecutá php -v desde la terminal o revisá el valor de PHP_VERSION con phpinfo(); el número debe ser 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o superior. En PHP-FPM, el campo de versión también aparece en el endpoint /status si tenés habilitado el estado del pool, o podés preguntarle directamente a tu proveedor de hosting si administra el servidor por vos.

flowchart TD
A["Peticion HTTP entra"] --> B["Worker PHP-FPM la procesa"]
B --> C{"Memoria agotada o error fatal?"}
C -- "Si, CVE-2026-109618" --> D["Limpieza trata datos a medio inicializar como validos"]
C -- "No" --> E["Peticion termina normal"]
E --> F["Worker queda disponible"]
F --> G["Siguiente peticion reutiliza el mismo worker"]
G --> H{"Quedo estado global sin limpiar?"}
H -- "Si, CVE-2026-109619" --> I["Nueva peticion hereda estado obsoleto"]
H -- "No" --> E

Impacto de las vulnerabilidades críticas de PHP en producción

El golpe real depende de cuánta superficie de ataque expone cada instalación. Un servidor con mod_php activo y rutas de subida de archivos abiertas al público enfrenta el escenario más urgente, porque ahí ya hay un exploit probado. Los despliegues con PHP-FPM detrás de Nginx reducen algo el riesgo porque el worker corre aislado del servidor web, pero siguen expuestos a CVE-2026-109619 mientras compartan procesos entre peticiones, que es justamente el diseño por defecto de FPM.

Para equipos de plataforma, el mensaje operativo es simple: no hay forma de parchar en caliente sin reiniciar. Cambiar session.upload_progress.enabled o fatal_error_backtraces solo surte efecto si se aplica en php.ini, en el pool de FPM o en la configuración del servidor antes de que arranque el procesamiento de la petición, y exige reiniciar cada worker para que tome el valor nuevo. Un reload que no reinicia procesos deja la ventana abierta.

⚠️ Ojo: ninguna de las mitigaciones parciales es una solución completa; el propio equipo de PHP lo dice sin matices, actualizar es la única opción segura.

Qué sigue

Las distribuciones Linux y los proveedores LTS ya recibieron los parches antes del anuncio público, así que la mayoría de los paquetes de sistema (Debian, Ubuntu, RHEL, Alpine) deberían tener versiones corregidas disponibles en sus repositorios al mismo tiempo que esta publicación. Quien compila PHP desde el código fuente, o corre contenedores con una imagen base vieja, necesita reconstruir manualmente contra 8.5.12, 8.4.27, 8.3.36 u 8.2.35, o aplicar alguno de los backports mínimos liberados para 7.4, 8.0 y 8.1 mientras planea una migración a una rama con soporte completo.

La existencia de un exploit interno demostrado contra mod_php acorta el tiempo habitual entre el anuncio y la aparición de pruebas de concepto públicas. Por eso el aviso oficial recomienda actualizar antes de leer los detalles técnicos completos de las advisories, no después.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré php -v en tu servidor hoy mismo y comparalo contra 8.5.12, 8.4.27, 8.3.36 u 8.2.35 para saber si ya estás parchado.

Preguntas frecuentes

¿Qué versiones de PHP corrigen CVE-2026-109618 y CVE-2026-109619?

Las versiones parcheadas son PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. El equipo de seguridad también liberó backports mínimos para 7.4, 8.0 y 8.1, pensados solo para quien compila desde el código fuente.

¿Qué hace explotable a mod_php frente a las fallas críticas de PHP-FPM?

En mod_php el ataque se dispara antes de que corra cualquier código de la aplicación, porque la corrupción ocurre en el propio manejo de memoria del intérprete durante la limpieza de la petición. Eso lo vuelve el escenario de mayor riesgo entre las plataformas afectadas.

¿Alcanza con ajustar php.ini si no puedo actualizar PHP de inmediato?

No por completo. Ajustes como memory_limit=-1, un post_max_size bajo o session.upload_progress.enabled=0 cierran las rutas de explotación ya confirmadas, pero el propio aviso de PHP aclara que solo la actualización es una solución completa.

¿PHP 8.1 y versiones anteriores reciben este parche?

El proyecto PHP ya no da soporte oficial a 8.1 ni a versiones previas, pero dada la gravedad del caso publicó backports mínimos para 7.4, 8.0 y 8.1. Algunas distribuciones Linux y proveedores LTS también ofrecen parches propios.

¿Cómo sé si mi servidor sigue expuesto a los RCE no autenticados de PHP?

Ejecutá php -v o revisá phpinfo() para ver el número de versión instalado; si no es 8.5.12, 8.4.27, 8.3.36, 8.2.35 o superior, tu servidor sigue expuesto hasta que actualices o apliques las mitigaciones parciales descritas en el aviso oficial.

Referencias

• PHP.net: anuncio oficial de las versiones 8.5.12, 8.4.27, 8.3.36 y 8.2.35 y de las dos vulnerabilidades críticas corregidas.
• NVD, CVE-2026-109618: ficha oficial de la vulnerabilidad de corrupción de memoria por manejo de OOM.
• NVD, CVE-2026-109619: ficha oficial de la vulnerabilidad de estado global obsoleto.
• GitHub Security Advisories, GHSA-w8hw-w9fx-j79w: detalle técnico de la ruta de explotación vía manejo de OOM.
• GitHub Security Advisories, GHSA-6wmf-4rv5-p3rp: detalle técnico de la ruta de explotación vía estado global obsoleto.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.

Imagen destacada: Foto de Pankaj Patel en Unsplash