Una vulnerabilidad crítica en PHP (CVE-2026-109618) permite que un atacante, sin autenticarse, ejecute código en el servidor enviando peticiones HTTP que agotan la memoria del proceso. Afecta a servidores con PHP anterior a 8.2.35, 8.3.36, 8.4.27 y 8.5.12, especialmente con Apache mod_php. Actualiza PHP de inmediato; es la única corrección completa.
Qué está pasando
PHP aborta las peticiones que se quedan sin memoria (OOM) usando un mecanismo llamado longjmp(). En ciertos momentos, la memoria de la petición queda accesible antes de estar completamente inicializada; si justo entonces falla cualquier asignación de memoria, PHP deja esa memoria en un estado inválido, y el procedimiento de cierre de la petición la procesa igual. Esto puede terminar en ejecución remota de código.
Un atacante puede provocar el agotamiento de memoria con peticiones multipart manipuladas sin salirse de los límites aparentes de PHP: cuerpos sin un largo declarado utilizable que pasan el control de post_max_size, partes con una cantidad ilimitada de encabezados que ocupan mucha más memoria internamente, o controles de archivo vacíos que no cuentan para max_file_uploads y se multiplican con nombres de campos anidados. También puede lograrse según la lógica de cada aplicación.
Con Apache mod_php el ataque ocurre antes de que se ejecute cualquier código de la aplicación, y el aviso confirma ejecución remota de código sin autenticación, con los permisos de la cuenta del servidor web, usando los límites por defecto de PHP. FrankenPHP probablemente es vulnerable de la misma forma. En FPM y LSAPI el análisis del código indica que también son susceptibles, aunque no se ha demostrado un exploit completo.
El parche elimina el uso de longjmp() para errores de memoria y lo reemplaza por un cierre controlado. El aviso pide además aplicar las recomendaciones de un reporte relacionado (GHSA-6wmf-4rv5-p3rp).
Vulnerabilidades
| CVE | CVSS | Descripción |
|---|---|---|
| CVE-2026-109618 | — | Uso de memoria liberada o no inicializada al abortar peticiones por falta de memoria (OOM) con longjmp(), que permite ejecución remota de código sin autenticación. |
Productos afectados
| Producto | Versiones afectadas | Versión corregida |
|---|---|---|
| PHP (php-src) 8.2 | < 8.2.35 | 8.2.35 |
| PHP (php-src) 8.3 | < 8.3.36 | 8.3.36 |
| PHP (php-src) 8.4 | < 8.4.27 | 8.4.27 |
| PHP (php-src) 8.5 | < 8.5.12 | 8.5.12 |
Qué hacer ahora
- Identifica todos los servidores con PHP y verifica la versión instalada (por ejemplo, con
php -v). - Actualiza PHP a 8.2.35, 8.3.36, 8.4.27 u 8.5.12 según tu rama; es la única mitigación completa. Prioriza los servidores con Apache mod_php o FrankenPHP expuestos a Internet.
- Reinicia todos los procesos y workers de PHP después de actualizar.
- Aplica también las recomendaciones del aviso relacionado GHSA-6wmf-4rv5-p3rp.
- Aun con el parche, mantén
post_max_sizeconservador, reducemax_input_nesting_levely limita la cantidad de variables de entrada, partes multipart, encabezados por parte y archivos subidos para reducir el riesgo de denegación de servicio.
Si no puedes actualizar de inmediato
Medidas temporales: reducen la exposición, pero no reemplazan la actualización.
- Si no puedes actualizar, configura y fuerza administrativamente
memory_limit=-1; no es una mitigación completa. Reinicia todos los workers y confirma que ninguna configuración de pool, directorio o aplicación vuelva a fijar un límite finito. - Limita en el frontend el tamaño decodificado de las peticiones y mantén
post_max_sizeconservador. - Si tu aplicación no usa formularios multipart, bloquea ese tipo de peticiones en el frontend antes de que lleguen a PHP.
- Un límite de memoria por contenedor o cgroup (
memory.max) puede servir como alternativa parcial, con limitaciones (puede matar al proceso maestro y a todos los workers si no están en grupos separados). - No uses
RLIMIT_ASniRLIMIT_DATA, porque provocan justamente la ruta vulnerable.
Te ayudamos a revisar sin costo si tus servidores o equipos usan una versión afectada por esta alerta, y qué conviene hacer primero.
Parte por los sitios PHP expuestos a Internet que corren sobre Apache con mod_php, típicos en hosting compartido, servidores antiguos y WordPress instalados hace años: ahí el ataque funciona sin depender de la aplicación. No olvides servidores de desarrollo, paneles internos publicados y contenedores con imágenes antiguas, que suelen quedar fuera de los ciclos de actualización. Si dependes de los paquetes de tu distribución Linux, confirma que el proveedor ya publicó la versión corregida o el backport correspondiente.
Si no puedes actualizar hoy, usa las mitigaciones solo como puente temporal y agenda la actualización en días, no semanas. Ten en cuenta que memory_limit=-1 puede hacer que un proceso consuma mucha memoria, así que vigila el uso de recursos del servidor mientras esté aplicado.
Cómo te ayuda UpTech
Mientras aplicas la actualización, podemos definir en Cerberus WAF reglas específicas para las rutas y parámetros vulnerables de tu sitio. Reduce la exposición, pero no reemplaza el parche.
Conocer el servicio → Servicios Gestionados TICon Gestión de Parches, las actualizaciones de seguridad de sistemas operativos y aplicaciones se aplican de forma programada, sin depender de que alguien lea esta alerta a tiempo.
Conocer el servicio → Servicios Gestionados TICon el inventario automatizado de hardware y software sabes de inmediato qué equipos tienen la versión afectada.
Conocer el servicio →Referencias
- https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
- https://www.cve.org/CVERecord?id=CVE-2026-109618