{"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\/pt\/blog\/news\/details-of-critical-php-vulnerabilities-disclosed-and-security-updates-released","title":{"rendered":"Detalhes sobre vulnerabilidades cr\u00edticas no PHP foram revelados e corre\u00e7\u00f5es foram publicadas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Foram lan\u00e7adas corre\u00e7\u00f5es para PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, al\u00e9m de patches para vers\u00f5es j\u00e1 n\u00e3o suportadas do PHP 7.4, PHP 8.0 e PHP 8.1 (vers\u00f5es vulner\u00e1veis de 5.4 a 7.3 permanecem sem patches), que corrigem duas vulnerabilidades cr\u00edticas:<\/p>\n
\n
CVE-2026-109618 \u2014 execu\u00e7\u00e3o remota de c\u00f3digo, causada pelo esgotamento da mem\u00f3ria livre dispon\u00edvel para o processo. O manipulador de falta de mem\u00f3ria, ao executar a fun\u00e7\u00e3o longjmp(), pode interromper o interpretador PHP em um estado onde apenas parte das estruturas internas relacionadas ao processamento da solicita\u00e7\u00e3o est\u00e3o inicializadas. Posteriormente, a fun\u00e7\u00e3o de finaliza\u00e7\u00e3o da solicita\u00e7\u00e3o acessa essas estruturas como se j\u00e1 estivessem inicializadas, embora a mem\u00f3ria para elas n\u00e3o tenha sido alocada.\n
O principal vetor de ataque \u00e9 a manipula\u00e7\u00e3o de solicita\u00e7\u00f5es multipart para criar condi\u00e7\u00f5es que esgotem a mem\u00f3ria dispon\u00edvel para o processo. Para contornar o limite post_max_size, pode-se n\u00e3o especificar o cabe\u00e7alho Content-Length e enviar um grande n\u00famero de cabe\u00e7alhos HTTP. \u00c9 poss\u00edvel realizar tamb\u00e9m ataques pontuais em opera\u00e7\u00f5es espec\u00edficas em aplicativos PHP que consomem excessivamente mem\u00f3ria. A presen\u00e7a de um exploit foi confirmada para mod_php, pois ele chama a fun\u00e7\u00e3o shutdown() mesmo em caso de falha. O PHP-FPM encerrar\u00e1 o processo filho em caso de falha, o que dificulta a realiza\u00e7\u00e3o do ataque, mas teoricamente n\u00e3o o exclui. <\/p>\n
CVE-2026-109619 \u2014 execu\u00e7\u00e3o remota de c\u00f3digo, causada pelo acesso \u00e0 mem\u00f3ria ap\u00f3s sua libera\u00e7\u00e3o devido \u00e0 limpeza inadequada do estado global associado a uma solicita\u00e7\u00e3o espec\u00edfica. Se a solicita\u00e7\u00e3o for interrompida devido a um erro fatal, timeout ou falta de mem\u00f3ria, o estado global pode n\u00e3o ser reiniciado e os ponteiros permanecer\u00e3o ativos, apesar da libera\u00e7\u00e3o da mem\u00f3ria a que se referem. Ao processar a pr\u00f3xima solicita\u00e7\u00e3o no mesmo processo, pode ocorrer um acesso ao antigo estado global atrav\u00e9s do ponteiro remanescente.\n
Para a explora\u00e7\u00e3o, podem ser criadas condi\u00e7\u00f5es para o esgotamento da mem\u00f3ria dispon\u00edvel ao processar uma solicita\u00e7\u00e3o multipart no c\u00f3digo para indicar o progresso do upload (session.upload_progress). Aqui, o principal e confirmado vetor de ataque mencionado \u00e9 o manipulador fatal_error_backtraces no PHP 8.5, que n\u00e3o reinicia o estado da rastreabilidade ao ser conclu\u00eddo. No primeiro caso, o ataque \u00e9 poss\u00edvel no mod_php e PHP-FPM, enquanto no segundo apenas no mod_php. Tamb\u00e9m \u00e9 mencionada uma possibilidade n\u00e3o confirmada de ataque em configura\u00e7\u00f5es que t\u00eam diretivas que resultam na exibi\u00e7\u00e3o de avisos em uma fase inicial do processamento da solicita\u00e7\u00e3o (por exemplo, avisos sobre o uso de par\u00e2metros obsoletos).<\/p>\n<\/ul>\n
Foi declarado que o bloqueio total das vulnerabilidades s\u00f3 \u00e9 poss\u00edvel atrav\u00e9s da instala\u00e7\u00e3o de atualiza\u00e7\u00f5es. As seguintes medidas ajudam a reduzir a probabilidade de ataques bem-sucedidos, mas n\u00e3o tornam o sistema totalmente seguro:<\/p>\n
\n
Definir o par\u00e2metro php.ini \"memory_limit=-1\", o que dificulta que um atacante controle o esgotamento dos limites de mem\u00f3ria.\n
Definir o par\u00e2metro \"post_max_size = 8M\", se n\u00e3o houver necessidade de carregar arquivos grandes. O valor do par\u00e2metro \"upload_max_filesize\" deve ser menor que o par\u00e2metro \"post_max_size\".\n
Definindo um limite para o consumo de mem\u00f3ria a n\u00edvel de sistema, atrav\u00e9s de cgroup memory.max ou par\u00e2metros de consumo de mem\u00f3ria do cont\u00eainer, mas n\u00e3o atrav\u00e9s dos limites de sistema RLIMIT_AS e RLIMIT_DATA, que apenas provocam a chamada problem\u00e1tica longjmp().\n
Se o desempenho n\u00e3o for importante, pode-se limitar o n\u00famero de solicita\u00e7\u00f5es processadas por um \u00fanico processo de trabalho atrav\u00e9s de pm.max_requests=1 no PHP-FPM e MaxRequestsPerChild no Apache httpd.\n