PHP2Shell: a falha crítica do PHP e o que fiz pelos activos digitais dos meus clientes.

A 21 de Outubro de 2026 o PHP corrigiu duas falhas críticas, CVE-2026-109618 e CVE-2026-109619, que permitem executar código num servidor sem conta nem palavra-passe. Qualquer site em PHP que receba pedidos da web está exposto até correr a 8.2.35, a 8.3.36, a 8.4.27 ou a 8.5.12. Nos sites que mantenho, a resposta foi um inventário, a versão corrigida fixada no único site em PHP, uma revisão do que estava à volta, a Cloudflare à frente como protecção temporária e uma auditoria de exposição a cada site. O que se segue é essa lista, para a copiar.

Escrevo isto dois dias depois do aviso, com as fontes oficiais ao lado e sem alarmismo: a maior parte dos sites de pequenas empresas em Portugal corre em PHP sem o dono saber, e a única coisa que decide se estão seguros é uma pergunta ao alojamento. Explico o que aconteceu, o que fiz pelos meus activos digitais e pelos dos meus clientes, e o que a lei passou a pedir a quem guarda dados de outros.

O que aconteceu

Duas falhas críticas no PHP, corrigidas a 21 de Outubro

A 21 de Outubro de 2026 o PHP publicou versões de emergência para duas falhas, CVE-2026-109618 e CVE-2026-109619, que a comunidade baptizou de PHP2Shell. As duas têm gravidade 9,2 em 10 e permitem a um atacante executar código no servidor sem precisar de conta nem de palavra-passe. Segundo a agência de cibersegurança dos Estados Unidos, afectam todas as instalações de PHP que servem pedidos da web, seja com PHP-FPM, com o módulo do Apache ou com outros servidores.

As versões corrigidas são a 8.5.12, a 8.4.27, a 8.3.36 e a 8.2.35. O PHP 8.1 e as versões anteriores já não recebem actualizações normais; houve correcções limitadas no código fonte para a 7.4, a 8.0 e a 8.1, mas quem está nessas versões depende do alojamento ou de uma migração. A Rapid7 explica as duas falhas em pormenor: uma corrompe a memória quando um pedido esgota a memória a meio, a outra deixa um processo reutilizar dados de um pedido anterior que já devia ter sido limpo. A 22 de Outubro já circulavam várias provas de conceito públicas e havia relatos de tentativas de exploração, embora nenhuma delas funcione em todas as combinações de sistema e versão. A CERT-EU emitiu um aviso no mesmo dia.

O que fiz

A lista que segui nos sites que mantenho

Mantenho sites meus e de clientes: um escritório de advogados, um gabinete de contabilidade, um salão de beleza, um marketplace de barbearias, uma loja de reparação e várias aplicações em construção. Foi por esta ordem:

• Inventário em meia hora: que sites correm PHP, em que versão e em que alojamento. A resposta foi um só: o site em Laravel de um escritório de advogados, num alojamento gerido. Tudo o resto corre sem PHP, em Cloudflare Pages, Vercel ou Node, e por isso a falha não existe nesses sites. Sem inventário, esta pergunta leva dias; com ele, leva minutos.
• Versão fixada, não prometida por email: esse site passou a exigir uma versão de PHP já corrigida sempre que é reconstruído, para não voltar a instalar uma versão com a falha. O assunto só fica fechado quando vejo a versão instalada com os meus olhos, não quando recebo um "está tratado".
• Revisão do que estava à volta: uma falha grave é uma boa desculpa para olhar para o resto. Nesse site, as peças de software de que a aplicação depende estavam atrasadas e foram actualizadas para as versões correntes, e o código foi revisto à procura de portas que não deviam estar abertas. O que apareceu foi fechado na mesma passagem.
• Modo de depuração desligado: é o primeiro item da lista em qualquer aplicação. Ligado, mostra o interior do site a quem o visita quando há um erro. Tem de estar desligado no alojamento, não só no código.
• Cloudflare à frente de tudo: todos os sites que mantenho passam pela Cloudflare, com TLS estrito, HSTS e cabeçalhos de segurança. Enquanto uma actualização não está em produção, é ali que se limitam os pedidos com envio de ficheiros, a porta de entrada da primeira falha, e se bloqueia tráfego anómalo. Não substitui a actualização; ganha tempo.
• Auditoria de exposição em cada site: desde Outubro uso uma ferramenta que vê o site como um atacante o veria, do lado de fora: chaves esquecidas no código, ficheiros que não deviam estar acessíveis, protecções em falta, cookies e serviços de terceiros. Só audito o que é meu ou de clientes com autorização. O que aparece entra numa lista de correcções com data.
• Acessos: contas de cliente separadas, verificação em dois passos onde a ferramenta a tem, nada de dados de clientes copiados para fora das ferramentas deles sem necessidade, e acessos cancelados no fim de cada contrato. Está escrito na minha política de privacidade porque é um compromisso, não um lembrete.
• Menos dados, menos risco: o site da Wandofi não tem base de dados nem sessões. O teste de diagnóstico guarda só o que pede, numa folha privada, com consentimento; o Google Analytics só carrega depois de o visitante aceitar. O que não se recolhe não se perde.

Nada disto é heróico, e nem tudo entra em produção no mesmo dia: num site de cliente, as alterações passam por um ambiente de teste antes de chegarem ao público, e a pressa é precisamente o que parte sites. O que conta é a lista, com datas, feita antes da falha. Quem não sabe onde corre PHP não consegue sequer começar.

Dados de terceiros

O cuidado que passou a ser obrigatório

Quando um site guarda dados de clientes, de pacientes ou de alunos, o dono do site é responsável por eles perante a lei, mesmo que o alojamento seja de outra empresa e o site tenha sido feito por um terceiro. O RGPD pede medidas de segurança adequadas ao risco, no artigo 32.º, e um contrato com quem trata os dados por conta do responsável, no artigo 28.º. E se houver uma violação de dados com risco para as pessoas, há 72 horas para a comunicar à CNPD, pelo artigo 33.º. Setenta e duas horas é pouco para quem descobre o problema a ler o jornal.

Para quem, como eu, trabalha por dentro das ferramentas dos clientes, a obrigação é a mesma na outra ponta: usar os acessos só para o trabalho contratado, guardar o mínimo, avisar o cliente se detectar uma fuga, e deixar escrito quem acedeu a quê. Numa semana como esta, o cliente tem de poder perguntar "o meu site está seguro?" e receber uma resposta com versão, data e nome de quem confirmou.

A segurança de um negócio pequeno não se compra num dia de pânico. Faz parte da infraestrutura, como a facturação ou a contabilidade, e é por isso que entra em todos os projectos que faço, do site às automações. Se quiser saber onde está o seu, o diagnóstico começa por aí.