5 perguntas que mostram se a sua empresa realmente tratou o PHP2Shell

Na semana em que duas falhas críticas do PHP colocaram milhões de sites em risco, a pergunta mais importante a ser feita não é “já atualizamos?”, e sim: “conseguimos provar que tratamos o problema do jeito certo?”.

Neste artigo, explicamos de forma simples o que um auditor, um cliente ou a própria diretoria deveriam conseguir verificar depois de uma falha como essa. Se você ainda não conhece os detalhes técnicos da vulnerabilidade, clique aqui e leia antes o nosso primeiro artigo que fala mais sobre o PHP2Shell.

Para empresas certificadas na ISO 27001, o tema merece atenção especial. Pela repercussão mundial, é provável que o PHP2Shell seja abordado nas próximas auditorias, internas e externas, como teste dos controles de gestão de vulnerabilidades técnicas (8.8) e de inteligência de ameaças (5.7) do Anexo A.

Continue a leitura para saber mais sobre o assunto e conferir as providências recomendadas para chegar preparado a essa conversa. 

O que aconteceu com o PHP2Shell?

Em 21 de outubro de 2026, o projeto PHP publicou correções para duas vulnerabilidades críticas, a CVE-2026-109618 e a CVE-2026-109619, apelidadas de PHP2Shell. O PHP é a linguagem por trás de cerca de 70% dos sites cuja tecnologia de servidor é conhecida, incluindo sites em WordPress, lojas virtuais, portais de clientes e sistemas internos. As falhas permitem que um atacante, sem login nem senha, execute comandos no servidor e assuma o controle dele.

Por isso, o PHP2Shell não é um problema da TI das grandes empresas. Ele atinge desde o site institucional de uma pequena empresa até portais de bancos, e muitas vezes chega por meio de fornecedores: a hospedagem, a agência que mantém o site, o sistema contratado de terceiros.

A resposta é conhecida: atualizar para as versões corrigidas (8.2.35, 8.3.36, 8.4.27 ou 8.5.12) ou aplicar medidas de contenção enquanto isso não é possível. Mas existe uma segunda camada, que separa uma reação improvisada de uma gestão madura: a capacidade de demonstrar, com registros, o que foi feito, por quem, quando e com qual resultado.

O que é a ISO 27001 e por que ela importa nesse caso?

A ISO/IEC 27001 é a norma internacional que orienta como uma organização deve gerenciar a segurança das suas informações. Ela não diz qual ferramenta comprar nem qual antivírus usar. Ela pede que a empresa tenha um Sistema de Gestão de Segurança da Informação (SGSI): um conjunto organizado de regras, processos, responsabilidades e registros para proteger as informações de forma contínua.

Uma forma simples de entender o SGSI é pensar no ciclo que qualquer gestor já conhece: planejar, executar, verificar e melhorar. A norma aplica esse ciclo à segurança. E, para que tudo isso não fique só no discurso, ela exige evidências: registros que permitem a qualquer pessoa (um auditor, um cliente, a diretoria) verificar que o processo realmente aconteceu.

É aqui que entram as cinco perguntas deste artigo. Elas são, na prática, o roteiro que um auditor percorre ao avaliar como a empresa lidou com uma vulnerabilidade como o PHP2Shell. E servem igualmente para qualquer gestor que queira saber se a sua empresa está, de fato, no controle da situação.

Vale para qualquer empresa, certificada ou não: Responder “sim” às cinco perguntas, com evidências, é sinal de que a organização tem controle sobre seus riscos. Responder “não sei” a qualquer uma delas já é, por si só, um achado importante.

Quais são as 5 perguntas que comprovam o tratamento da vulnerabilidade?

As perguntas seguem a ordem natural de qualquer resposta a uma falha. Cada etapa responde a uma dúvida central:

1. Preparação: o processo existia antes?
2. Identificação: percebemos a falha e avaliamos o risco?
3. Decisão: decidimos com responsabilidade?
4. Comprovação: a correção funcionou?
5. Aprendizado: o que melhoramos?

