O que é o PHP2Shell? Compreender os riscos de execução remota de código e a segurança das contas de criptomoedas

PHP2Shell é um tema de segurança recentemente analisado que envolve o risco de execução remota de código em servidores PHP. Refere-se principalmente à exploração, por parte de atacantes, de ambientes de execução PHP vulneráveis ou de componentes de aplicações relacionados, para executar código no lado do servidor sem autorização. O PHP é amplamente utilizado em websites, sistemas de gestão de conteúdos e vários serviços de backend. Consequentemente, quando as vulnerabilidades relacionadas afetam serviços expostos à Internet, podem também ameaçar a segurança dos dados dos utilizadores, da autenticação de identidade e dos sistemas empresariais.

Para o setor das criptomoedas, os riscos das vulnerabilidades em PHP não se limitam aos websites tradicionais. As plataformas de negociação de criptomoedas, os websites de projetos, os serviços relacionados com carteiras e as aplicações Web3 também dependem de servidores, bases de dados e API para fornecer gestão de contas, dados de mercado e interações de negociação. Se estes sistemas contiverem falhas de segurança graves, os atacantes podem obter acesso a credenciais sensíveis ou manipular interações dos utilizadores através de uma intrusão num serviço Web, ampliando o potencial impacto do incidente de segurança.

No entanto, os riscos de segurança dos servidores e a segurança dos protocolos de blockchain não são a mesma coisa. Uma vulnerabilidade em PHP não quebra automaticamente as chaves privadas das carteiras, e um servidor comprometido, por si só, não é suficiente para determinar que os ativos dos utilizadores foram roubados. Este artigo começa pelos conceitos básicos de PHP2Shell e explica os princípios técnicos da execução remota de código, as vias potenciais através das quais as vulnerabilidades podem afetar contas de criptomoedas e a forma como plataformas, programadores e utilizadores comuns podem estabelecer proteções de segurança mais eficazes.

Pontos principais

• PHP2Shell é uma designação recentemente analisada associada a riscos de segurança de execução remota de código em PHP. A questão central é que os atacantes podem executar código não autorizado através de ambientes do lado do servidor vulneráveis.

• A execução remota de código (RCE) difere das vulnerabilidades Web comuns. Em casos graves, pode afetar privilégios do servidor, o acesso a bases de dados e a lógica empresarial de backend.

• Um servidor PHP comprometido não significa que a rede blockchain ou as chaves privadas dos utilizadores tenham sido quebradas. O facto de os ativos de criptomoedas serem afetados depende das relações de permissões entre o servidor e os sistemas de autenticação de contas, assinatura de transações e custódia de ativos.

• Para plataformas de negociação centralizadas, os riscos potenciais podem envolver sessões de utilizadores, credenciais de API, dados de contas e interfaces empresariais. No caso de carteiras sem custódia, os utilizadores devem estar especialmente atentos a páginas Web maliciosas, interações de phishing e assinaturas de transações perigosas.

• Instalar prontamente correções de segurança, restringir as permissões do servidor, isolar credenciais sensíveis, ativar a autenticação multifator e verificar de forma independente as assinaturas das transações são medidas importantes para reduzir os riscos associados.

O que é a vulnerabilidade PHP2Shell? Porque é uma questão de segurança crítica?

PHP2Shell não é uma única função PHP nem um plugin de terceiros. É um termo coletivo para duas vulnerabilidades de segurança no núcleo do PHP: CVE-2026-109618 e CVE-2026-109619. As duas vulnerabilidades foram divulgadas em 21 de outubro de 2026. Ambas envolvem potenciais problemas de segurança na forma como o PHP processa pedidos excecionais e estados de memória, tendo ambas recebido uma classificação CVSS v4.0 de 9,2, o que as coloca na categoria de gravidade crítica.

Ao contrário das vulnerabilidades tradicionais em aplicações PHP, o PHP2Shell ocorre no ambiente de execução do PHP. Isto significa que, mesmo que os programadores de websites tenham aplicado filtragem padrão das entradas dos utilizadores e a própria aplicação não tenha falhas evidentes de injeção SQL ou de carregamento de ficheiros, os componentes PHP subjacentes podem continuar expostos a ataques devido às vulnerabilidades.

