Em 20 e 21 de outubro de 2026, o mundo da tecnologia acordou com um alerta incomum. Foram identificadas duas falhas críticas no próprio núcleo do PHP, batizadas pela comunidade de PHP2Shell, que possibilitam que um atacante execute código remotamente em servidores web sem precisar de login. Como o PHP está por trás de cerca de 70% dos sites cuja linguagem de servidor é conhecida, incluindo WordPress, MediaWiki e muitas lojas virtuais, o problema passou a ser de praticamente todas as empresas com presença na internet.

Este artigo explica o que é a falha, como ela veio a público e, principalmente, o que ela ensina. As organizações que já operam um Sistema de Gestão de Segurança da Informação (SGSI) baseado na ISO/IEC 27001:2022 não ficaram imunes, mas sabem onde o PHP roda, quem decide o que fazer e em quanto tempo conseguem corrigir. Essa diferença, em um incidente de escala mundial, vale horas, e horas, neste caso, valem muito.

O que é a falha PHP2Shell?

PHP2Shell é o nome dado ao par de vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas classificadas como críticas, com nota 9,2 de 10 no CVSS v4.0. As duas permitem execução remota de código (RCE) por um atacante não autenticado, ou seja, alguém que não tem nenhuma conta no sistema pode, com requisições preparadas, assumir o controle do servidor.

De forma simplificada, o problema está na maneira como o PHP lida com situações de falta de memória e de erro fatal durante o processamento de uma requisição:

Três pontos tornam o caso especialmente grave:

• Está no núcleo da linguagem. Não é um plugin ou um CMS específico. A falha está no próprio PHP, então afeta qualquer aplicação que rode sobre ele, nos dois modos mais comuns de execução (mod_php e PHP-FPM).

• Atinge praticamente todas as versões. Segundo os pesquisadores, qualquer servidor com PHP 5.4.0 ou posterior pode estar vulnerável. As correções oficiais saíram apenas para as versões suportadas: 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

• Versões antigas ficaram sem remédio. PHP 5 e PHP 7 já estão fora de suporte e não receberão correção oficial. O PHP 8.2 deixa de ser suportado em 31 de dezembro de 2026.

Como aconteceu a falha PHP2Shell?

A falha foi tratada em divulgação coordenada por quase três meses, mas os detalhes vazaram um dia antes da correção e os ataques começaram antes do patch. É esse descompasso que transformou um problema técnico em uma corrida mundial.

A raiz técnica não é nova. A classe de problema ligada ao limite de memória do PHP é conhecida desde 2004, e, em 2026, três equipes diferentes conseguiram, de forma independente, transformá-la em exploração funcional. Ao mesmo tempo, fornecedores como Cloudflare e Akamai registraram varreduras automatizadas em escala mundial procurando servidores vulneráveis.

A lição de processo é que entre o vazamento e a correção oficial houve uma janela de quase 24 horas em que a única defesa era controle compensatório (bloqueio na borda, WAF, redução de exposição). Quem não sabia quais servidores rodavam PHP, não conseguiu nem começar.

Por que o impacto da falha é mundial?

A Palo Alto Networks identificou mais de 22,6 milhões de instâncias expostas potencialmente vulneráveis já no dia da divulgação. O número reflete três características do PHP que se aplicam a empresas de qualquer porte:

• Onipresença: Sites institucionais, lojas virtuais, portais de clientes, intranets, ERPs e sistemas legados usam PHP, muitas vezes sem que a área de negócio saiba disso.

• PHP “escondido”: A linguagem vem embarcada em produtos de terceiros: appliances, painéis de hospedagem, ferramentas de monitoramento e soluções SaaS. O centro nacional de cibersegurança da Holanda (NCSC-NL) chegou a publicar uma lista de produtos com dependência de PHP potencialmente afetados.

• Terceirização: Muitas empresas não administram o próprio servidor: dependem de agência, hospedagem ou fornecedor de software. A vulnerabilidade é da empresa, mas a correção está na mão de outra pessoa.

Como alertaram especialistas, uma execução remota de código é a porta de entrada típica para instalação de webshells, roubo de dados, movimentação lateral na rede e, no fim da cadeia, ransomware. Para quem trata dados pessoais, isso também significa possível incidente com obrigação de comunicação à ANPD e aos titulares, nos termos da LGPD.

Como as empresas poderiam ter se prevenido?

Nenhum controle impede que uma linguagem tenha uma falha desconhecida (um zero-day). O que a ISO 27001 faz é garantir que, quando a falha aparece, a empresa já tenha a base pronta: saber o que tem, reduzir a superfície de ataque, detectar abuso e reagir rápido. A tabela abaixo relaciona os controles do Anexo A da ISO/IEC 27001:2022 (detalhados na ISO/IEC 27002:2022) ao cenário PHP2Shell.

Os controles só funcionam porque estão amarrados às cláusulas da norma. A avaliação de riscos (6.1.2) é o que coloca “servidores web expostos com software de terceiros” na lista de riscos relevantes. O tratamento de riscos (6.1.3) e a Declaração de Aplicabilidade são o que transformam esse risco nos controles acima. E a auditoria interna (9.2) e a análise crítica pela direção (9.3) são o que garantem que o inventário e o processo de patch existam de verdade, e não apenas no papel.

O que fazer agora: Correção ligada aos controles

Com a falha já pública e explorada, a prioridade é atualizar o PHP e verificar se houve comprometimento. As ações abaixo seguem as recomendações das autoridades de cibersegurança e de pesquisadores, organizadas em fases e relacionadas aos controles da ISO 27001:

Nas primeiras horas: conter

1. Acionar o processo de resposta a incidentes e tratar o caso como evento de segurança, com responsável e registro desde o início. Controles 5.24, 5.25 e 6.8.

