Atualização de segurança do PHP: corrija primeiro e revise segredos e acessos

Em 21 de outubro de 2026, o PHP publicou 8.5.12, 8.4.27, 8.3.36 e 8.2.35 para corrigir CVE-2026-109618 e CVE-2026-109619, vulnerabilidades críticas que podem permitir execução remota de código sem autenticação. O anúncio oficial aponta risco nas instalações que atendem requisições web, incluindo PHP-FPM e Apache mod_php. Atualizar é a correção completa; medidas temporárias não são equivalentes.

Uma instalação vulnerável não prova uma invasão. Trate correção, investigação e recuperação de credenciais como tarefas relacionadas, tomando decisões conforme o ambiente e as evidências.

Confirme o que realmente atende às requisições

Faça um inventário de sites públicos, serviços internos, contêineres e contas de hospedagem que executam PHP. Confirme a versão e a correção do ambiente que processa as requisições web; a versão na linha de comando pode ser de outra instalação.

Na hospedagem gerenciada, peça ao operador a confirmação do pacote aplicado, do serviço afetado e da reinicialização ou implantação. Distribuições podem aplicar correções a versões antigas; obtenha a confirmação do fornecedor em vez de considerar apenas o número da versão original. Confira o escopo com o operador usando os avisos da equipe PHP. Não publique uma página de diagnóstico que exponha configurações do servidor.

Contenha a exposição e restaure um ambiente confiável

Coordene a atualização rapidamente com a hospedagem ou equipe de operações. Restrinja a exposição ou isole sistemas quando a avaliação do incidente exigir, preservando as evidências relevantes. Não adie uma contenção urgente só para terminar de coletar logs.

Revise o período de exposição, logs web e do sistema, arquivos ou processos inesperados e eventos de auditoria dos fornecedores envolvidos. A falta de alertas ou logs aparentemente normais não prova que o servidor ficou intacto.

Se a invasão estiver confirmada ou houver suspeita razoável, siga o procedimento de incidentes para reconstruir ou restaurar a partir de uma fonte confiável. A correção não remove mecanismos de persistência do invasor. Não use um servidor ou dispositivo sem confiança para gerar, receber ou instalar novos segredos.

Avalie as credenciais antes da rotação

Liste aquelas que o processo afetado podia acessar: configuração do aplicativo, variáveis de ambiente, tokens de implantação, credenciais de banco de dados e chaves de API. Determine permissões, escopo e possível exposição. O anúncio sozinho não mostra que todas as credenciais da organização vazaram.

Para as potencialmente expostas, coordene substituição e revogação no serviço emissor usando um dispositivo administrativo confiável. Instale as novas credenciais no ambiente reconstruído e verifique as integrações legítimas. Escolha a sequência conforme abuso ativo, recursos do fornecedor e dependências. Não prometa operação sem interrupção nem deixe uma chave exposta ativa indefinidamente por conveniência.

Revise sessões e acessos de recuperação conforme necessário e registre o responsável por cada mudança. Nunca inclua os segredos em texto aberto no chamado ou log do incidente. OWASP

Encerre o acesso emergencial quando o trabalho terminar

Dê a cada responsável uma conta individual, com permissões mínimas e horário de encerramento combinado. Após a recuperação, revise funções temporárias, sessões, acesso de implantação e links de entrega. Remova acessos retidos sem necessidade e confirme os resultados no serviço correspondente, sem depender só de um lembrete no calendário.

Separe três controles diferentes

Use uma entrega temporária só depois de restaurar a confiança

Se o procedimento permitir, crie uma nota protegida por senha em um sistema confiável com o mínimo necessário para um destinatário verificado. Envie a senha separadamente e use expiração ou limites de acesso quando o plano oferecer. Não inclua frases de recuperação de carteiras nem chaves privadas.

O LOCK.PUB é uma ferramenta limitada de entrega: não corrige PHP, repara dispositivos infectados, revoga chaves de fornecedores nem recolhe cópias. Não substitui o gerenciador de segredos, os controles de identidade ou a resposta a incidentes.

Perguntas frequentes

Instalar a atualização do PHP encerra a investigação?

Não. Ela trata a vulnerabilidade; as evidências e a exposição determinam a investigação, recuperação e ações sobre credenciais ainda necessárias.

Expirar a nota desativa a chave de API que estava nela?

Não. Revogue ou substitua a chave no serviço emissor. Uma credencial copiada continua separada do link que a entregou.

Leia também: compartilhar chaves de API com limites claros.