O principal perigo do PHP2Shell é que os atacantes podem não precisar de iniciar sessão antecipadamente no website visado. Podem ter a oportunidade de desencadear operações de memória anormais através de pedidos especialmente concebidos e, posteriormente, alcançar a execução remota de código. As condições reais de exploração dependem da versão do PHP, do modo de funcionamento do servidor e da configuração de implementação. Nem todos os websites PHP têm exatamente a mesma superfície de ataque.

O PHP lançou oficialmente versões corrigidas e recomenda claramente que os utilizadores afetados atualizem assim que possível.

Como é que o PHP2Shell desencadeia a execução remota de código?

Para compreender os riscos do PHP2Shell, é necessário primeiro compreender como os servidores PHP processam os pedidos dos utilizadores.

Quando um utilizador visita um website, submete um formulário ou chama uma API, o servidor Web transmite o pedido relevante ao ambiente de execução PHP para processamento. O PHP analisa os dados do pedido, executa o código da aplicação e devolve o resultado ao utilizador. Durante este processo, o servidor tem de alocar memória, preservar o estado do pedido e libertar os recursos relacionados após o fim do pedido.

Em circunstâncias normais, o PHP deve limpar em segurança os recursos alocados, mesmo quando o processamento do pedido falha. No entanto, as duas vulnerabilidades associadas ao PHP2Shell ocorrem precisamente durante o tratamento de exceções e a limpeza da memória.

A CVE-2026-109618 está relacionada com o tratamento de falta de memória. Quando ocorre uma falha de alocação de memória enquanto o PHP analisa um pedido, alguns dados internos podem ainda não ter sido totalmente inicializados. Se uma rotina de limpeza subsequente tratar incorretamente estes dados como um estado válido, pode ocorrer corrupção de memória.

A CVE-2026-109619 envolve referências de memória inválidas durante o processamento de pedidos. Quando determinados recursos já foram libertados, mas os ponteiros ou estados relacionados são mantidos, operações subsequentes podem aceder incorretamente a regiões de memória que já não são válidas. Este tipo de problema é habitualmente conhecido como use-after-free.

Quando se verificam condições específicas de exploração, os atacantes podem utilizar estes erros de memória para alterar o fluxo normal de execução do programa e fazer com que o servidor execute código não autorizado. Os privilégios de execução são geralmente limitados pelas permissões da conta do processo de trabalho PHP. Contudo, se as permissões do servidor estiverem configuradas incorretamente, os atacantes podem ainda aceder a ficheiros sensíveis ou tentar expandir o seu controlo.

É importante salientar que os riscos reais variam entre os modos de implementação. Por exemplo, foram validadas algumas vias de exploração que envolvem Apache mod_php, enquanto as condições de desencadeamento e a possibilidade de exploração noutros ambientes, como o PHP-FPM, não são exatamente as mesmas.

Que versões de PHP e ambientes de servidor são afetados pelo PHP2Shell?

O PHP2Shell afeta várias versões de PHP ainda em utilização. Em 21 de outubro de 2026, o PHP lançou as atualizações de segurança correspondentes para corrigir as duas vulnerabilidades críticas.

Em 27 de outubro de 2026, as principais versões afetadas e corrigidas são as seguintes:

As versões mais antigas de PHP também podem ser afetadas por problemas relacionados. Para versões que já não têm manutenção oficial, os programadores devem confirmar se os distribuidores do sistema operativo ou os serviços de manutenção comercial fornecem correções de segurança, em vez de se basearem apenas nos números das versões para avaliar o risco.

Além disso, algumas distribuições Linux podem corrigir vulnerabilidades através de retroportações de correções de segurança, aplicando a correção enquanto mantêm o número da versão original. Por conseguinte, determinar se um servidor é seguro exige verificar tanto a versão real de compilação do pacote como os avisos de segurança do fornecedor.

Em termos de métodos de implementação, o PHP2Shell pode envolver Apache mod_php, PHP-FPM, php-cgi, FrankenPHP e outros ambientes de execução PHP. No entanto, as condições de exploração diferem entre os vários modos. Os administradores de servidores devem avaliar o impacto com base na sua própria pilha tecnológica, em vez de assumirem que todos os websites que utilizam PHP podem ser comprometidos através do mesmo método de ataque.

