Comece pelo ambiente que realmente atende o site

A correção principal para as duas falhas conhecidas como PHP2Shell é atualizar o PHP. O cuidado operacional é descobrir qual instalação precisa ser atualizada e confirmar que a mudança chegou ao serviço que recebe as requisições.

Este roteiro é uma verificação defensiva. Não é necessário executar um ataque para começar a avaliar a exposição. Identificar runtime, pacote, configuração e origem da atualização permite tomar uma decisão sem provocar falhas em produção.

Confira o runtime web, além da linha de comando

A versão retornada por php -v informa sobre o executável chamado no terminal. O site pode usar outro binário, uma versão selecionada no painel da hospedagem ou um contêiner próprio. Por isso, confira o serviço e o pool associados à aplicação, incluindo o caminho efetivamente utilizado pelo servidor web. (PHP — opções de linha de comando)

Faça essa conferência por acesso administrativo restrito. Evite deixar uma página phpinfo disponível publicamente: ela pode revelar versões, caminhos, configuração e variáveis do ambiente. Se um diagnóstico temporário for necessário, limite seu acesso e remova-o depois da verificação. (PHP — informações expostas por phpinfo)

Compare a instalação com uma fonte confiável

Nas versões upstream, as correções para CVE-2026-109618 e CVE-2026-109619 foram disponibilizadas em PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Os registros publicados pelo próprio PHP identificam esses limites nas respectivas séries. (Registro CVE-2026-109618, registro CVE-2026-109619)

Se a distribuição ou o fornecedor aplica backports, uma versão aparentemente anterior pode conter o patch. Confira o pacote completo, o repositório de origem e o comunicado de segurança do mantenedor. Guarde essa evidência. Um número isolado ou um resultado genérico de scanner não encerra a análise.

Para PHP sem suporte upstream, confirme a cobertura real do fornecedor e planeje a migração. Atualizar o framework ou os plugins não demonstra que o interpretador que executa a aplicação foi corrigido.

Aplique a mudança no serviço certo

Antes da alteração, tenha backup recuperável, procedimento de retorno e uma validação de compatibilidade proporcional ao sistema. Isso ajuda a executar uma atualização urgente sem descobrir durante a mudança que ninguém sabe restaurar o serviço.

Em instalações por pacotes, use o canal confiável da distribuição ou da hospedagem e reinicie ou recarregue os serviços de modo que todos os workers antigos sejam substituídos. Confirme que o procedimento realmente encerrou os processos anteriores.

Em Docker, obtenha a imagem corrigida ou reconstrua a aplicação sobre uma base atualizada. Depois, recrie os contêineres que usam essa imagem. Baixar uma imagem nova não troca automaticamente um contêiner já em execução. A Docker informou a atualização das imagens oficiais para essas falhas. (Docker — atualização das imagens PHP, Docker — recriação de contêineres)

Verifique todas as instâncias e registre a conclusão

Repita a conferência nas réplicas, nos pools adicionais e nos serviços que incorporam seu próprio PHP. O ambiente pode responder por instâncias diferentes atrás de um balanceador. Corrigir apenas uma delas deixa a entrega incompleta. (NCSC-NL — inventário e verificação)

Depois da mudança, confirme o runtime ativo, faça verificações de saúde e valide autenticação, formulários, uploads e integrações relevantes. Registre pacote ou imagem, data, responsável e resultados. O critério de conclusão precisa demonstrar o que está rodando, além de mostrar que um comando terminou sem erro.

Se houver indícios de comprometimento, trate a investigação separadamente. Aplicar o patch não remove automaticamente alterações indevidas nem substitui a análise de credenciais e registros.

Inclua o cuidado adicional de 23 de outubro

O aviso de 23/10/2026 recomenda session.upload_progress.enabled=0 até o próximo bugfix para uma configuração incomum de sessão, acompanhada como CVE-2026-115560. Confira as condições no aviso. (PHP — atualização sobre sessões)

Aplique a configuração no php.ini ou no pool/servidor, antes da análise da requisição, e reinicie todos os workers. Alterá-la apenas com ini_set() na aplicação não basta. (PHP — aplicação da mitigação de sessão)

As fontes técnicas deste artigo foram conferidas em 23 de outubro de 2026. Continue acompanhando o projeto e seu fornecedor: novas orientações precisam entrar no procedimento, inclusive depois da primeira atualização.

O laboratório mostrado no vídeo

O vídeo usa um laboratório com Apache, PHP e Docker para explicar a identificação e a correção do problema. A aplicação prática em cada empresa começa pelo conhecimento do próprio ambiente e termina com a confirmação da atualização. (Assista ao vídeo no Instagram)