A seguir, cada pergunta é explicada em linguagem simples, com uma comparação do dia a dia, as evidências esperadas e um exemplo aplicado ao PHP2Shell.

1. O processo estava definido antes da vulnerabilidade?

- Em linguagem simples: A empresa já sabia o que fazer quando uma falha grave fosse anunciada, antes de o PHP2Shell aparecer? Ou o procedimento foi criado às pressas, no meio da crise?

- Para entender: É como o plano de evacuação de um prédio. Ele precisa existir, estar aprovado e ser conhecido antes de o alarme tocar. Desenhar a rota de fuga durante o incêndio não funciona.

- Por que isso importa: No caso do PHP2Shell, os detalhes da falha vazaram em 20 de outubro, antes da correção oficial e os primeiros ataques foram registrados em poucas horas. Quem tinha um processo pronto ganhou tempo; quem precisou decidir tudo do zero perdeu justamente as horas mais críticas. 

O que serve como evidência:

• Procedimento aprovado: documento formal de gestão de vulnerabilidades, com versão e data de aprovação anteriores ao incidente.
• Critérios de priorização: como a empresa classifica uma falha (crítica, alta, média, baixa) e qual prazo de tratamento vale para cada nível.
• Responsabilidades: quem monitora os alertas, quem avalia, quem aprova e quem executa.
• Regras de monitoramento: quais fontes a empresa acompanha (avisos de fabricantes, centros de resposta a incidentes, fornecedores) e com que frequência. No Anexo A da ISO 27001, essa atividade corresponde ao controle 5.7 (Inteligência de ameaças).

→​ Exemplo ilustrativo no caso PHP2Shell: A empresa consegue mostrar que, desde antes de outubro, seu procedimento previa, por exemplo, que “vulnerabilidades críticas em sistemas expostos à internet devem ser avaliadas em até 24 horas”, e indicava qual área é responsável por acompanhar os avisos do projeto PHP e dos fornecedores de sistemas.

→​ Não existe prazo único na norma: A ISO 27001 não define um prazo universal para aplicar correções. Cada empresa define os seus, de acordo com seus critérios de risco. O que a norma exige é que esses prazos existam, estejam aprovados e sejam cumpridos, e que qualquer exceção seja justificada formalmente.

2. A organização identificou e avaliou a vulnerabilidade?

- Em linguagem simples: Quando o alerta saiu, alguém percebeu? A empresa descobriu se usava PHP, onde, em qual versão e qual seria o impacto caso um atacante explorasse a falha?

- Para entender: Pense em um recall de automóveis. Não basta saber que o recall existe: é preciso conferir se o seu carro é daquele modelo e daquele lote e entender o risco de continuar dirigindo até o reparo.

- Por que isso importa: O PHP costuma estar “escondido” dentro do site institucional, de um portal de clientes, de um painel de hospedagem ou de um sistema comprado de terceiros. Sem saber onde ele está, não há como proteger. E nem todo sistema é igual, por exemplo, uma loja virtual que processa pagamentos é mais crítica do que um site de testes.

- Inteligência de ameaças: o que muda a prioridade. A gestão de vulnerabilidades (controle 8.8) responde à pergunta: “temos essa falha?”. A inteligência de ameaças (controle 5.7) responde a outra, tão importante quanto: “o que os atacantes estão fazendo com ela agora?”. No PHP2Shell, essa diferença foi decisiva. Os detalhes da falha vazaram em 20 de outubro, a Cloudflare relatou os primeiros ataques na manhã de 21 de outubro, horas antes da correção oficial e fornecedores de segurança registraram varreduras automatizadas em todo o mundo. Quem acompanhava essas fontes entendeu que não se tratava apenas de uma falha crítica, mas de uma falha já explorada. Isso justificou medidas de contenção antes da correção e a busca imediata por sinais de invasão.

