Falha crítica no PHP expõe a maioria dos sites. O que pedir à hospedagem hoje

A maior parte dos sites de empresa no Brasil roda sobre PHP: é a linguagem por trás do WordPress, das lojas em WooCommerce e Magento e de muito sistema feito sob medida. Em 21 de outubro, o próprio projeto PHP publicou um aviso de segurança e versões corrigidas para duas falhas que permitem executar código no servidor sem precisar de login. A recomendação oficial é atualizar imediatamente. Para quem tem um site e não cuida do servidor, a tarefa de hoje é uma só: descobrir em que versão o site está e cobrar a atualização de quem o hospeda.

O que aconteceu

O aviso do PHP diz que as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35 corrigem duas falhas críticas que podem permitir execução remota de código sem autenticação, e que todos os usuários devem atualizar de imediato ^[1]. Estão em risco todas as instalações que atendem requisições web, e o projeto considera o risco maior no Apache com mod_php, em que uma requisição sem login consegue disparar o ataque antes de qualquer código da aplicação rodar ^[1]. A versão 8.1 e as anteriores não recebem mais atualização do projeto; a equipe de segurança publicou correções mínimas em código-fonte para 7.4, 8.0 e 8.1, voltadas a quem compila por conta própria ou não tem um fornecedor de suporte estendido ^[1].

As falhas foram encontradas pela Wiz Research com ajuda de modelos de IA de fronteira, em trabalho conjunto com a equipe do PHP, a Calif e a OpenAI, e receberam o nome PHP2Shell ^[2]. Segundo a Wiz, toda versão de PHP lançada na última década é afetada por pelo menos uma das falhas, desde a 5.4, e os atacantes podem explorá-las remotamente, em alguns casos com relativa facilidade ^[2]. O problema está no motor do PHP, e não no site: a Wiz demonstrou invasão sem login em instalações atuais de WordPress, Drupal e Joomla, e também a leitura da memória do processo, que pode conter senhas, tokens e chaves de API, mesmo sem chegar a executar código ^[2].

O tempo entre a correção e os primeiros ataques foi curto. A Sansec, que investiga invasões de lojas virtuais, registra que a Cloudflare relatou ataques iniciais às 7h43 UTC de 21 de outubro, antes mesmo do lançamento das versões corrigidas, às 14h UTC, e lembra que lojas em Magento, Shopware e WooCommerce ficam expostas mesmo com o código próprio limpo ^[3]. A Patchstack, especializada em WordPress, lista em sua linha do tempo incidentes de exploração ativa relatados por parceiros de hospedagem na manhã do mesmo dia ^[4].

Por que isso importa

Os avisos de segurança que a empresa pequena costuma receber falam de plugin, de tema ou de senha fraca, e ela já aprendeu a cobrar essas atualizações. Desta vez o buraco está uma camada abaixo, no PHP em si, e por isso não adianta o site estar em dia: a Patchstack resume que sites em WordPress, Drupal, Magento, Joomla, Laravel e outras aplicações PHP ficam expostos se rodam uma versão vulnerável do PHP ^[4]. Quem resolve é quem administra o servidor, ou seja, a hospedagem, a agência ou o técnico que cuida da máquina.

O segundo ponto é que não existe remendo completo. O próprio PHP afirma que as medidas provisórias reduzem a exposição a alguns caminhos de ataque, mas não deixam a instalação segura, e que só a atualização resolve ^[1]. A Sansec acrescenta que todo gatilho conhecido é uma requisição do tipo multipart/form-data, o formato que o navegador usa para enviar arquivos, e sugere bloquear esse tipo de requisição no servidor web enquanto a atualização não vem, avisando que a regra quebra o envio de arquivos, como fotos de produto no painel do Magento ^[3].

O terceiro ponto é o papel da IA. A Wiz escreve que as falhas existiam há décadas, mas provar que eram exploráveis exigia uma cadeia de passos no limite do que pesquisadores humanos conseguiam fazer na prática, e que os modelos de IA reduziram bastante essa barreira ^[2]. Vale para quem defende e para quem ataca: a IV Help já tratou aqui de agentes de IA que agem com acesso demais e de chaves de API roubadas, e este caso mostra o outro lado, falhas antigas que passam a ser exploradas mais depressa do que antes.

Para fechar

Esta é uma daquelas semanas em que o site da empresa depende de uma pergunta bem feita a quem cuida do servidor. Quem perguntar hoje, com número de versão e data na resposta, fecha o assunto; quem deixar para depois conta com a sorte.