Hackers já exploravam falhas críticas no PHP antes da correção

Sabe aquela sensação de que, quando você finalmente resolve um problema, descobre que ele já estava te perseguindo há dias? Pois é, aconteceu algo parecido com a segurança de milhões de sites ao redor do mundo nesta semana. Duas falhas críticas no PHP, uma linguagem de programação essencial para a web, acenderam um alerta vermelho para desenvolvedores e administradores.

Eu trago essa notícia porque ela muda um pouco o foco do que a gente costuma ouvir sobre atualizações de segurança. Geralmente, a gente pensa que o perigo surge depois que a falha é descoberta e anunciada, mas o cenário aqui foi bem diferente. Parece que alguns hackers estavam um passo à frente, testando as brechas antes mesmo de qualquer correção ser divulgada.

O que aconteceu

Duas falhas críticas de segurança no PHP, classificadas com gravidade 9,2, foram alvo de tentativas de exploração por hackers antes mesmo de serem corrigidas. De acordo com informações da Wired, os ataques começaram por volta de 17 de outubro, quatro dias antes da divulgação das correções oficiais para o público.

A descoberta dessas atividades suspeitas foi feita pela Amazon Web Services (AWS) por meio de sua rede de servidores-isca, os chamados honeypots. Segundo a AWS, o primeiro registro de ataque partiu de um endereço IP associado a serviços de anonimização, como VPNs ou proxies, o que indica uma possível atividade criminosa organizada.

O volume de ataques cresceu de forma explosiva assim que as vulnerabilidades se tornaram públicas. Segundo o CEO da Cloudflare, Matthew Prince, a empresa viu o número de tentativas saltar de milhares para centenas de milhares de ataques em apenas duas horas após o anúncio. A Reuters também informou que, em pouco tempo, o volume acumulado já chegava aos milhões.

Apesar desse movimento massivo de criminosos, ainda não há confirmação de invasões bem-sucedidas. A PHP Foundation afirmou à Wired que não tem conhecimento de casos onde invasores tenham conseguido executar códigos maliciosos remotamente usando essas falhas específicas. O foco atual é entender como os hackers obtiveram as informações sobre a falha antes do vazamento oficial.

Os pesquisadores notaram que os ataques realizados em diferentes momentos utilizaram códigos maliciosos distintos. Para a equipe de segurança, essa variação sugere que múltiplos grupos ou indivíduos podem estar tentando aproveitar a mesma oportunidade para atacar sistemas que utilizam o PHP.

Entendendo

Para entender a gravidade do que está acontecendo, precisamos falar sobre o que é o PHP. Ele é uma linguagem de programação muito popular, usada para construir a parte lógica de milhões de sites e sistemas na internet. Como muitos sites dependem dele para funcionar, qualquer erro de segurança nessa linguagem acaba se tornando um alvo gigante para criminosos digitais.

Quando falamos em vulnerabilidades como as CVE-2026-109618 e CVE-2026-109619, estamos nos referindo a falhas no código que permitem que alguém faça algo que não deveria. No caso dessas falhas, a classificação de gravidade é altíssima, chegando a 9,2 em uma escala de 10. Isso indica que um invasor poderia, teoricamente, executar comandos maliciosos em um servidor de forma remota.

A notícia também menciona o uso de honeypots, que em tradução livre seria algo como 'potes de mel'. Na segurança digital, esses são servidores propositalmente vulneráveis criados por pesquisadores para atrair hackers. Eles funcionam como armadilhas para monitorar as técnicas dos criminosos e entender como os ataques estão sendo feitos antes que eles atinjam sistemas reais e importantes.

O que me chama atenção nesse caso não é apenas a existência das falhas, mas o fato de que os ataques começaram antes mesmo de o mundo saber que elas existiam.

O que muda para você

Para quem gerencia sites ou contrata serviços de software, a recomendação agora vai além de apenas clicar no botão de atualizar. Segundo a Amazon, é fundamental analisar os registros de atividade dos servidores desde o dia 17 de outubro. Isso porque as tentativas de invasão foram detectadas pela empresa já nessa data, dias antes da correção oficial.

Na prática, isso significa que administradores precisam investigar sinais de comportamento estranho nos sistemas. A AWS sugere procurar por requisições suspeitas, processos que rodam de forma inesperada ou até arquivos que foram alterados sem autorização. O objetivo é descobrir se houve uma invasão bem-sucedida antes de você aplicar a correção do PHP.

É importante entender que a atualização serve para fechar a porta, mas ela não limpa a casa. Se um invasor conseguiu entrar e deixar um código malicioso instalado antes da correção, o software atualizado continuará vulnerável por causa da presença do invasor. Por isso, o monitoramento de segurança deve ser um processo contínuo e não apenas uma reação a avisos.

Para usuários de serviços como o da Cloudflare, existe uma camada extra de proteção, já que a empresa implementou medidas de defesa antes da divulgação oficial. No entanto, essas proteções são temporárias. O conselho geral para qualquer gestor de tecnologia é sempre perguntar aos fornecedores e equipes técnicas sobre o que mudou e como o histórico recente está sendo revisado.

Fonte: Canaltech