Para demonstrar o controle 5.7, a empresa deve conseguir mostrar quais fontes acompanha, quando e por qual fonte recebeu a informação, a análise feita (relevância para o seu ambiente, exploração ativa, indicadores de ataque), para quem a informação foi comunicada e qual decisão ela apoiou.

O que serve como evidência:

• Alerta registrado: data e hora em que a empresa tomou conhecimento, a fonte (por exemplo, o aviso oficial do PHP), os códigos das falhas (CVEs) e quem fez a triagem.
• Informações de inteligência de ameaças: registro do que se sabia sobre a falha no momento da análise (exploração ativa, varreduras em massa, indicadores de ataque) e de como essas informações influenciaram a prioridade.
• Ativos identificados: relação dos servidores, sites e sistemas que usam PHP, com a versão e a indicação dos que estão acessíveis pela internet, normalmente extraída do inventário de ativos.
• Avaliação de riscos conforme a metodologia aprovada: registro de que a empresa analisou probabilidade, impacto e proteções existentes usando o método que ela mesma definiu, e não uma opinião informal.
• Ativos de terceiros: confirmação formal dos fornecedores (hospedagem, plataformas SaaS, sistemas contratados) sobre o uso de PHP e a situação da correção.
• Conclusão de não aplicabilidade, quando for o caso: registro de que a análise foi feita, quais ativos foram verificados e por que a empresa concluiu que não é afetada.

→​ Exemplo ilustrativo no caso PHP2Shell: O registro mostra que o alerta foi recebido na manhã de 21 de outubro; que o inventário apontou os servidores com PHP e quais deles estão expostos à internet; e que o portal de clientes foi classificado como risco crítico, por ser acessível publicamente e tratar dados pessoais.

→​ Distinção essencial: Descobrir uma vulnerabilidade não significa que a empresa “falhou”, nem que foi invadida. Ter falhas em software é inevitável; o que se avalia é a forma como a empresa reagiu. Uma não conformidade só existe quando o processo não foi seguido ou se mostrou insuficiente.

3. A decisão de tratamento foi justificada e autorizada?

- Em linguagem simples: Depois de avaliar o risco, a empresa decidiu o que fazer: corrigir, conter temporariamente, tirar o sistema do ar ou, em casos específicos, conviver com parte do risco. Essa decisão foi tomada por quem tinha autoridade para isso e com um motivo registrado?

- Para entender: É como uma decisão médica. O médico registra o diagnóstico, o tratamento escolhido, o motivo da escolha e o consentimento do paciente. Se algo der errado, é possível reconstituir o que foi decidido e por quê.

- Por que isso importa: Nem sempre é possível atualizar na hora. Um sistema antigo pode depender de uma versão do PHP que não receberá correção (PHP 5 e PHP 7 já estão fora de suporte). Nesses casos, a empresa pode adotar medidas temporárias ou até aceitar algum risco por um período, mas essa escolha precisa ser consciente e assumida por quem responde pelo negócio, e não decidida informalmente por um técnico sobrecarregado.

O que serve como evidência:

• Plano de tratamento: o que será feito (atualizar, bloquear, isolar, retirar do ar), em quais ativos e com qual justificativa.
• Responsáveis e prazos: quem executa cada ação e até quando.
• Aprovações: registro de quem autorizou, de acordo com as alçadas internas da empresa.
• Aceitação formal do risco residual, quando aplicável: se algum risco permanecer, o responsável pelo negócio declara formalmente que está ciente dele, com prazo para nova avaliação.
• GMUD (Gestão de Mudança): registro formal da alteração no ambiente de produção, com planejamento, janela de execução, plano de retorno e aprovação, inclusive quando a mudança é emergencial.
• Chamado registrado: o ticket no sistema de atendimento que conecta o alerta, a decisão e a execução em um único histórico.

→​ Exemplo ilustrativo no caso PHP2Shell: O plano registra a atualização dos servidores expostos para a versão corrigida no mesmo dia, por meio de GMUD emergencial aprovada pelo gestor de TI; uma regra temporária de bloqueio no firewall de aplicação (WAF) até a conclusão da atualização; e a manutenção de um sistema legado em PHP 7 isolado da internet, com o risco residual aceito formalmente pela diretoria até a sua migração.