Porque pode o PHP2Shell ameaçar a segurança das contas de negociação de criptomoedas?

As plataformas de negociação de criptomoedas são normalmente compostas por vários sistemas independentes, incluindo início de sessão de utilizadores, verificação de identidade, correspondência de negociações, gestão de contas, custódia de ativos, aprovação de levantamentos e controlo de riscos.

O PHP2Shell afeta diretamente servidores PHP vulneráveis, e não a própria rede blockchain. Se o website público ou o serviço de backend de uma plataforma utilizar uma versão afetada de PHP, os atacantes podem tentar aceder ao servidor relacionado através da vulnerabilidade.

Depois de um servidor ser comprometido, os atacantes podem procurar informações de ligação a bases de dados, dados de sessão de utilizadores, credenciais de API ou outras configurações sensíveis. Se estas informações fornecerem acesso a um sistema de gestão de contas, podem aumentar o risco de divulgação de informações da conta ou de usurpação de identidade.

Por exemplo, uma plataforma de serviços de criptomoedas pode utilizar PHP para desenvolver interfaces de gestão de contas e armazenar no seu servidor credenciais de API internas com privilégios elevados. Se um atacante obtiver acesso ao servidor através de execução remota de código, pode tentar ler estas credenciais e utilizá-las para chamar interfaces empresariais que não deveriam estar acessíveis publicamente.

Contudo, isto não significa que os atacantes possam levantar diretamente todos os ativos dos utilizadores. As plataformas de negociação maduras geralmente isolam capacidades críticas, como a custódia de fundos, a assinatura de transações, a aprovação de levantamentos e a autenticação de contas, dos serviços Web públicos. Também utilizam controlos de permissões independentes e verificação de riscos.

Por conseguinte, o impacto real do PHP2Shell nas contas de criptomoedas depende das permissões do servidor, do isolamento da rede interna, da gestão de credenciais sensíveis e dos mecanismos de aprovação das operações sobre ativos. Uma vulnerabilidade num website público não significa que o sistema central de custódia de ativos já tenha sido comprometido.

O PHP2Shell expõe diretamente as chaves privadas das carteiras Web3?

O próprio PHP2Shell não consegue quebrar diretamente as chaves privadas de carteiras blockchain nem alterar os mecanismos de segurança criptográfica de uma blockchain.

No caso de carteiras sem custódia como a MetaMask, as chaves privadas são geralmente geridas por software de carteira local ou dispositivos de hardware. Se uma chave privada nunca tiver sido carregada para um servidor PHP vulnerável, a execução remota de código nesse servidor, por si só, geralmente não consegue obter diretamente a chave privada.

No entanto, uma violação do servidor pode ainda afetar os utilizadores de carteiras de outras formas.

Por exemplo, depois de obter controlo sobre o website oficial de um projeto Web3, um atacante pode modificar a página de frontend para orientar os utilizadores a ligarem as suas carteiras e assinarem transações maliciosas. Se os utilizadores não verificarem cuidadosamente os detalhes da transação, podem autorizar inadvertidamente transferências de tokens ou executar operações perigosas.

Outro risco envolve serviços relacionados com carteiras. Algumas aplicações Web3 dependem de servidores para fornecer dados de transações, pedidos de assinatura, configurações de utilizadores ou informações sobre operações entre cadeias. Se estes dados forem alterados após uma violação do servidor, os utilizadores podem receber parâmetros de transação incorretos ou pedidos de interação maliciosos.

Por conseguinte, é necessário distinguir entre dois tipos de questões de segurança:

A exposição de uma chave privada significa que um atacante obtém diretamente o material de chave necessário para controlar os ativos da carteira. A assinatura maliciosa pode ocorrer sem exposição da chave privada, quando um utilizador aprova ativamente uma transação com permissões perigosas.

Para os utilizadores de carteiras sem custódia, este último é frequentemente o risco indireto mais importante a ter em conta.

Em que difere o PHP2Shell das vulnerabilidades Web tradicionais?

