Ir para o conteúdo
Todos os artigos

· por NetProtector Security Team

PHP2Shell: vulnerabilidades críticas do PHP estão a ser ativamente exploradas

Duas vulnerabilidades críticas no núcleo do PHP, designadas em conjunto por „PHP2Shell“, permitem que atacantes executem código em servidores web sem autenticação. Desde 20 de outubro de 2026 existem patches – e já se registam ataques reais (in the wild). Quem opera aplicações PHP deve agir já.

Do que se trata

Estão em causa a CVE-2026-109618 e a CVE-2026-109619, ambas classificadas com 9.2 no CVSS 4.0. Trata-se de falhas de memória no núcleo do PHP, e não numa aplicação ou framework específico:

  • CVE-2026-109618: quando o PHP interrompe um pedido por falta de memória, os dados do pedido ficam apenas parcialmente inicializados. Na limpeza do pedido, são ainda assim tratados como válidos – permitindo a um atacante introduzir memória inválida.
  • CVE-2026-109619: o estado global de um pedido sobrevive à libertação da respetiva memória. Um pedido subsequente no mesmo worker lê-o antes de ser redefinido (use-after-free). Isto permite também ler a memória do worker – incluindo palavras-passe, tokens ou chaves de API que aí se encontrem nesse momento.

Estão em risco todas as instalações que processam pedidos web: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. A facilidade de exploração das vulnerabilidades depende da configuração e da aplicação; um vetor de ataque confirmado passa pela funcionalidade Session Upload Progress.

Porque é urgente

As vulnerabilidades tornaram-se públicas antes do previsto: circularam indícios em fóruns antes da data do patch, e um vídeo com uma prova de conceito foi inadvertidamente publicado antecipadamente. Entretanto, há scripts de exploit publicamente disponíveis, e várias empresas de segurança observam exploração ativa. O PHP é executado numa grande parte de todos os servidores web – os atacantes fazem varrimentos em conformidade, de forma abrangente.

O que deve fazer agora

  1. Atualizar. As versões corrigidas são a 8.5.12, 8.4.27, 8.3.36 e 8.2.35. As distribuições aplicam frequentemente as correções retroativamente (backport) e mantêm o número de versão antigo – o que conta é o aviso de segurança do seu fornecedor. O PHP 8.1 e versões anteriores já não recebem atualizações regulares; neste caso, só um upgrade resolve.
  2. Verificar o que está realmente em execução. php -v na linha de comandos não mostra necessariamente a versão com que o servidor web trabalha. Reinicie o PHP-FPM ou o Apache após a atualização e verifique a versão dos workers em execução.
  3. Proteger provisoriamente, caso não seja possível atualizar de imediato (o projeto PHP sublinha: só a atualização elimina totalmente as vulnerabilidades):
    • Definir session.upload_progress.enabled = 0 no php.ini ou na configuração do pool FPM e reiniciar os workers – através de ini_set() ou .user.ini não é suficiente.
    • No PHP 8.5, definir adicionalmente fatal_error_backtraces = 0.
    • Definir limites de tamanho e de upload restritivos (post_max_size, upload_max_filesize, max_file_uploads) e bloquear pedidos multipart no reverse proxy onde não sejam necessários.
    • Sempre que possível, desligar o serviço da Internet ou filtrá-lo a montante.
  4. Procurar vestígios. Analise os logs do servidor web em busca de pedidos multipart e de upload suspeitos, bem como de falhas de workers PHP desde meados de outubro. Os ataques bem-sucedidos manifestam-se frequentemente através de novos ficheiros no diretório web ou de ligações de saída invulgares do servidor web.

A nossa avaliação

O PHP2Shell é um exemplo paradigmático da rapidez com que se fecha a janela temporal entre a divulgação e a exploração. Uma gestão de patches atualizada continua a ser a medida mais importante. Do lado da rede, a intrusion prevention ajuda a bloquear padrões de ataque conhecidos no perímetro, e a deteção de anomalias assinala quando um servidor web estabelece subitamente ligações que nunca estabeleceu antes – um sinal típico de um comprometimento bem-sucedido.

Fontes