2. Levantar todos os ativos com PHP, priorizando os expostos à internet. Não procure só versões antigas: todas podem estar afetadas. Inclua appliances, painéis e softwares de terceiros que trazem PHP embarcado. Controle 5.9.

3. Atualizar para as versões corrigidas (8.5.12, 8.4.27, 8.3.36 ou 8.2.35), usando o fluxo de mudança emergencial. Controles 8.8 e 8.32.

4. Onde não for possível atualizar de imediato, aplicar controles compensatórios: regras de WAF na borda, bloqueio temporário de envios do tipo upload de arquivos (multipart/form-data) onde a aplicação permitir, e os ajustes de configuração temporários indicados no aviso oficial do PHP. Controles 8.9, 8.20 e 8.26.

5. Se nada disso for viável a tempo, tirar o sistema do ar ou colocá-lo em modo somente leitura. É uma decisão de negócio, e deve ser tomada por quem tem autoridade para isso. Controles 5.29 e 5.30.

Nos primeiros dias: investigar e erradicar

6. Procurar sinais de comprometimento, especialmente para sistemas que ficaram expostos entre 20 e 21 de outubro: webshells, arquivos PHP novos em pastas de upload, contas criadas, tarefas agendadas e conexões de saída incomuns. Controles 8.15, 8.16 e 8.7.

7. Preservar evidências (logs, imagens de disco) antes de limpar ou reinstalar. Controle 5.28.

8. Em caso de comprometimento, reconstruir a partir de fonte confiável e restaurar dados de backup íntegro, trocando senhas, chaves e tokens que estavam no servidor. Controles 8.13, 5.17 e 8.24.

9. Cobrar fornecedores (hospedagem, agência, fabricantes de produtos com PHP embarcado) por evidência de correção e por comunicação de qualquer incidente. Controles 5.19 a 5.22.

10. Avaliar a LGPD: se houve acesso indevido a dados pessoais com risco ou dano relevante aos titulares, comunicar a ANPD e os titulares no prazo regulamentar. Controles 5.31 e 5.34.

Nas próximas semanas: aprender e melhorar

11. Eliminar versões sem suporte. PHP 5 e 7 não terão correção, e o PHP 8.2 sai de suporte no fim de 2026; o risco de mantê-los deve ser tratado ou formalmente aceito pela direção. Controle 8.8 e cláusula 6.1.3.

12. Rever a avaliação de riscos incluindo dependências de software de terceiros e de fornecedores. Cláusulas 6.1.2 e 8.2.

13. Registrar lições aprendidas e abrir ações corretivas: o inventário estava completo? O alerta chegou a tempo? O patch levou quanto tempo? Controle 5.27 e cláusula 10.2.

14. Levar o caso à análise crítica pela direção, com indicadores como tempo de detecção, tempo de correção e percentual de ativos atualizados. Cláusulas 9.1 e 9.3.

A importância da ISO 27001 para empresas de todos os portes

O PHP2Shell demonstra a importância da ISO 27001 para empresas de todos os portes. A norma não prescreve ferramentas caras, mas estabelece que a organização conheça seus riscos e escolha controles proporcionais a eles. O mesmo princípio se aplica a uma loja virtual com cinco funcionários e a um banco.

A norma é especialmente útil em cenários de incerteza por quatro motivos:

• Ela é baseada em risco, não em lista de ameaças. Ninguém sabia do PHP2Shell em setembro, mas o risco “software exposto à internet com vulnerabilidade crítica” já estava na avaliação de quem tem um SGSI. A ameaça específica é nova; a resposta, não.

• Ela define antes quem decide. Em uma crise, a pergunta mais cara é “quem autoriza tirar o site do ar?”. Com papéis e responsabilidades definidos (cláusula 5.3 e controle 5.24), a decisão leva minutos.

• Ela integra segurança, continuidade e conformidade. O mesmo sistema de gestão trata o patch, a operação em modo reduzido e a avaliação de comunicação à ANPD. Para quem trata dados pessoais, a ISO/IEC 27701 aproxima ainda mais das exigências da LGPD.

• Ela aprende com cada incidente. O ciclo de monitoramento, auditoria, análise crítica e melhoria contínua (cláusulas 9 e 10) faz com que o próximo incidente encontre a empresa mais preparada do que o anterior.

Por fim, a certificação ISO 27001 também gera confiança no mercado: em um momento como este, clientes e parceiros querem saber se o fornecedor tem processo para responder, e o certificado é a evidência independente de que tem.

Como preparar sua empresa para responder a incidentes de segurança?

O PHP2Shell não será a última falha crítica em uma tecnologia utilizada por grande parte dos sites na internet. Incidentes como este podem afetar empresas de qualquer porte ou segmento, e a diferença está na preparação antes do alerta. Inventário, processo de correção, monitoramento, contratos com fornecedores e uma equipe que saiba como agir, são algumas das ações que devem ser tomadas.

É exatamente isso que a ISO 27001 organiza. A norma estabelece processos para que a segurança da informação faça parte da gestão da empresa e, diante de uma nova vulnerabilidade, seja possível identificar os riscos e agir com rapidez.

A Dédalo Security atua na implementação da ISO 27001 e na preparação de empresas para a certificação. Entre em contato com um consultor 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 sobre CVE-2026-109618 e CVE-2026-109619

• Techzine Global: Serious vulnerabilities in PHP, emergency patches on the way

• BigGo Finance: Critical PHP Vulnerability Affects 70% of Websites Worldwide

• Yahoo Tech: What to know about critical PHP vulnerability threatening Internet

• Forbes: Critical PHP Security Warning Issued, Apply Emergency Patch Today

• ABNT NBR ISO/IEC 27001:2022 e ABNT NBR ISO/IEC 27002:2022