O PHP2Shell, a injeção SQL, o cross-site scripting (XSS) e as vulnerabilidades de carregamento de ficheiros podem todos ameaçar a segurança de websites, mas as suas raízes técnicas e métodos de ataque diferem significativamente.

A injeção SQL ocorre normalmente quando uma aplicação não processa corretamente os parâmetros de consulta da base de dados. Os atacantes podem utilizar entradas maliciosas para alterar a lógica das consultas à base de dados. O XSS envolve principalmente o processamento inadequado da saída de páginas Web, o que pode fazer com que scripts maliciosos sejam executados no navegador de um utilizador.

O que distingue o PHP2Shell é que a vulnerabilidade ocorre no ambiente de execução central do PHP. Mesmo que uma aplicação utilize filtragem de entradas e verificação de permissões relativamente abrangentes, as falhas de segurança da memória nos componentes subjacentes podem continuar a fornecer um ponto de entrada para ataques.

Isto também demonstra que a segurança dos websites não pode depender apenas da revisão de código ao nível da aplicação. Os ambientes de execução do servidor, as dependências e as configurações do sistema também exigem manutenção contínua.

Como devem as plataformas de negociação de criptomoedas e os projetos Web3 proteger-se contra o PHP2Shell?

Para plataformas de criptomoedas e projetos Web3 que utilizam PHP, a principal medida para prevenir o PHP2Shell consiste em instalar prontamente as correções de segurança oficiais e confirmar que todos os serviços PHP atualmente em funcionamento foram atualizados.

Como as vulnerabilidades ocorrem no ambiente de execução central do PHP, limitar-se a modificar o código empresarial do website, adicionar filtragem de entradas ou implementar regras de firewall comuns não pode ser considerado uma correção completa. O PHP indicou claramente que a atualização para uma versão corrigida é a solução fiável. Além de atualizar as versões, as plataformas devem concentrar-se nas seguintes áreas.

1. Realizar uma revisão abrangente dos serviços PHP. Além dos websites públicos, devem ser verificados os backends administrativos, as API internas, os ambientes de teste, os projetos legados e os componentes de terceiros. Alguns serviços com menor manutenção podem continuar a executar versões mais antigas de PHP e tornar-se pontos de entrada na rede interna.

2. Implementar o princípio do menor privilégio. Os processos de trabalho PHP não devem ter privilégios desnecessários de administrador do sistema nem acesso direto a chaves privadas de carteiras, sistemas de assinatura centrais ou contas de bases de dados com privilégios elevados. Mesmo que um atacante obtenha acesso a um serviço Web, os recursos a que pode aceder devem permanecer restritos.

3. Isolar sistemas críticos de operação de ativos. Os serviços de contas, a custódia de fundos, a aprovação de levantamentos e a assinatura de transações devem ter limites de permissões independentes. Para operações que envolvam transferências de ativos, devem também ser utilizadas autenticação multifator, limites de transação, deteção de comportamentos anómalos e aprovação independente para reduzir o risco.

4. Reforçar a gestão de credenciais e registos. As chaves de API, palavras-passe de bases de dados e outras configurações sensíveis devem ser armazenadas através de mecanismos dedicados de gestão de chaves e rodadas regularmente. Nos servidores suspeitos de terem sido comprometidos, devem ser verificados processos anómalos, alterações de ficheiros, ligações de rede e registos de operações das contas.

5. Estabelecer um mecanismo de atualização contínua. O PHP2Shell demonstra que problemas graves de segurança podem surgir em ambientes de execução subjacentes num curto período. As equipas de projeto precisam de monitorizar continuamente os avisos de segurança e estabelecer processos para classificação de vulnerabilidades, testes de correções e atualizações de emergência.

Para sistemas que não podem ser atualizados imediatamente, medidas como restrições de acesso e isolamento de serviços podem reduzir a exposição. No entanto, estas medidas não podem substituir as correções de segurança.

Como podem os utilizadores comuns de criptomoedas proteger as suas contas e carteiras?

Para os utilizadores comuns, o PHP2Shell é uma vulnerabilidade no lado do servidor que, geralmente, não pode ser corrigida através de ações num dispositivo pessoal. Por isso, os utilizadores devem prestar mais atenção à segurança dos prestadores de serviços e reduzir os riscos indiretos que uma violação de servidor pode criar.

