Servidor PHP com 2000 dólares em bitcoin como isco caiu em 19 horas com o PHP2Shell

Um servidor com uma cópia do PHP sem as atualizações de segurança, deixado online com uma chave de carteira de bitcoin como isco, não durou um dia. Um investigador que usa o pseudónimo KillaBoi entrou através do PHP2Shell, o conjunto de duas vulnerabilidades críticas na linguagem que está na base de grande parte da Web, e extraiu a chave. No mesmo fim de semana, um honeypot gerido por um responsável de segurança da Perplexity registou um atacante a fazer o mesmo num servidor real, pondo fim à confortável teoria de que estas falhas eram demasiado complicadas para alguém as explorar.

Isto é relevante para quem gere um site e para quem tem dados alojados num. O PHP está na base do WordPress, do Drupal, do Joomla e da maioria dos serviços de alojamento partilhado, e estas falhas podem permitir que alguém sem conta execute comandos no servidor. Desde que foram disponibilizadas as correções, o principal argumento para adiar a atualização era o facto de as tentativas de ataque conhecidas continuarem a falhar. Os dois resultados deitam por terra esse argumento.

O desafio, chamado Steal My Bitcoin, foi lançado no seu próprio site e anunciado numa publicação num fórum. O criador, que escreveu com o nome cloudlandsdev, publicou: «Fiz isto porque tenho curiosidade em saber se alguém por aí descobriu como usar realmente esta RCE do PHP; passámos os últimos dias em pânico. Divirtam-se!» O prémio começou nos cerca de 502 dólares e cresceu com donativos até aos 0,02511679 BTC, equivalentes a 2.021,22 dólares quando foi reclamado, cerca de 19 horas após o lançamento, segundo a Tom’s Hardware. O servidor cedeu perante o tráfego de quem tentava participar, e o espaço de armazenamento limitado não permitiu guardar todos os registos.

KillaBoi publicou depois uma prova de conceito no GitHub. Mark Maunder, fundador da empresa de segurança Wordfence, especializada em WordPress, considerou a explicação «a melhor de todas as que vais encontrar sobre a dificuldade de explorar o #php2shell», destacando o trabalho minucioso exigido pelo ataque. Afinal, ser difícil não significava que demorasse muito.

O resultado mais preocupante surgiu fora do desafio. Adel Karimi, responsável pela deteção e resposta na Perplexity, afirmou que os seus honeypots detetaram uma execução remota de código confirmada num servidor Apache com PHP 8.4.26. «Está agora confirmada uma RCE com divulgação de memória utilizável, não apenas uma falha seguida de um processo suspeito», escreveu, segundo a BleepingComputer. Marcus Hutchins, investigador de ameaças da Expel, que acompanhava as alegações de ataques bem-sucedidos, classificou-a como «de longe a confirmação de maior qualidade de exploração do php2shell no mundo real que vi até agora». Até então, a Cloudflare, a watchTowr, a Patchstack e outras empresas de segurança só tinham registado tentativas falhadas, enquanto a equipa de informações sobre ameaças da Amazon detetara o início da atividade de pesquisa quatro dias antes da publicação das correções.

Nenhum dos resultados significa que todos os servidores sem atualização vão ser comprometidos amanhã. A chave recuperada por KillaBoi não correspondia ao endereço da carteira anunciado pelo site; o organizador atribuiu o problema a um erro de configuração e afirmou que os fundos seriam transferidos, segundo a Cointelegraph. Além disso, o site de segurança Cyberpress observa que as provas públicas mostram que uma chave foi obtida, não que o prémio tenha sido roubado. A exploração publicada também está preparada para uma compilação específica do PHP e falha noutras compilações da mesma versão, pelo que não é uma ferramenta de apontar e clicar. O que deixou de ser possível alegar é que ninguém conseguiu fazê-la funcionar.

A exposição é global. Agências governamentais dos Países Baixos, da Austrália, do Japão e da Finlândia retiraram de funcionamento sites críticos enquanto preparavam as correções, noticiou a Cointelegraph. Uma contagem do Shodan feita pela empresa de segurança Mallory encontrou cerca de 884.000 servidores acessíveis pela Internet que anunciavam uma versão do PHP sem atualizações oficiais, 59% dos cerca de 1,5 milhões que revelam uma versão, segundo a Notebookcheck. São contagens baseadas nos banners, não vítimas confirmadas, uma vez que as distribuições Linux aplicam frequentemente correções a pacotes antigos sem alterar o número da versão.

Para quem gere sites, a solução continua a ser a mesma. As versões corrigidas são a PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, publicadas a 21 de outubro para as vulnerabilidades CVE-2026-109618 e CVE-2026-109619, ambas classificadas com 9,2 em 10. No alojamento partilhado, a atualização é da responsabilidade do fornecedor, não resulta de uma atualização do WordPress ou de um plug-in. Por isso, a pergunta útil a fazer ao fornecedor é que compilação do PHP o site utiliza e quando foi corrigida. A agência norte-americana de cibersegurança CISA recomendou às organizações que não conseguem atualizar, ou que ainda utilizam o PHP 8.1 ou uma versão anterior, que retirem esses sistemas de funcionamento até o poderem fazer.

O próximo problema já está em cima da mesa. Na sexta-feira, a equipa do PHP publicou uma solução temporária para uma terceira falha de execução remota de código, a CVE-2026-115560, que ainda não tem correção e só afeta sistemas «com uma combinação invulgar de configuração e código da aplicação». Até ser disponibilizada uma correção, os programadores do PHP recomendam desativar a opção session.upload_progress, a mesma medida que aconselharam antes das correções do PHP2Shell. O suporte de segurança do PHP 8.2 termina a 31 de dezembro de 2026, e os servidores que nunca abandonaram o PHP 8.1 já ultrapassaram o fim do respetivo suporte.

Etiquetas: cibersegurança, bitcoin, Perplexity, PHP, PHP2Shell, WordPress