→​ Achado frequente em auditoria: “Correção instalada sem registro de mudança” é um dos apontamentos mais comuns. Em uma emergência, a mudança pode seguir um fluxo acelerado, mas ainda precisa ser registrada e aprovada.

4. Existe comprovação técnica da eficácia?

- Em linguagem simples: Depois da correção, alguém verificou se ela realmente funcionou? A versão nova está de fato em uso? A condição vulnerável deixou de existir?

- Para entender: Depois de trocar a fechadura de casa, você testa a chave antiga para ter certeza de que ela não abre mais a porta.

- Por que isso importa: É comum que uma atualização seja instalada, mas o serviço continue rodando a versão antiga até ser reiniciado; que um servidor esquecido fique de fora; ou que o pacote do fornecedor tenha numeração diferente da oficial. Além disso, como os ataques começaram antes da correção, é preciso verificar se o sistema não foi comprometido nesse intervalo.

O que serve como evidência:

• Nova verificação: varredura de vulnerabilidades (scan) ou checagem técnica da versão efetivamente em execução, feita depois da correção.
• Resultados dos testes: confirmação de que o sistema voltou a funcionar normalmente e de que a falha não pode mais ser explorada.
• Confirmação de que a condição vulnerável foi tratada: comparação entre o “antes” e o “depois”, com data, responsável e evidência (relatório, captura de tela, resultado do comando).
• Apuração de indícios de exploração: análise dos registros (logs) para verificar se houve tentativa ou sucesso de ataque antes da correção.

→ Exemplo ilustrativo no caso PHP2Shell: O relatório de validação mostra a varredura realizada após a correção, sem apontamento das duas CVEs; a versão corrigida em execução em cada servidor; e a análise dos registros de 20 e 21 de outubro, sem sinais de arquivos maliciosos instalados (webshells) ou de acessos suspeitos.

→ Critério de encerramento: Não encerre o caso apenas com “patch instalado”. Para concluir, é preciso ter a decisão de risco rastreável, a correção verificada e a investigação de possível exploração concluída. Se houver pendência, ela continua em acompanhamento, com aprovação de quem tem competência para isso.

5. Os resultados contribuíram para avaliar e melhorar o SGSI?

- Em linguagem simples: Depois que a situação se normalizou, a empresa parou para aprender? Mediu como foi a resposta, identificou o que não funcionou bem e mudou algo para a próxima vez?

- Para entender: Depois de cada partida, um time de futebol revê o jogo, identifica os erros e ajusta o treino. Sem essa análise, os mesmos gols continuam sendo sofridos.

- Por que isso importa: O PHP2Shell não será a última falha crítica. O valor de uma gestão madura está em transformar cada episódio em melhoria: se o inventário estava incompleto, ele precisa ser corrigido; se o alerta chegou tarde, as fontes de monitoramento precisam ser revistas; se um fornecedor demorou a responder, o contrato precisa ser ajustado.

O que serve como evidência:

• Indicadores: por exemplo, tempo entre o alerta e a avaliação, tempo até a correção e percentual de ativos corrigidos dentro do prazo.
• Análise dos desvios: o que saiu diferente do planejado e por quê (prazo estourado, ativo fora do inventário, fornecedor sem resposta).
• Ações de melhoria: ajustes no processo, no inventário, nos contratos com fornecedores ou nos treinamentos.
• Ações corretivas, quando necessário: se o processo não foi seguido ou falhou, registra-se a não conformidade, investiga-se a causa e define-se a correção.
• Análise crítica pela direção: o caso é levado à alta direção, que avalia os resultados e decide sobre recursos e prioridades.

→ Exemplo ilustrativo no caso PHP2Shell: Na reunião de lições aprendidas, a equipe identificou que um servidor de homologação com PHP não constava do inventário. Foi aberta uma ação corretiva, o inventário foi revisado e o indicador “tempo até a correção de vulnerabilidade crítica” passou a ser apresentado na análise crítica pela direção.

