Perguntas frequentes
Quais versões do PHP são afetadas?
Todas as versões anteriores a 8.5.12, 8.4.27, 8.3.36 e 8.2.35 nos branches com suporte. PHP 8.1 e anteriores estão em fim de vida e não recebem release do projeto PHP; considere-os afetados, a menos que seu fornecedor confirme um backport da correção.
Meu site não mostra a versão do PHP. Estou seguro?
Não necessariamente. Ocultar a versão (expose_php = Off) é uma boa prática, mas não corrige nada. Verifique no servidor com php -v ou pergunte ao seu provedor.
O verificador mostra uma versão antiga, mas minha hospedagem diz que está corrigida. Quem está certo?
Possivelmente ambos. Distribuições Linux como Debian, Ubuntu e RHEL costumam fazer backport de correções de segurança sem alterar o número de versão. Pergunte à sua hospedagem qual build do pacote está instalado e se o changelog menciona as CVE-2026-109618 e CVE-2026-109619.
WordPress, Laravel ou meu CMS são afetados?
As falhas estão no próprio PHP, então qualquer aplicação rodando em um PHP afetado fica exposta. Os pesquisadores demonstraram ataques sem autenticação contra WordPress, Drupal e Joomla, mas eram apenas exemplos — até uma simples página “Hello World” basta. Atualizar o WordPress ou os plugins não resolve — o PHP precisa ser atualizado.
Dados podem vazar mesmo sem execução de código?
Sim. A CVE-2026-109619 pode expor a memória do processo PHP — senhas, tokens de sessão, chaves de API e certificados de outras requisições — sem que o atacante execute código. Esses vazamentos não deixam arquivos e são difíceis de detectar, então troque os segredos de qualquer site que tenha rodado uma versão afetada na internet.
Desativar session.upload_progress resolve?
Não. O php.net lista session.upload_progress.enabled=0 como mitigação parcial para alguns caminhos confirmados da CVE-2026-109619. Ela não cobre todas as variantes e não tem efeito algum sobre a CVE-2026-109618.
Um firewall de aplicação web é suficiente?
Um WAF ou limites de requisição podem reduzir a exposição enquanto você atualiza, mas os problemas estão na forma como o PHP trata requisições e memória. A atualização continua sendo necessária.
Preciso reiniciar algo depois de atualizar?
Sim. PHP-FPM, Apache, LiteSpeed e workers de longa duração continuam executando o código antigo até serem reiniciados. Contêineres precisam ser recriados a partir da nova imagem.
O que este verificador realmente faz?
Ele envia uma requisição HEAD (ou GET, se HEAD não for permitido) ao endereço informado, segue até três redirecionamentos e lê cabeçalhos de resposta como X-Powered-By e Server. Ele nunca envia payloads de exploit, requisições grandes ou uploads, e não varre outros caminhos.
É legal verificar qualquer site?
Verifique apenas sites que você possui ou está autorizado a avaliar. A requisição é igual a uma visita normal, mas o uso responsável é responsabilidade sua. Limitamos as verificações por rede e por site.
O PHP 8.5.12 foi corrigido por completo?
Relatos de uma falha (crash) no 8.5.12 circularam em 22 de outubro de 2026, mas não foram confirmados como vulnerabilidade remota. Acompanhamos o php.net; se sair um novo release, este site será atualizado e a data de “última verificação” mudará.
Onde posso ler os detalhes oficiais?
No php.net e nos avisos do GitHub do projeto PHP GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp. A equipe de pesquisa (Wiz Research, OpenAI Codex Security e Calif) publicou suas descobertas em php2shell.com.
Quem descobriu as vulnerabilidades?
Pesquisadores da Wiz Research, da OpenAI Codex Security e da Calif, por meio de divulgação coordenada com a equipe de segurança do PHP, que preparou as correções. Veja a publicação da The PHP Foundation sobre o release.