O PHP para Windows recebeu novas compilações para corrigir uma vulnerabilidade crítica na biblioteca Brotli, utilizada na cadeia de dependências do cURL. A falha, identificada como CVE-2026-111497, acende um alerta para desenvolvedores, administradores de sistemas e equipes de segurança que dependem de aplicações PHP para realizar requisições HTTP e processar respostas de serviços externos.
A liberação de novos pacotes em um intervalo inferior a uma semana aumenta a pressão sobre os responsáveis pela manutenção de servidores Windows. O movimento ocorre após uma rodada recente de correções relacionadas às vulnerabilidades PHP2Shell, exigindo que administradores revisem novamente seus ambientes para confirmar se os binários instalados estão realmente protegidos.
O risco merece atenção especial porque a vulnerabilidade pode atingir aplicações sem que seus desenvolvedores tenham implementado diretamente qualquer funcionalidade relacionada à descompressão Brotli. Bibliotecas populares, como o Guzzle, podem ativar automaticamente o processamento de respostas HTTP compactadas, criando uma via indireta para que dados maliciosos alcancem componentes vulneráveis.
Neste artigo, você entenderá como funciona esse cenário, por que o PHP para Windows precisa de pacotes específicos para corrigir o problema, como identificar uma instalação protegida e quais medidas temporárias podem reduzir a exposição quando a atualização imediata não for possível.
O que é a falha no Brotli e como ela atinge o PHP para Windows
O Brotli é um algoritmo de compressão desenvolvido pelo Google e amplamente utilizado na web para reduzir o tamanho das respostas HTTP. Ele permite transferir páginas, arquivos e outros conteúdos com menor consumo de banda, contribuindo para melhorar o desempenho das aplicações.
O problema associado à CVE-2026-111497 é descrito no cenário apresentado como uma vulnerabilidade de corrupção de memória. Esse tipo de falha ocorre quando uma implementação manipula dados de maneira inadequada, podendo provocar acessos inválidos à memória e comprometer a estabilidade ou a segurança do processo.
Dependendo da causa específica, das condições de exploração e das proteções disponíveis, uma vulnerabilidade de corrupção de memória pode permitir desde uma interrupção do serviço até consequências mais graves. Entretanto, não se deve presumir que toda falha desse tipo permita execução remota de código em qualquer ambiente.
A correção mencionada neste cenário está associada à versão 1.2.1 do Brotli, disponibilizada pelo Google. O ponto central para os administradores é verificar se a biblioteca vulnerável foi efetivamente substituída na distribuição utilizada pela aplicação, em vez de confiar apenas na versão principal do interpretador PHP.
O papel da extensão cURL e da descompressão automática
A extensão cURL permite que aplicações PHP realizem requisições HTTP e HTTPS para APIs, servidores remotos e outros serviços. Ela é utilizada em integrações com plataformas de pagamento, sistemas de autenticação, serviços de armazenamento e aplicações corporativas.
Para economizar largura de banda, um cliente HTTP pode solicitar respostas compactadas e descompactá-las automaticamente antes de entregar o conteúdo à aplicação. No cURL, esse comportamento pode ser configurado por meio da opção CURLOPT_ENCODING.
Quando essa opção é definida para aceitar determinados formatos ou uma cadeia vazia, o cliente pode negociar os métodos de compressão suportados pela biblioteca e realizar a descompressão correspondente. O comportamento exato depende da versão, das bibliotecas disponíveis e das opções utilizadas.
É justamente nesse processamento que uma biblioteca de compressão vulnerável pode se tornar relevante. Se uma resposta HTTP controlada por um atacante for aceita e encaminhada ao decodificador afetado, o processamento dos dados poderá acionar a falha.
Isso não significa que qualquer servidor PHP esteja automaticamente exposto. A exploração depende da presença do componente vulnerável, do caminho de execução utilizado pela aplicação e das condições necessárias para alcançar o código defeituoso.
O perigo silencioso do Guzzle configurado por padrão
O Guzzle é um cliente HTTP bastante utilizado no ecossistema PHP. Ele simplifica a comunicação com APIs e serviços externos, oferecendo recursos para configurar requisições, autenticação, cabeçalhos, timeouts e tratamento de respostas.
Um dos aspectos importantes para a análise de segurança é o suporte à descompressão automática de conteúdo. Conforme a versão e a configuração do cliente, o Guzzle pode negociar formatos de compressão e decodificar as respostas recebidas sem exigir que o desenvolvedor implemente esse processo manualmente.
Na prática, isso significa que uma aplicação pode utilizar o Brotli indiretamente. O desenvolvedor talvez tenha escrito apenas uma chamada para consultar uma API, sem perceber que o processamento da resposta envolve componentes nativos adicionais.
Se o caminho de descompressão estiver habilitado e utilizar uma biblioteca afetada, uma resposta maliciosa poderá alcançar o componente vulnerável durante o fluxo normal da aplicação. O risco aumenta em sistemas que consultam endpoints externos sem validação adequada ou que processam dados de origens não confiáveis.
O uso do Guzzle, por si só, não comprova que uma aplicação esteja vulnerável. É necessário avaliar a versão instalada, as opções efetivamente utilizadas, os recursos de compressão disponíveis e a biblioteca Brotli carregada pelo cURL.
Para equipes de desenvolvimento, essa situação demonstra por que a análise de dependências não deve se limitar aos pacotes declarados diretamente no Composer. Bibliotecas nativas e componentes incorporados ao ambiente de execução também fazem parte da superfície de ataque.
Como identificar e atualizar as versões vulneráveis no Windows
A resposta mais importante para os administradores é que não basta executar php -v para confirmar a correção. O projeto PHP publicou novas compilações para Windows em 26 de outubro de 2026, mas preservou os números das versões principais porque a mudança está nas dependências incluídas nos pacotes.
As compilações corrigidas são:
| Versão do PHP | Pacote atualizado para Windows |
|---|---|
| PHP 8.5 | 8.5.12-1 |
| PHP 8.4 | 8.4.27-1 |
| PHP 8.3 | 8.3.36-1 |
| PHP 8.2 | 8.2.35-1 |
Esses pacotes incluem o Brotli 1.2.1, que corrige a vulnerabilidade CVE-2026-111497. O sufixo -1 identifica uma reconstrução do pacote com dependências atualizadas, sem alteração na versão-base do interpretador.
Por que o comando php -v não é suficiente
Ao executar php -v, o administrador continuará vendo números como PHP 8.5.12 ou PHP 8.4.27. Esse resultado é esperado, mas não comprova que a biblioteca vulnerável foi substituída.
A verificação precisa considerar o arquivo ZIP efetivamente instalado. Compare o nome do pacote original com o da nova compilação e confira o hash SHA-256 publicado na página oficial de downloads do PHP para Windows.
No PowerShell, o hash do arquivo baixado pode ser calculado com:
Get-FileHash .\php-8.5.12-1-nts-Win32-vs17-x64.zip -Algorithm SHA256Substitua o nome do arquivo pelo pacote correspondente à sua arquitetura e configuração. Compare o resultado com o valor oficial divulgado para aquele download.
Depois, instale a compilação corrigida seguindo o procedimento adequado ao ambiente. Se o PHP estiver integrado ao IIS, Apache, PHP-CGI ou outro serviço, reinicie o processo correspondente para garantir que a nova biblioteca seja carregada.
Atenção: não substitua arquivos de uma instalação em produção sem avaliar compatibilidade, permissões, configurações e possibilidade de reversão. Faça um backup e teste a atualização em um ambiente controlado sempre que possível.
Como o SBOM ajuda a confirmar a correção
O projeto PHP também disponibiliza um SBOM (Software Bill of Materials), documento que identifica componentes e dependências incorporados a um pacote de software.
Esse inventário é especialmente útil quando o número da versão principal não muda. Em vez de depender exclusivamente do resultado de php -v, a equipe pode consultar os componentes declarados no inventário associado à compilação e verificar qual versão do Brotli foi incluída.
O procedimento também ajuda organizações que mantêm inventários de ativos, políticas de conformidade ou ferramentas de análise de dependências. Ao registrar o pacote instalado, seu hash e as bibliotecas que o acompanham, a equipe cria evidências mais confiáveis de que a atualização foi aplicada.
É importante distinguir os ambientes: o comunicado trata das compilações oficiais do PHP para Windows. Em Linux, containers e distribuições que utilizam bibliotecas do sistema, a correção deve ser verificada conforme o pacote de Brotli e a cadeia de dependências efetivamente fornecidos pelo respectivo sistema operacional ou fornecedor.
Medidas de mitigação em código caso o patch não possa ser aplicado
A prioridade deve ser instalar a compilação corrigida. Entretanto, quando uma atualização imediata não é possível, algumas mudanças podem reduzir a exposição ao desativar a descompressão automática de respostas HTTP.
Essas medidas são paliativas. Elas não substituem a atualização da biblioteca vulnerável e não protegem outros caminhos da aplicação que possam utilizar o mesmo decodificador.
Desative a descompressão automática no cURL
Em aplicações que utilizam diretamente a extensão cURL, revise as opções aplicadas às requisições. A opção CURLOPT_ENCODING pode ativar a negociação e a descompressão de conteúdo, dependendo do valor configurado.
Se a aplicação não precisar desse recurso, evite habilitá-lo. Remova configurações como:
curl_setopt($ch, CURLOPT_ENCODING, '');O valor vazio permite que o cURL negocie os formatos de compressão suportados. Portanto, enquanto a biblioteca vulnerável não for atualizada, não habilite essa opção indiscriminadamente.
A revisão deve incluir funções auxiliares, bibliotecas internas e outros componentes que configurem opções cURL em nome da aplicação. Alterar apenas uma chamada não resolve o problema se outra parte do sistema continuar ativando a descompressão.
Desative a decodificação automática no Guzzle
Para aplicações que utilizam o Guzzle, a opção decode_content permite controlar a decodificação automática das respostas. Quando for compatível com o funcionamento da aplicação, defina essa opção como false:
$response = $client->request('GET', $url, [
'decode_content' => false,
]);Essa configuração evita que o Guzzle decodifique automaticamente o conteúdo da resposta por meio desse mecanismo. O código que consome a resposta, entretanto, precisará estar preparado para lidar com o conteúdo recebido, que pode permanecer comprimido.
Antes de aplicar a mudança em produção, teste integrações que dependam de respostas descompactadas. Também verifique a configuração efetiva do cliente e o comportamento da versão do Guzzle utilizada.
Não considere a desativação da decodificação uma correção definitiva. Se a aplicação ainda puder alcançar o Brotli vulnerável por outra biblioteca ou caminho de processamento, o risco poderá permanecer. O objetivo da mitigação é reduzir a superfície de ataque até que a atualização possa ser aplicada e validada.
Conclusão: a segurança da cadeia de suprimentos no desenvolvimento web
A vulnerabilidade CVE-2026-111497 demonstra como um componente aparentemente secundário pode comprometer a segurança de aplicações que, à primeira vista, não possuem relação direta com a biblioteca afetada. O Brotli está integrado a uma cadeia de dependências que envolve bibliotecas nativas, extensões PHP e clientes HTTP utilizados diariamente por desenvolvedores.
A falha recebeu uma avaliação de CVSS 9.2 na escala CVSS 4.0, indicando gravidade elevada. Esse valor reforça a necessidade de priorizar a correção, embora a possibilidade de exploração dependa da configuração do ambiente e do processamento de conteúdo controlado por terceiros.
Para quem administra servidores Windows, a principal recomendação é instalar as compilações 8.5.12-1, 8.4.27-1, 8.3.36-1 ou 8.2.35-1, conforme a versão utilizada. Como o número principal do PHP permanece igual, a validação precisa considerar o pacote instalado, seu hash e as dependências incluídas.
Desenvolvedores também devem revisar o uso de cURL e Guzzle, evitando habilitar a descompressão automática de conteúdo não confiável sem necessidade. Paralelamente, manter um inventário de dependências, acompanhar avisos de segurança e automatizar verificações de componentes vulneráveis ajuda a reduzir o tempo entre a divulgação de uma falha e sua correção.
O episódio evidencia um desafio importante para o desenvolvimento multiplataforma: atualizar o código da aplicação não é suficiente quando bibliotecas nativas incorporadas ao ambiente de execução também precisam de manutenção.
