{"id":183943,"date":"2026-10-22T05:40:56","date_gmt":"2026-10-22T03:40:56","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/raskryty-detali-kriticheskih-uyazvimostej-v-php-i-opublikovany-korrektiruyushhie-obnovleniya"},"modified":"2026-10-22T05:41:02","modified_gmt":"2026-10-22T03:41:02","slug":"details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Se han revelado detalles de vulnerabilidades cr\u00edticas en PHP y se han publicado actualizaciones correctivas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Se han publicado lanzamientos correctivos de PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35, as\u00ed 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\u00e1n sin parches), en los cuales se han corregido dos vulnerabilidades cr\u00edticas:<\/p>\n
\n
CVE-2026-109618 \u2014 ejecuci\u00f3n remota de c\u00f3digo, provocada porque, al agotarse la memoria libre disponible para el proceso, el controlador de falta de memoria, a trav\u00e9s de la ejecuci\u00f3n de la funci\u00f3n longjmp(), puede interrumpir el int\u00e9rprete de PHP en un estado en el que solo se ha inicializado parcialmente algunas estructuras internas relacionadas con el procesamiento de la solicitud. Posteriormente, la funci\u00f3n de finalizaci\u00f3n del procesamiento de la solicitud accede a estas estructuras como si ya estuvieran inicializadas, aunque no se haya asignado memoria para ellas.\n
El principal vector de ataque es la manipulaci\u00f3n de solicitudes multipart para crear condiciones que agoten la memoria disponible para el proceso. Para eludir el l\u00edmite post_max_size, se puede no especificar el encabezado Content-Length y enviar un n\u00famero enorme de encabezados HTTP. Tambi\u00e9n es posible realizar ataques puntuales en operaciones espec\u00edficas en aplicaciones PHP que consumen excesivamente memoria. La existencia de un exploit ha sido confirmada para mod_php, ya que llama a la funci\u00f3n shutdown() incluso en caso de fallo. PHP-FPM, en caso de fallo, finalizar\u00e1 el proceso hijo, lo que dificulta la realizaci\u00f3n del ataque, pero te\u00f3ricamente no lo excluye. <\/p>\n
CVE-2026-109619 \u2014 ejecuci\u00f3n remota de c\u00f3digo, causada por el acceso a la memoria despu\u00e9s de ser liberada debido a la limpieza inadecuada del estado global vinculado a una solicitud particular. Si se interrumpe la solicitud debido a un error fatal, un tiempo de espera o falta de memoria, el estado global puede no resetearse y los punteros permanecen activos, a pesar de la liberaci\u00f3n de la memoria a la que apuntan. Al procesar la siguiente solicitud en el mismo proceso, puede ocurrir un acceso a trav\u00e9s del puntero restante al antiguo estado global.\n
Para su explotaci\u00f3n, se puede utilizar la creaci\u00f3n de condiciones que agoten la memoria disponible al procesar una solicitud multipart en el c\u00f3digo 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\u00e9n 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\u00e1metros obsoletos).<\/p>\n<\/ul>\n
Se afirma que el bloqueo total de vulnerabilidades solo es posible mediante la instalaci\u00f3n de actualizaciones. Las siguientes medidas pueden reducir la probabilidad de ataques exitosos, pero no hacen que el sistema sea completamente seguro:<\/p>\n
\n
Establecer en php.ini el par\u00e1metro \"memory_limit=-1\", lo que dificulta que un atacante controle el agotamiento de los l\u00edmites de memoria.\n
Establecer el par\u00e1metro \"post_max_size = 8M\" si no es necesario subir archivos grandes. El valor del par\u00e1metro \"upload_max_filesize\" debe ser menor que el par\u00e1metro \"post_max_size\".\n
Definir un l\u00edmite de consumo de memoria a nivel del sistema, a trav\u00e9s de cgroup memory.max o par\u00e1metros de consumo de memoria del contenedor, pero no a trav\u00e9s de los l\u00edmites del sistema RLIMIT_AS y RLIMIT_DATA, que solo provocan un llamado problem\u00e1tico a longjmp().\n
Si el rendimiento no es importante, se puede limitar el n\u00famero de solicitudes procesadas por un solo proceso de trabajo mediante pm.max_requests=1 en PHP-FPM y MaxRequestsPerChild en Apache httpd.\n