Sua empresa é certificada na ISO 27001? Saiba o que fazer antes da próxima auditoria

Auditores costumam testar o SGSI com casos reais e de grande repercussão. Um caso com a notoriedade do PHP2Shell é um candidato natural: o auditor pode pedir para ver, de ponta a ponta, como a empresa tomou conhecimento da falha e como a tratou. Por isso, recomendamos que as empresas certificadas, especialmente as que estão em ciclo de manutenção do SGSI, tomem seis providências agora:

1. Registre o caso, mesmo que a empresa não use PHP: A conclusão “não aplicável” também é uma evidência. Registre a data do alerta, quem fez a análise, quais ativos foram verificados e por que a empresa concluiu que não é afetada. Sem esse registro, não há como demonstrar que a análise foi feita.
2. Demonstre a inteligência de ameaças: Registre de qual fonte veio o alerta, quando ele chegou e o que a empresa fez com a informação. Se a empresa só soube do PHP2Shell pela imprensa, dias depois, esse é um sinal de que as fontes monitoradas no controle 5.7 precisam ser revistas, e vale registrar essa melhoria.
3. Inclua os sistemas de terceiros: Sites hospedados, plataformas SaaS e sistemas contratados também podem usar PHP. Solicite aos fornecedores uma confirmação formal (por e-mail ou chamado) sobre a exposição e a correção, e anexe a resposta ao registro.
4. Se o tratamento já foi feito, mas não foi registrado, registre agora com as datas reais: Reúna o que existe (e-mails, chamados, mensagens, registros de atualização) e documente o que aconteceu, indicando claramente a data em que o registro foi elaborado. Nunca crie registros com datas retroativas: além de ser uma prática inadequada, a inconsistência costuma ser percebida na auditoria e compromete a confiança no SGSI.
5. Se o processo não foi seguido, abra a não conformidade antes do auditor: Prazo descumprido, ativo fora do inventário ou ausência de aprovação são falhas do processo. Identificá-las internamente, investigar a causa e registrar a ação corretiva (cláusula 10.2) demonstra que o SGSI funciona. Uma não conformidade identificada e tratada pela própria empresa tem peso muito diferente de uma encontrada pelo auditor.
6. Organize o dossiê do caso:. Reúna em um único local, ou vincule por um identificador único, o alerta, a avaliação de riscos, o plano de tratamento, a GMUD ou o chamado, a validação técnica e o registro de encerramento. Na auditoria, isso permite responder às cinco perguntas em poucos minutos.

O mínimo esperado para os controles 8.8 e 5.7: a ISO/IEC 27001 pede que a organização obtenha informações sobre vulnerabilidades técnicas dos sistemas em uso, avalie a sua exposição e adote medidas adequadas (8.8), e que colete e analise informações sobre ameaças para produzir inteligência que apoie as decisões (5.7). No caso PHP2Shell, isso significa conseguir demonstrar, no mínimo, que a empresa tomou conhecimento da falha, verificou se era afetada, considerou o que se sabia sobre os ataques em andamento, decidiu o que fazer e confirmou o resultado.

Checklist rápido para gestores

Use o quadro abaixo para uma conversa objetiva com a sua equipe de TI ou com o seu fornecedor. Para cada pergunta, peça para ver a evidência, e não apenas ouvir que ela existe.

Um ponto prático sobre as evidências: As evidências não precisam estar em cinco ou seis documentos separados. Elas podem estar no sistema de chamados, na ferramenta de gestão de riscos, no inventário de ativos, no relatório do scanner ou em um repositório controlado. O que importa é que estejam ligadas por um identificador único do caso, sejam datadas, íntegras e recuperáveis, e que permitam seguir o fio da meada: ativo, risco, decisão, ação e resultado.

Onde isso está na ISO/IEC 27001:2022?

