PHP2Shell, Windows e VPNs: cinco lições de GRC que as falhas globais deixam

1. Inventário vem antes da correção

Diante do PHP2Shell, a primeira pergunta não foi técnica: “nós usamos PHP?”. Muita empresa não sabe responder. O PHP está no WordPress do site, na loja virtual, naquele sistema web antigo — e até na interface de firewalls como pfSense e OPNsense. Sem um inventário de ativos e de softwares, incluindo os que o fornecedor administra, não há como saber se a empresa está exposta.

A ISO/IEC 27001 trata disso no controle 5.9 (inventário de informações e outros ativos associados). Na prática, basta começar pelo que está exposto na internet: site, loja, e-mail, VPN, firewall, acesso remoto.

2. Prioridade é exploração e exposição — não só a nota

Entre 30 de setembro e 23 de outubro, a CISA, agência de cibersegurança dos EUA, incluiu 27 falhas no seu catálogo de vulnerabilidades exploradas. Só no pacote de 13 de outubro, a Microsoft corrigiu 1.411. Ninguém corrige tudo ao mesmo tempo — e a nota CVSS sozinha não diz o que vem primeiro.

A diretiva BOD 26-04, que a CISA publicou em junho para os órgãos federais americanos, dá um critério útil para qualquer empresa: três dias para falhas já exploradas em sistemas expostos na internet quando o ataque pode ser automatizado ou dá controle total do sistema; prazos de 14 ou 60 dias para o que oferece menos risco. Para uma PME, a tradução é uma política curta de prazos por risco — e o controle 8.8 da ISO 27001 (gestão de vulnerabilidades técnicas) é o lugar para registrá-la.

3. O seu prazo de correção é o prazo do fornecedor

A maioria das PMEs não atualiza o PHP pessoalmente: quem faz isso é a hospedagem, a agência ou o prestador de TI. Se o contrato não diz em quanto tempo uma falha crítica é corrigida — e como a empresa fica sabendo —, o prazo que vale é o do fornecedor, não o seu.

Prazo de correção, aviso e evidência no contrato é gestão de terceiros na prática. Falamos disso em “Ataque à cadeia de suprimentos”.

4. Fim de suporte é um risco com data marcada

O PHP 8.1 e as versões anteriores não têm versão corrigida. O Windows 11 24H2 Home e Pro recebeu a última atualização em 13 de outubro. O PHP 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. Nada disso é surpresa: as datas são públicas há anos.

Colocar as datas de fim de suporte no registro de riscos transforma a surpresa em migração planejada — e em orçamento aprovado com antecedência, não às pressas.

5. Paliativo é decisão de risco — com dono e prazo

Quando não dá para corrigir na hora, entram medidas parciais: firewall de aplicação web, desligar uma opção, tirar o sistema da internet. No caso do PHP, os próprios desenvolvedores avisaram que só a atualização resolve. As medidas parciais são legítimas — desde que alguém aceite formalmente o risco que sobra, com nome, justificativa e data para a correção definitiva.

Sem esse registro, o paliativo vira permanente, e ninguém lembra por quê.

O fio comum: conseguir provar

As cinco lições terminam no mesmo lugar: evidência. Clientes que mandam questionários, seguradoras e a ANPD querem ver o inventário, a política de prazos e o registro de cada correção. A LGPD manda considerar, no cálculo de sanções, a adoção reiterada e demonstrada de mecanismos internos capazes de minimizar danos (art. 52, § 1º, VIII). O que a empresa não consegue mostrar, na prática, não conta.