O PHP publicou correções para as versões com suporte. Distribuições e serviços de hospedagem podem aplicar correções retroativas sem mudar o número da versão; consulte o aviso do fornecedor antes de concluir que um pacote continua vulnerável.
O que o PHP informou e qual é o impacto
Em 21 de outubro de 2026, o projeto PHP publicou correções para CVE-2026-109618 e CVE-2026-109619, duas falhas críticas no runtime. Em determinadas condições, elas podem permitir execução remota de código sem autenticação em instalações que atendem solicitações web. O PHP recomenda tratar essas instalações como expostas até confirmar a versão e a correção fornecida pelo provedor.
A CVE-2026-109618 envolve corrupção do estado interno durante o tratamento de falta de memória. A CVE-2026-109619 descreve um estado global que pode manter referências à memória de uma solicitação anterior. Não é necessário reproduzir o ataque: o objetivo é atualizar com cuidado e confirmar que a aplicação continua funcionando.
O aviso destaca um risco específico no Apache com mod_php. Também cita PHP-FPM, php-cgi, FrankenPHP e LiteSpeed. A exposição depende do runtime, da configuração e dos caminhos da aplicação; não presuma que todos os ambientes têm o mesmo cenário.
Versões afetadas e corrigidas
A tabela mostra as versões oficiais publicadas pelo PHP em 21 de outubro de 2026. “Corrigida a partir de” indica a primeira versão da linha que inclui a correção. Pacotes do sistema, imagens de provedores e hospedagem gerenciada podem receber uma correção retroativa sem mudar o número da versão; consulte também o aviso do fornecedor.
O suporte de segurança do PHP 8.2 está previsto para terminar em 31 de dezembro de 2026. A versão 8.2.35 corrige estas CVEs nessa linha, mas planeje migrar para uma versão que continue recebendo suporte. O PHP não publica mais versões regulares para 8.1 e anteriores. Há correções mínimas de código para 7.4, 8.0 e 8.1, e alguns fornecedores mantêm seus próprios pacotes. Confirme exatamente o que seu provedor entrega.
| Linha do PHP | Vulnerável antes de | Corrigida a partir de | Suporte de segurança |
|---|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 | Com suporte |
| 8.4 | < 8.4.27 | 8.4.27 | Com suporte |
| 8.3 | < 8.3.36 | 8.3.36 | Com suporte |
| 8.2 | < 8.2.35 | 8.2.35 | Até 31 dez. 2026 |
| 8.1, 8.0 e 7.4 | Afetadas; sem suporte regular | Correção mínima ou pacote do fornecedor | Confirme com o fornecedor |
| 7.3 e anteriores | Afetadas; sem suporte | Sem versão oficial indicada | Migre; não presuma que há correção |
Confira a correção dentro da linha correspondente. Pacotes de distribuições podem incluir correções retroativas e mostrar outro número de versão.
Antes de atualizar: inventário e preparação
Procure todos os lugares que usam PHP: servidores, contêineres, imagens-base, painéis de hospedagem, produtos com runtime incluído, processos em segundo plano e ambientes de teste. Um site pode usar várias versões. Identifique o serviço que recebe tráfego e quem é responsável por cada atualização.
Registre a versão e a origem do pacote, sistema operacional, servidor web, runtime, imagem se houver, aplicação, ambiente, responsável e o plano para voltar à versão anterior se algo falhar. Não publique `phpinfo()`: ele pode revelar dados sensíveis. Use o inventário interno, o painel do provedor ou comandos autorizados.
Leia as notas do fornecedor e o guia de migração se for mudar de linha do PHP. Prepare uma janela de manutenção, um backup que possa ser restaurado e um plano de retorno. Em serviços gerenciados, peça confirmação da versão instalada e de qualquer reinicialização ou nova implantação necessária.
Etapas para atualizar com segurança
- Comece pelos serviços acessíveis pela Internet e confirme se o fornecedor já disponibilizou o pacote corrigido.
- Atualize primeiro um ambiente parecido com o de produção, seguindo as instruções do sistema, hospedagem ou imagem.
- Recrie e publique os contêineres usando uma imagem corrigida; atualizar o servidor não altera o PHP que está dentro da imagem.
- Reinicie ou substitua os processos PHP conforme a orientação do fornecedor para que todos carreguem a versão nova.
- Confirme a versão no ambiente que realmente recebe as visitas, não apenas em outro terminal.
- Faça os testes básicos e os testes de regressão prioritários.
- Durante o período combinado, acompanhe erros, registros e métricas.
- Se algo importante falhar, interrompa a implantação, registre o ocorrido e volte à versão anterior conforme o plano. Um WAF ou uma regra temporária não substitui a atualização.
- 01Listar runtimes
- 02Aplicar a correção
- 03Confirmar processos ativos
- 04Testar os fluxos
- 05Revisar resultados
- 06Decidir se pode publicar
Como montar o plano de regressão
Depois da atualização, os testes de regressão ajudam a encontrar efeitos indesejados no sistema e nas integrações. Eles não provam que o runtime está livre de vulnerabilidades e não substituem uma análise de segurança, das dependências ou da configuração.
Defina o que mudou: versão do PHP, serviços, configuração, extensões, dependências e ambientes. Mapeie os fluxos que usam PHP e os componentes que compartilham processos, sessões, cache, arquivos ou filas. Priorize pelo impacto no negócio, exposição e dificuldade de recuperação. Registre dependências desconhecidas como risco pendente.
Organize os testes em três grupos: verificações básicas de disponibilidade e funções essenciais; testes focados nos caminhos alterados ou dependentes; e uma suíte mais ampla para componentes de maior impacto. Registre versão, ambiente e dados usados para poder investigar e repetir os resultados.
Casos de teste sugeridos
Adapte os exemplos à arquitetura e às regras do seu sistema. Eles não formam um pacote universal: remova o que não se aplica e inclua seus próprios fluxos, extensões e integrações. Use contas de teste e dados fictícios, nunca senhas ou dados pessoais reais.
| Área | Exemplo | O que verificar | Evidência útil |
|---|---|---|---|
| Disponibilidade | Inicialização, verificação de saúde e página principal | Processo ativo, resposta esperada e dependências disponíveis | Versão, ambiente, horário, código HTTP e registro sem dados sensíveis |
| Login | Entrar, sair e expiração da sessão | Sessão válida, encerramento e redirecionamento | Conta fictícia, etapas e resultado; nunca senha ou cookie |
| Permissões | Acesso permitido e negado por perfil | Permissões e resposta a acesso não autorizado | Perfil, recurso e resultado esperado e observado |
| Formulários | Criar ou editar um registro importante | Validação, gravação e regras de negócio | Dados fictícios, etapas e captura sem dados pessoais |
| APIs | Resposta de sucesso, erro e timeout | Código, campos, autenticação e tratamento de falhas | Solicitação e resposta sem segredos |
| Arquivos | Enviar, ler e baixar um arquivo | Tipo e tamanho aceitos, armazenamento e permissões | Arquivo fictício, resultado e registros sem conteúdo sensível |
| Tarefas em segundo plano | Fila, tarefa agendada e nova tentativa | Estado final e tratamento de erro | ID da tarefa, horários e resultado sem dados sensíveis |
| Dados e sessões | Persistência entre solicitações e processos | Consistência, separação entre usuários e continuidade da sessão | IDs fictícios e estado antes e depois |
Quando os testes podem ser concluídos
Defina antes de começar o que impede a implantação. Não avance se falhar o login, as permissões, uma operação importante, a integridade dos dados ou uma integração essencial; se não for possível confirmar a versão corrigida; ou se surgirem erros sem explicação. Um teste bloqueado por falta de ambiente ou dados não conta como aprovado.
Ao concluir, compare os testes com o que mudou. Revise falhas, bloqueios, itens pendentes, evidências, defeitos e riscos que ainda existem. Uma suíte aprovada só confirma os casos executados; não prova que todos os servidores têm a correção.
Checklist final
- O inventário inclui servidores, contêineres e serviços do provedor.
- A origem do pacote e o aviso usado para confirmar a correção foram registrados.
- Os processos que recebem tráfego foram reiniciados conforme a orientação.
- Versão, ambiente e dados fictícios aparecem nos resultados.
- Falhas, bloqueios e riscos pendentes têm uma pessoa responsável.
- Senhas e dados pessoais foram removidos das evidências.
Como guardar evidências dos testes
No Treseko, a equipe pode organizar casos, suítes, versões, execuções, resultados, defeitos e anexos para consultar o que foi verificado e quais riscos continuam abertos. A equipe precisa configurar e executar os testes no próprio ambiente. O Treseko não instala a correção nem confirma automaticamente todas as versões do PHP.
Fontes oficiais e materiais úteis
- Aviso oficial de segurança do PHP
- Aviso CVE-2026-109618 (PHP/GitHub)
- Aviso CVE-2026-109619 (PHP/GitHub)
- Versões do PHP com suporte
- Downloads oficiais do PHP
- Guia oficial de migração do PHP 8.5
Este guia é material educativo de QA. Ele não substitui orientações do PHP, do sistema operacional, do contêiner ou do provedor de hospedagem. Última revisão: 21 de outubro de 2026.