Para quem acompanha o SGSI, o quadro relaciona cada pergunta às cláusulas da norma e aos controles do Anexo A. Os controles aplicáveis dependem da Declaração de Aplicabilidade de cada organização.

Glossário para quem não é da área 

• SGSI: Sistema de Gestão de Segurança da Informação: o conjunto de regras, processos, responsáveis e registros que a ISO 27001 pede que a empresa mantenha.
• Vulnerabilidade: Uma falha em um software ou configuração que pode ser aproveitada por um atacante.
• CVE: Código público e único que identifica uma vulnerabilidade conhecida, como CVE-2026-109618.
• CVSS: Sistema de pontuação que indica a gravidade de uma vulnerabilidade, em uma escala de 0 a 10. As duas falhas do PHP2Shell receberam nota 9,2, considerada crítica.
• Patch (correção): Atualização publicada pelo fabricante para eliminar uma vulnerabilidade.
• Inteligência de ameaças: Coleta e análise de informações sobre ameaças e ataques em andamento (quem está atacando, como e com quais sinais), para orientar decisões de proteção. Corresponde ao controle 5.7 da ISO 27001.
• Inventário de ativos: A lista organizada dos sistemas, servidores, softwares e informações da empresa, com seus responsáveis.
• Risco residual: O risco que ainda permanece depois das medidas adotadas.
• GMUD: Gestão de Mudança: o processo que planeja, aprova e registra qualquer alteração em sistemas em produção.
• Chamado (ticket): Registro em um sistema de atendimento que documenta uma solicitação ou ocorrência do início ao fim.
• Varredura (scan): Verificação automatizada que procura vulnerabilidades conhecidas em sistemas.
• WAF: Firewall de aplicação web: uma barreira que filtra acessos maliciosos antes que cheguem ao site.
• Não conformidade: O não atendimento a um requisito da norma ou do próprio processo da empresa.
• Ação corretiva: Ação que elimina a causa de uma não conformidade para evitar que ela se repita.
• Análise crítica pela direção: Reunião periódica em que a alta direção avalia o desempenho do SGSI e decide sobre melhorias e recursos.

Conclusão

O PHP2Shell mostrou, mais uma vez, que nenhuma empresa está livre de vulnerabilidades. A diferença entre as organizações não está em ter ou não ter falhas, mas em como elas respondem: com um processo definido antes, uma avaliação baseada em critérios, decisões assumidas por quem tem autoridade, verificação de que a correção funcionou e aprendizado ao final.

As cinco perguntas deste artigo podem ser usadas por qualquer gestor, conheça ele ou não a ISO 27001. Se a sua empresa consegue respondê-las com evidências, ela está no controle. Se não consegue, este é o melhor momento para começar, porque a próxima falha crítica é uma questão de quando, e não de se.

A Dédalo Security atua na implementação, manutenção e auditoria de sistemas de gestão de segurança da informação e privacidade (ISO/IEC 27001 e ISO/IEC 27701) e na adequação à LGPD, apoiando empresas de todos os portes a transformar requisitos em rotinas práticas e evidências que resistem a uma auditoria. Para entender como esses temas se conectam, veja também o artigo: ISO 27001, ISO 27701 e LGPD: como construir uma adequação técnica e jurídica em proteção de dados?.

Se a sua empresa é certificada na ISO 27001, fale com o seu consultor, podemos apoiar a revisão dos registros do PHP2Shell antes da próxima auditoria.

Entre em contatoconosco e proteja sua empresa!

Fontes:

• NCSC (Reino Unido): Critical security issue affecting PHP
• Sansec: PHP2Shell, Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)
• Unit 42, Palo Alto Networks: Threat Brief CVE-2026-109618 e CVE-2026-109619
• BigGo Finance: Critical PHP Vulnerability Affects 70% of Websites Worldwide
• ABNT NBR ISO/IEC 27001:2022 e ABNT NBR ISO/IEC 27002:2022

Felipe Nicácio

Marcos Gomes

Consultores na Dédalo Inteligência em Segurança da Informação.