🥇Se han revelado detalles de vulnerabilidades críticas en PHP y se han publicado actualizaciones correctivas

Se han publicado lanzamientos correctivos de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, así como parches para las ramas ya no soportadas PHP 7.4, PHP 8.0 y PHP 8.1 (las versiones vulnerables del 5.4 al 7.3 permanecerán sin parches), en los cuales se han corregido dos vulnerabilidades críticas:

CVE-2026-109618 — ejecución remota de código, provocada por el hecho de que, al agotar la memoria libre disponible para el proceso, el manejador de falta de memoria a través de la función longjmp() puede interrumpir el intérprete de PHP en un estado en el que solo una parte de las estructuras internas relacionadas con el procesamiento de la solicitud está inicializada. Posteriormente, la función que finaliza el procesamiento de la solicitud accede a estas estructuras como si ya estuvieran inicializadas, aunque no se haya 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 no especificar el encabezado Content-Length y enviar un número enorme de encabezados HTTP. También es posible realizar 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, en caso de fallo, finalizará el proceso hijo, lo que dificulta la realización del ataque, pero teóricamente no lo excluye.
CVE-2026-109619 — ejecución remota de código, causada 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. Si se interrumpe la solicitud debido a un error fatal, un tiempo de espera o falta de memoria, el estado global puede no restablecerse y los punteros pueden permanecer activos, a pesar de que la memoria a la que hacen referencia haya sido liberada. 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 explotación, se puede utilizar la creación de condiciones que agoten la memoria disponible al procesar una solicitud multipart en el código para indicar el progreso de carga (session.upload_progress). En este caso, como vector de ataque principal y confirmado, se menciona el manejador fatal_error_backtraces en PHP 8.5, que no restablece el estado de la traza al finalizar. En el primer caso, el ataque es posible en mod_php y PHP-FPM, mientras que en el segundo, solo en mod_php. También se menciona la posibilidad no confirmada de realizar un ataque en configuraciones que contienen directivas que generan advertencias en una etapa temprana de procesamiento de la solicitud (por ejemplo, advertencias sobre el uso de parámetros obsoletos).

Se afirma que el bloqueo total de 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 es necesario cargar archivos grandes. El valor del parámetro "upload_max_filesize" debe ser menor que el parámetro "post_max_size".
Definir un límite de 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 los límites del sistema RLIMIT_AS y RLIMIT_DATA, que solo provocan un llamado problemático a 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.
Estableciendo 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 del inicio del procesamiento de la solicitud) el parámetro "session.upload_progress.enabled=0."
Al utilizar la versión PHP 8.5, se debe establecer el parámetro "fatal_error_backtraces=0".
Eliminar configuraciones obsoletas o erróneas asociadas a solicitudes individuales (como assert.* y rutas incorrectas en open_basedir), que llevan a la emisión de mensajes de diagnóstico antes de la inicialización.
Eliminar en el código PHP situaciones que provocan tiempos de espera y errores fatales, por ejemplo, relacionadas con fallos en callbacks manejadores y 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 anuncio preliminar.

El estado de la eliminación de vulnerabilidades 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 GPT‑5.6 y Gemini 4 Argon. La empresa OpenAI publicó la utilidad php2shell-checker para verificar la exposición a vulnerabilidades de sitios y archivos ejecutables locales, pero esta utilidad solo verifica el número de versión de PHP que devuelve el servidor HTTP o el comando «php -v», sin 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) informó que el problema sigue sin solucionarse en la versión PHP 8.5.12 y el exploit sigue funcionando. Anteriormente, representantes de PHP afirmaron que esta vulnerabilidad no estaba relacionada con los próximos parches y no era un problema real. Sin embargo, el autor del exploit afirmó que se trataba de una vulnerabilidad completamente diferente.

Fuente: opennet.ru