Seguridad de aplicaciones
Fallos críticos de PHP: de la corrupción de memoria a una corrección verificada
Una petición HTTP no debería comprometer el proceso que atiende una aplicación de negocio. Las CVE-2026-109618 y CVE-2026-109619 pueden cruzar esa frontera bajo determinadas condiciones de gestión de memoria y del ciclo de vida de las peticiones. Distinguir sus mecanismos permite priorizar la corrección y comprobar que llegó a la aplicación en ejecución.
Qué cambian estas vulnerabilidades
Los fallos afectan al núcleo de PHP, por debajo de frameworks como Laravel, Symfony y WordPress. Una aplicación puede tener sus dependencias actualizadas y seguir usando un intérprete vulnerable. El impacto potencial es ejecución remota de código con los privilegios del proceso PHP; el acceso a archivos, secretos y servicios depende de los permisos y del aislamiento del entorno.
Las correcciones se publicaron el 21/10/2026. PHP asigna CVSS 4.0 de 9.2 a ambas CVE; NVD registra CVSS 3.1 de 9.8 para CVE-2026-109618. Son evaluaciones con versiones y vectores distintos. Las pruebas de concepto públicas aumentan la urgencia, pero no demuestran compromiso ni explotación universal.
Versiones oficiales corregidas
| Rama | Versiones afectadas de la rama | Primera versión corregida |
|---|---|---|
| PHP 8.2 | 8.2.0–8.2.34 | 8.2.35 |
| PHP 8.3 | 8.3.0–8.3.35 | 8.3.36 |
| PHP 8.4 | 8.4.0–8.4.26 | 8.4.27 |
| PHP 8.5 | 8.5.0–8.5.11 | 8.5.12 |
La tabla cubre las ramas oficiales con soporte. Los backports pueden usar otra versión de paquete: confirme el aviso y la revisión del proveedor. PHP 8.1 y anteriores están fuera del soporte oficial regular; los paquetes LTS y los backports de emergencia requieren una evaluación específica.
CVE-2026-109618 · inicialización interrumpida y memoria inválida
El tratamiento de falta de memoria (out-of-memory, OOM) puede interrumpir una operación cuando las estructuras internas de la petición solo están parcialmente inicializadas. La limpieza posterior puede considerar válido ese estado incompleto. El problema es la limpieza insegura tras la interrupción, no simplemente “consumir mucha RAM”.
En mod_php se ha demostrado ejecución remota antes del código de la aplicación. PHP-FPM puede terminar un proceso hijo si falla el inicio, pero también deben evaluarse las vías durante la ejecución de la aplicación. Por ello, una página de acceso y las comprobaciones realizadas solo por el framework no son una barrera suficiente.
- 01Entrada HTTP
El proceso empieza a tratar la petición.
- 02Asignación en curso
Las estructuras internas siguen incompletas.
- 03Interrupción por OOM
El flujo sale antes de completar la inicialización.
- 04Limpieza insegura
El estado inválido puede corromper la memoria.
Esquema conceptual: los pasos explican la causa del fallo, no un exploit universal.
CVE-2026-109619 · memoria liberada, referencia persistente
El segundo fallo cruza la frontera entre peticiones. Un worker persistente conserva una referencia global a memoria que pertenecía a una petición anterior. Si el estado no se limpia antes de liberar esa memoria, una operación posterior puede acceder a ella como si aún fuera válida: un use-after-free.
La cadena necesita un productor de estado obsoleto y un consumidor que lo alcance antes de la inicialización normal, en otra petición atendida por el mismo worker. Los errores fatales pueden interrumpir la limpieza; las operaciones de sesión y carga o los diagnósticos iniciales pueden formar parte del recorrido. Una nueva petición HTTP no implica un proceso nuevo ni memoria global nueva.
- 01Petición A
Una operación publica estado interno.
- 02Memoria liberada
Una interrupción deja una referencia global sin limpiar.
- 03Mismo worker
El proceso persiste y recibe otra petición.
- 04Petición B
Un consumidor inicial usa la referencia obsoleta.
Esquema conceptual: los pasos explican la causa del fallo, no un exploit universal.
Los mismos fallos, distintas vías de exposición
| Entorno | Qué cambia en la evaluación |
|---|---|
| Apache + mod_php | Máxima prioridad: el inicio de la petición puede alcanzar el fallo antes del código de la aplicación. Se ha demostrado ejecución remota. |
| PHP-FPM | No es inmune. Existen vías confirmadas ligadas a la aplicación; importan la reutilización del worker y el momento de la inicialización. |
| Contenedores y otros SAPIs | Un contenedor no corrige el intérprete. Compruebe la imagen, la versión incluida, las extensiones y el modo de ejecución; el nombre del servidor no demuestra inmunidad. |
Cómo priorizar la exposición real
Empiece por los servicios expuestos a internet y por mod_php. Incluya APIs, herramientas de administración, cargas, importadores y productos de terceros que incorporan PHP. En FPM, evalúe pools y flujos de aplicación; cambiar únicamente el frontend HTTP no elimina un fallo del intérprete.
Un backport puede conservar un número de versión antiguo. Base la decisión en el aviso del proveedor y la revisión instalada, no solo en banners HTTP o comparaciones de cadenas. La etiqueta “PHP 8.2+” es insuficiente: cada rama tiene una primera versión corregida distinta.
Defensa por capas, con el parche en el centro
El control decisivo es aplicar la corrección completa del runtime. Mientras prepara el cambio, restrinja las vías expuestas y revise los límites del proxy y del servidor. Un WAF puede reducir tráfico reconocido; no prueba que bloquee todas las vías de corrupción de memoria.
Deshabilitar session.upload_progress.enabled cuando no sea necesario, o fatal_error_backtraces en los casos aplicables de PHP 8.5, reduce vías específicas y exige configuración administrativa y reinicio de workers. No sustituye el parche. Evite cambios genéricos en memory_limit sin evaluar disponibilidad y límites de recursos.
- 01Contener la exposición
Acceso restringido, límites y observación perimetral.
- 02Corregir el runtime
Paquetes corregidos y renovación de todos los workers.
- 03Validar la operación
Versión activa, pruebas y evidencias del despliegue.
Esquema conceptual: los pasos explican la causa del fallo, no un exploit universal.
Proceso de corrección verificable
- Inventaríe PHP en el servidor web, pools FPM, workers de cola, tareas programadas e imágenes. php -v en la terminal comprueba únicamente ese binario CLI.
- Confirme la corrección en el aviso del proveedor y registre el paquete, la revisión, el repositorio y el digest de la imagen cuando corresponda.
- Pruebe autenticación, cargas, sesiones, importaciones, integraciones, extensiones y tareas de fondo en preproducción. Prepare una copia restaurable y un plan de reversión.
- Actualice el paquete o reconstruya la imagen y sustituya todos los procesos afectados. Cambiar archivos en disco no garantiza que los workers antiguos hayan terminado.
- Valide el runtime que recibe tráfico real, los flujos de negocio y los registros tras el cambio. Use diagnósticos restringidos; no publique phpinfo() para demostrar la versión.
- Conserve evidencias del despliegue y la validación. Volver a una versión vulnerable requiere contención y un nuevo plan de corrección.
Qué observar después de actualizar
Correlacione errores fatales, eventos OOM, caídas de workers, avisos de inicio y cargas anómalas con los registros del proxy y la aplicación. Son señales para investigar, pero no demuestran por sí solas explotación. La ausencia de mensajes tampoco demuestra seguridad: un fallo puede preceder a su registro.
Si sospecha un compromiso, aplicar el parche no completa la respuesta al incidente. Preserve evidencias, contenga el activo y evalúe credenciales, cambios de archivos y accesos dependientes. Investigue también lo ocurrido antes de la corrección.