Se han publicado versiones correctivas de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, así como parches para ramas que ya no son compatibles, PHP 7.4, PHP 8.0 y PHP 8.1 (las versiones vulnerables de 5.4 a 7.3 no reciben parches), en las que se han corregido dos vulnerabilidades críticas:
- CVE-2026-109618 — ejecución remota de código, provocada porque, al agotarse la memoria libre disponible para el proceso, el controlador de falta de memoria a través de la ejecución de la función longjmp() puede interrumpir el intérprete de PHP en un estado en el que solo se ha inicializado parte de las estructuras internas relacionadas con el procesamiento de la solicitud. Posteriormente, la función de finalización del procesamiento de la solicitud accede a estas estructuras como si ya estuvieran inicializadas, a pesar de que no se ha asignado memoria para ellas.
El principal vector de ataque es la manipulación de solicitudes multipart para crear condiciones que agoten la memoria disponible para el proceso. Para eludir el límite post_max_size, se puede omitir el encabezado Content-Length y enviar una gran cantidad de encabezados HTTP. También pueden realizarse ataques puntuales en operaciones específicas en aplicaciones PHP que consumen excesivamente memoria. La existencia de un exploit ha sido confirmada para mod_php, ya que llama a la función shutdown() incluso en caso de fallo. PHP-FPM finalizará el proceso hijo en caso de fallo, lo que dificulta el ataque, pero teóricamente no lo excluye.
- CVE-2026-109619 — ejecución remota de código, provocada por el acceso a la memoria después de su liberación debido a una limpieza incorrecta del estado global asociado a una solicitud específica. En caso de interrupción de la solicitud debido a un error fatal, tiempo de espera o falta de memoria, el estado global puede no restablecerse y los punteros pueden permanecer activos a pesar de la liberación de la memoria a la que apuntan. Al procesar la siguiente solicitud en el mismo proceso, puede ocurrir un acceso a través del puntero restante al antiguo estado global.
Para su funcionamiento, se puede crear condiciones que agoten la memoria disponible al procesar solicitudes multipart en el código para indicar el progreso de la carga (session.upload_progress). Se menciona que el principal y confirmado vector de ataque es el controlador fatal_error_backtraces en PHP 8.5, que no restablece el estado de la traza al completarse. En el primer caso, el ataque es posible en mod_php y PHP-FPM, y en el segundo solo en mod_php. También se menciona una posibilidad no confirmada de llevar a cabo un ataque en configuraciones que tienen directivas que generan advertencias en una etapa temprana del procesamiento de la solicitud (por ejemplo, advertencias sobre el uso de parámetros obsoletos).
Se afirma que el bloqueo total de las vulnerabilidades solo es posible mediante la instalación de actualizaciones. Las siguientes medidas pueden reducir la probabilidad de ataques exitosos, pero no hacen que el sistema sea completamente seguro:
- Establecer en php.ini el parámetro «memory_limit=-1», lo que dificulta que un atacante controle el agotamiento de los límites de memoria.
- Establecer el parámetro «post_max_size = 8M», si no hay necesidad de cargar archivos grandes. El valor del parámetro «upload_max_filesize» debe ser menor que el parámetro «post_max_size».
- Establecer un límite para el consumo de memoria a nivel del sistema, a través de cgroup memory.max o parámetros de consumo de memoria del contenedor, pero no a través de límites del sistema RLIMIT_AS y RLIMIT_DATA, los cuales solo provocan el problemático llamado longjmp().
- Si el rendimiento no es importante, se puede limitar el número de solicitudes procesadas por un solo proceso de trabajo mediante pm.max_requests=1 en PHP-FPM y MaxRequestsPerChild en Apache httpd.
- Establecimiento a nivel de php.ini o configuración servidores (no a través de ini_set() o FPM .user.ini, ya que el parámetro debe aplicarse antes de iniciar el procesamiento de la solicitud) del parámetro «session.upload_progress.enabled=0».
- Al usar la versión PHP 8.5, se debe establecer el parámetro «fatal_error_backtraces=0».
- Eliminar configuraciones obsoletas o erróneas vinculadas a solicitudes individuales (como assert.* y rutas incorrectas en open_basedir), que provocan la generación de mensajes de diagnóstico antes de la inicialización.
- Eliminar en el código PHP situaciones que conducen a tiempos de espera y errores fatales, por ejemplo, aquellas relacionadas con fallos en los manejadores de callback y en el procesamiento de cargas.
- Para bloquear la primera vulnerabilidad en el código de versiones antiguas de PHP, se puede reemplazar la llamada a longjmp() en el manejador de agotamiento de memoria libre por _exit().
- Además, se puede reducir el valor del parámetro max_input_nesting_level en php.ini y bloquear las solicitudes multipart, como se mostró en el aviso preliminar.
El estado de las vulnerabilidades solucionadas en las distribuciones se puede evaluar en las siguientes páginas: Debian, Ubuntu, SUSE, RHEL, Gentoo, Arch,
Fedora, FreeBSD.
Adición 1: Las vulnerabilidades fueron identificadas mediante modelos de IA como GPT-5.6 y Gemini 4 Argon. OpenAI ha publicado la herramienta php2shell-checker para verificar la exposición a vulnerabilidades de sitios web y archivos ejecutables locales, pero esta herramienta solo comprueba el número de versión de PHP que devuelve el servidor HTTP o el comando "php -v", sin un análisis detallado.
Adición 2: El autor del prototipo de exploit que utiliza la vulnerabilidad causada por la doble liberación de memoria (double-free) ha informado que el problema sigue sin resolverse en la versión PHP 8.5.12 y el exploit continúa funcionando. Anteriormente, representantes de PHP afirmaron que esta vulnerabilidad no estaba relacionada con las correcciones en curso y no era un problema real. Sin embargo, el autor del exploit afirmó que se trataba de una vulnerabilidad completamente diferente.
Fuente: opennet.ru
