PHP 8.2.33, 8.3.33, 8.4.24 e 8.5.9 corrigem falhas de segurança

O PHP publicou em 30 de julho de 2026 atualizações de segurança para todos os branches suportados. As versões 8.2.33, 8.3.33, 8.4.24 e 8.5.9 corrigem vulnerabilidades que incluem SQL injection na extensão PDO PostgreSQL, gravações fora dos limites em BCMath, atualização de segurança da libgd e negação de serviço em Phar.

O que aconteceu

As correções não representam uma única falha universal. O risco de cada servidor depende das extensões instaladas e do modo como a aplicação usa suas APIs:

• CVE-2026-17543: quebra de escape com barra invertida em literais E'...' na extensão PDO_PGSQL, permitindo SQL injection quando a aplicação depende da função de quoting vulnerável;
• CVE-2026-17544: gravação fora dos limites em bccomp(), presente nos branches mais novos que incluem a implementação afetada;
• CVE-2026-9672: correção entregue por atualização da biblioteca libgd usada pela extensão GD;
• CVE-2026-7260: crash por links simbólicos recursivos em Phar, com impacto de disponibilidade.

SQL injection pode expor ou alterar dados de acordo com a conta usada pela aplicação. Falhas de memória podem encerrar processos PHP, provocar indisponibilidade e, dependendo do defeito e ambiente, justificar prioridade maior. Não presuma que “meu site não usa PostgreSQL” elimina todas as demais correções do release.

Versões afetadas e corrigidas

A CVE-2026-17544 aparece em 8.4.24 e 8.5.9; as CVEs de PDO_PGSQL, GD e Phar também foram corrigidas nos releases 8.2.33 e 8.3.33. Instale hoje o patch mais recente oferecido pelo repositório, que pode ser superior ao primeiro corrigido. PHP 8.2 recebe apenas correções de segurança até 31 de dezembro de 2026; planeje a migração para branch mais novo.

Nível de risco

Classificamos o boletim como alto para aplicações que usam PDO_PGSQL com dados não confiáveis no fluxo vulnerável ou processam arquivos/imagens enviados por usuários. Para sites sem essas extensões e sem entrada controlada por terceiros, o risco contextual pode ser menor, mas a atualização continua necessária porque o pacote reúne correções de memória e robustez.

Como verificar o servidor e cada site

O servidor pode ter múltiplos PHPs: CLI, PHP-FPM, LiteSpeed e versões selecionadas por domínio. Verifique todos:

php -v
php -r 'echo PHP_VERSION, PHP_EOL; print_r(get_loaded_extensions());'
php --ini
ps -eo command | grep -E '[p]hp-fpm|[l]sphp'

Em cPanel, liste pacotes EasyApache e versões disponíveis:

rpm -qa | grep -E '^ea-php(82|83|84|85)' | sort
/usr/local/cpanel/bin/rebuild_phpconf --current

No site, use MultiPHP Manager e confirme o domínio. Evite deixar um phpinfo() público: ele revela módulos, caminhos e configuração. Depois da atualização, valide php -v para CLI e uma página controlada ou o painel para o SAPI do site.

Como corrigir sem quebrar a aplicação

1. faça backup de arquivos, banco e configuração;
2. registre versão, extensões e handler atuais;
3. instale o patch do mesmo branch pelo repositório do sistema/cPanel;
4. reinicie os pools e o web server de forma controlada;
5. limpe OPcache quando aplicável;
6. teste login, formulários, uploads, imagens, tarefas cron e integrações;
7. revise logs PHP-FPM, Apache/LiteSpeed e da aplicação.

Mudar de 8.2 para 8.4 ou 8.5 é uma atualização de branch e pode introduzir incompatibilidades. Aplicar 8.2.33 sobre 8.2.32 é uma atualização de patch com risco de compatibilidade menor. Corrija primeiro dentro do branch; depois planeje a evolução com ambiente de homologação.

Medidas adotadas pela WebinHost

A WebinHost acompanha os pacotes PHP oferecidos pela distribuição e pelo EasyApache, mantendo múltiplos branches para compatibilidade nos serviços elegíveis. Atualizações de patch são aplicadas com validação do handler e dos serviços; a troca da versão selecionada por um site precisa considerar plugins, temas e código do cliente. Imunify360 ajuda contra payloads web e malware, mas não corrige uma extensão PHP vulnerável.

Nos serviços em que o gerenciamento da camada de servidor faz parte do contrato, o fluxo da WebinHost inclui acompanhamento dos canais de segurança dos fornecedores, inventário do componente, avaliação de exposição, aplicação controlada da correção disponível e validação posterior. Quando o kernel e a distribuição são compatíveis, o KernelCare reduz a janela de exposição ao aplicar live patches sem aguardar uma reinicialização; quando a correção exige um novo kernel ou o fornecedor não oferece live patch, a equipe planeja a atualização e o reboot conforme o risco e a janela operacional.

O Imunify360 complementa essa resposta com firewall de aplicação, detecção de malware, defesa proativa e inteligência de reputação nos planos elegíveis. Essas camadas ajudam a bloquear ou detectar tentativas, mas não substituem a correção do pacote vulnerável. CloudLinux e CageFS também aumentam o isolamento entre contas, sem transformar uma versão desatualizada em versão segura.

Tutoriais, downloads e serviços relacionados

Use estes materiais para continuar a verificação com segurança:

Referências oficiais

• PHP.net — changelog oficial do PHP 8
• PHP.net — alterações de segurança do PHP 8.2.33
• PHP.net — alterações de segurança do PHP 8.4.24
• PHP.net — branches suportados e datas de fim de suporte

Nota técnica: distribuições Linux e painéis frequentemente aplicam backports. O número exibido por um pacote pode ser diferente da versão upstream e ainda conter a correção. Compare sempre o pacote com o advisory da distribuição ou do painel. Não execute prova de conceito em produção; os comandos deste boletim são de inventário e verificação.