• Dar prioridade a plataformas de negociação e serviços de carteira com mecanismos de segurança abrangentes e ativar a autenticação multifator nas contas de negociação. Para operações que envolvam grandes montantes de ativos, funcionalidades como listas de permissões de endereços de levantamento, verificação independente e notificações de segurança podem ajudar a reduzir potenciais perdas após usurpação de identidade.

• Não introduzir a frase-semente nem a chave privada da carteira no website de um projeto. Mesmo que um website tenha funcionado normalmente durante muito tempo, pode ainda ser modificado de forma maliciosa após uma violação do servidor.

• Ao ligar a uma aplicação Web3, verificar o domínio do website, o destinatário da transação e os detalhes da autorização. Não aprovar pedidos de assinatura desconhecidos apenas com base em mensagens da página Web ou no nome de um projeto.

• Minimizar a utilização de chaves de API com privilégios elevados. Se for necessário gerir uma conta de negociação através de uma API, configurar as permissões mínimas necessárias para a utilização pretendida e evitar ativar permissões de levantamento quando não forem necessárias.

• Quando uma plataforma de negociação ou um projeto Web3 publica um anúncio sobre um incidente de segurança, confirmar primeiro o âmbito do impacto através dos seus canais de confiança. Não clicar em ligações desconhecidas que aleguem fornecer migração de ativos de emergência, verificação de carteira ou compensação de segurança.

Estas medidas não conseguem eliminar todos os riscos no lado do servidor, mas podem reduzir a possibilidade de os atacantes afetarem posteriormente os ativos dos utilizadores através de usurpação de identidade, páginas de phishing ou assinaturas maliciosas.

Já ocorreram ataques reais que envolvam o PHP2Shell?

Após a divulgação do PHP2Shell em 21 de outubro de 2026, instituições de investigação em segurança e prestadores de serviços de infraestrutura publicaram sucessivamente análises de risco e recomendações de mitigação. Em 27 de outubro de 2026, algumas organizações de segurança tinham comunicado tentativas de ataque contra as vulnerabilidades relacionadas. No entanto, relativamente a algumas intrusões suspeitas de terem sido bem-sucedidas, a ligação entre o vetor de ataque e os CVE específicos continua incerta.

Por exemplo, a Unit 42 da Palo Alto Networks comunicou uma campanha de intrusão suspeita de estar relacionada com o PHP2Shell. Contudo, após investigação adicional, retirou em 25 de outubro a sua avaliação anterior sobre a ligação entre a intrusão inicial e uma vulnerabilidade específica, afirmando que não conseguia confirmar se os atacantes tinham utilizado o PHP2Shell para obter o acesso inicial.

Esta evolução demonstra que é necessário distinguir entre a possibilidade técnica de exploração de uma vulnerabilidade, tentativas de ataque reais e intrusões bem-sucedidas verificadas. Estas três situações não são exatamente iguais.

Para o setor das criptomoedas, a gravidade do PHP2Shell, por si só, não é suficiente para concluir que uma grande plataforma de negociação foi atacada. Também não se pode atribuir a esta vulnerabilidade cada incidente de roubo de contas comunicado no mercado.

Ainda assim, o PHP2Shell envolve tecnologia do lado do servidor amplamente utilizada e apresenta um risco grave de execução remota de código. Por conseguinte, os programadores e prestadores de serviços devem continuar a tomar medidas de mitigação atempadas.

Conclusão

PHP2Shell é um termo coletivo para duas vulnerabilidades críticas de segurança no núcleo do PHP divulgadas em outubro de 2026: CVE-2026-109618 e CVE-2026-109619. Os riscos principais resultam de potenciais falhas de segurança na forma como o PHP processa pedidos excecionais e a limpeza de memória. Em condições específicas, os atacantes podem alcançar execução remota de código não autorizada.

Para o setor das criptomoedas, o impacto do PHP2Shell concentra-se principalmente nas camadas dos serviços Web, dos sistemas de contas e da infraestrutura de backend. Depois de comprometerem um servidor, os atacantes podem tentar aceder a credenciais sensíveis, manipular interfaces empresariais ou modificar páginas apresentadas aos utilizadores. No entanto, isto não significa que o protocolo blockchain tenha sido quebrado ou que as chaves privadas em carteiras sem custódia sejam expostas automaticamente.

Este incidente demonstra ainda que a segurança dos ativos de criptomoedas depende não só das blockchains e dos contratos inteligentes, mas também da fiabilidade da infraestrutura tradicional da Internet. A gestão de correções de servidores, o isolamento de permissões, a autenticação de contas e a verificação de assinaturas de transações são todos componentes importantes de um sistema de segurança abrangente.

Para os programadores, atualizar prontamente as versões PHP afetadas é a principal prioridade. Para os utilizadores comuns, proteger as credenciais das contas, autorizar cuidadosamente as transações de carteiras e acompanhar anúncios de segurança de fontes de confiança continuam a ser medidas básicas para reduzir o risco.

Perguntas frequentes

O que é o PHP2Shell?

PHP2Shell é um termo coletivo para as duas vulnerabilidades no núcleo do PHP CVE-2026-109618 e CVE-2026-109619. Envolvem problemas de processamento de pedidos excecionais e de segurança da memória que podem conduzir à execução remota de código.

Qual é a gravidade do PHP2Shell?

Ambas as vulnerabilidades têm uma classificação CVSS v4.0 de 9,2, o que as coloca na categoria de gravidade crítica. Em condições específicas de implementação, os atacantes não autenticados podem explorar as vulnerabilidades para executar código no lado do servidor.

O PHP2Shell rouba diretamente ativos de carteiras de criptomoedas?

Não resulta automaticamente no roubo dos ativos da carteira. O impacto real depende de o servidor ter acesso a credenciais sensíveis, chaves privadas ou sistemas de assinatura de transações, bem como de o atacante conseguir contornar os controlos de segurança relacionados.

Que versões de PHP são afetadas pelo PHP2Shell?

As principais versões afetadas incluem as versões anteriores a PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12, respetivamente. Os ramos mais antigos de PHP também podem ser afetados e devem ser verificados em relação às atualizações de segurança fornecidas pelos distribuidores relevantes.

Em que difere o PHP2Shell das vulnerabilidades de contratos inteligentes?

O PHP2Shell afeta o ambiente de execução PHP no lado do servidor, enquanto as vulnerabilidades de contratos inteligentes ocorrem no código do contrato ou na lógica empresarial implementada numa blockchain. Ambos podem afetar indiretamente a segurança dos ativos de criptomoedas, mas as suas raízes técnicas são diferentes.

O PHP2Shell exige que o utilizador inicie sessão antes de poder ser desencadeado?

Algumas vias de ataque validadas não exigem que o atacante inicie sessão antecipadamente no website. No entanto, as condições específicas de exploração dependem da versão do PHP, do modo de funcionamento do servidor e da configuração de implementação.

As carteiras sem custódia, como a MetaMask, são afetadas?

Se a chave privada da carteira for armazenada apenas localmente pelo utilizador, o PHP2Shell geralmente não a consegue obter diretamente. Contudo, um website Web3 comprometido pode induzir os utilizadores a executar transações maliciosas, pelo que os pedidos de assinatura devem continuar a ser verificados cuidadosamente.

Como pode o PHP2Shell ser corrigido?

Instalar as correções de segurança fornecidas pelo PHP ou pelo distribuidor do sistema operativo e confirmar que os serviços PHP relevantes recarregaram o ambiente de execução atualizado. As firewalls ou a filtragem de entradas, por si só, não podem substituir a mitigação.

O PHP2Shell já afetou plataformas de negociação de criptomoedas?

Em 27 de outubro de 2026, não existiam provas públicas fiáveis suficientes que demonstrassem que alguma grande plataforma de negociação de criptomoedas tenha sido comprometida com sucesso devido ao PHP2Shell. A existência de uma vulnerabilidade não pode ser equiparada diretamente a perdas reais de ativos.

Como podem os utilizadores comuns proteger-se contra os riscos relacionados com o PHP2Shell?

Ativar a autenticação multifator, proteger as credenciais de API da conta, não fornecer frases-semente de carteiras a websites, verificar assinaturas de transações Web3 e acompanhar os anúncios de segurança das plataformas através de canais de confiança.