Uma vulnerabilidade «-Shell» é uma falha de execução remota de código (RCE) num software. O sufixo «-Shell» ganhou popularidade com o Log4Shell (CVE-2021-44228) em dezembro de 2021. O React2Shell substituiu o 4 por um 2 em dezembro de 2025, e a comunidade de investigação seguiu a convenção de nomenclatura ao dar nome aos bugs de outubro. O PHP divulgou o PHP2Shell a 21 de outubro de 2026, e o Node.js lançou as suas correções para o Node2Shell no mesmo dia. Qualquer um deles, por si só, teria sido a notícia de segurança do ano.
Se a sua pilha de tecnologias utiliza PHP, Node.js, React ou Java, é provável que pelo menos uma destas tecnologias já fizesse parte dela, caso a estivesse a utilizar há alguns anos.
O que é que todas as vulnerabilidades do shell têm em comum?
Todas as vulnerabilidades de tipo «shell» existem a um nível inferior ao da aplicação, numa biblioteca de registo, numa estrutura de interface do utilizador, num ambiente de execução da linguagem ou num descodificador de compressão. Na exploração comprovada relatada para o PHP contra o Apache com o mod_php, o PHP2Shell é acionado enquanto o PHP ainda está a processar o pedido recebido, antes de uma única linha da sua aplicação ser executada. O React2Shell afetou aplicações que nunca definiram uma função de servidor própria. Uma equipa pode escrever código cuidadoso e bem revisto e, mesmo assim, ficar exposta, porque a parte vulnerável não é algo que tenha sido escrita por ela.
Em todas estas vulnerabilidades de shell, os dados introduzidos pelo atacante chegaram a código que os tratava como seguros. O Log4j interpretou texto que deveria apenas registar, e o React reconstruiu objetos a partir de cargas úteis do Flight sem verificar a sua estrutura. O Express 5 e o body-parser 2.x descodificam corpos de pedido Brotli de qualquer cliente que os envie, muitas vezes antes de ser executada qualquer verificação de autenticação.
Nenhuma destas vulnerabilidades exige que o atacante inicie sessão. Basta uma solicitação manipulada para que o código seja executado no servidor. O Node2Shell também tinha uma segunda via de ataque, uma vez que uma resposta manipulada a uma solicitação efetuada pela sua aplicação também pode desencadeá-lo.
A maioria das equipas também herda o componente vulnerável sem nunca o ter escolhido. O Log4j surgiu normalmente como uma dependência de uma dependência, e o Node.js e o PHP vêm incluídos em imagens d container , que raramente são recompiladas até que algo o exija. O Brotli vai ainda mais longe, uma vez que o seu descodificador está integrado em ambientes de execução e proxies como o Node.js, o Bun, o .NET e o Envoy. Em Python, clientes HTTP populares, como o requests e o httpx, carregam o Brotli automaticamente quando este está presente, e alguns pacotes, como o Scrapy, instalam-no como dependência, pelo que uma aplicação pode ser disponibilizada sem importar o Brotli em qualquer parte do seu próprio código.
Visão geral das vulnerabilidades do shell
Vulnerabilidades de shell decorrentes de corrupção de memória (PHP2Shell e Node2Shell)
O PHP2Shell está presente no código C do próprio motor do PHP, enquanto o Node2Shell está presente no Brotli, uma biblioteca de compressão em C que o Node.js e muitas outras plataformas compilam no seu próprio código. Ambos vieram a ser divulgados ao público através de investigação assistida por IA, embora, no caso do PHP2Shell, os modelos tenham concluído um trabalho que os humanos tinham iniciado anos antes.
PHP2Shell (CVE-2026-109618 e CVE-2026-109619)
Um worker do PHP processa pedido após pedido, reservando memória para cada um e libertando-a assim que o pedido é concluído. Ambos os bugs do PHP2Shell forçam o PHP a ficar sem memória num momento preciso, pelo que um pedido é interrompido a meio do seu processamento e deixa um ponteiro para memória que já foi libertada. O pedido seguinte do atacante preenche essa memória com dados manipulados, e o PHP lê-os como se fossem um dos seus próprios objetos internos.
A vulnerabilidade CVE-2026-109618 ocorre enquanto o PHP está a preparar os dados do pedido, e a vulnerabilidade CVE-2026-109619 explora o estado que o worker mantém entre pedidos, sendo o progresso do upload da sessão — que está ativado por predefinição — uma das vias de exploração confirmadas.
O código vulnerável remonta à versão PHP 5.4, lançada em 2012, e a ideia subjacente remonta a um erro relacionado com o limite de memória que Stefan Esser descobriu em 2004. Uma auditoria realizada em 2024 revelou o mesmo problema, mas ninguém conseguiu provar que era explorável, pelo que a correção ficou em suspenso. Em agosto de 2026, o investigador californiano Ryan Austin utilizou IA para fazer o que a auditoria não conseguiu e transformou o bug numa execução de código funcional.
Os detalhes foram divulgados antes do anúncio previsto, o PHP lançou as correções um dia antes, a 21 de outubro, e o siteCloudflare informou que a exploração da vulnerabilidade tinha começado nesse mesmo dia. O nosso aviso sobre o PHP2Shell abrange as versões afetadas, as medidas de mitigação e como aplicar as correções, e mantemo-lo atualizado à medida que as orientações se alteram.
Node2Shell (CVE-2026-111497)
O Node.js inclui a sua própria cópia do Brotli, a biblioteca de compressão da Google, e o Node2Shell é um bug no descodificador do Brotli, em que dados comprimidos especialmente criados para o efeito fazem com que este escreva para além do fim de um buffer de memória.
A equipa de segurança do Codex da OpenAI relatou que se trata de uma falha de execução remota de código que funciona em ambos os sentidos, pelo que um cliente malicioso pode assumir o controlo de um servidor sem patch e um servidor malicioso pode assumir o controlo de um cliente sem patch que aceite respostas comprimidas. No Node.js, o Express 5 e o body-parser 2.x descodificam automaticamente os corpos das solicitações em Brotli, e o fetch() faz o mesmo com as respostas.
Os investigadores conseguiram executar código numa imagem do Node.js 24.22.0 não modificada, mas a sua exploração não funcionou em todas as tentativas; por isso, na prática, é mais provável que ocorra uma falha do sistema ou uma fuga de memória. O nosso aviso sobre o Node2Shell enumera as versões corrigidas para cada linha de lançamento.
HTTP2Shell e Broccoli2Shell
O descodificador do Brotli está presente em muito mais do que apenas o Node.js, razão pela qual o mesmo bug recebeu nomes como HTTP2Shell e Broccoli2Shell (HTTP2Shell e Broccoli2Shell referem-se ao mesmo bug do Brotli no Node.js). Já foram lançadas correções para o Node.js, Bun, Envoy, Istio, .NET, Python, Java brotli4j, libbrotli, Ubuntu e várias distribuições Linux, enquanto a SUSE e os repositórios padrão do Red Hat Enterprise Linux ainda não dispõem de uma correção.
Os responsáveis pelo Brotli já tinham corrigido o erro no seu código-fonte a 27 de fevereiro, mas ninguém o reconheceu como um problema de segurança, pelo que só foi incluído numa versão a 21 de outubro. Os projetos incluem versões lançadas do Brotli, pelo que todas as cópias em circulação permaneceram vulneráveis durante oito meses, e cada projeto teve então de lançar a sua própria atualização de acordo com o seu próprio calendário. O Aikido Security acompanha cada uma delas numa tabela em tempo real sobre o estado das correções.
Vulnerabilidades do Logic 2Shell (Log4Shell e React2Shell)
As vulnerabilidades Log4Shell e React2Shell ocorreram em Java e JavaScript, linguagens que gerem a memória automaticamente, pelo que nada fica corrompido. As falhas residem na forma como uma funcionalidade foi concebida, o que permitiu que a entrada de um atacante determinasse o código que o servidor executava. Ambas obtiveram uma pontuação CVSS perfeita de 10,0 🏆.
Log4Shell (CVE-2021-44228)
O Log4j é uma biblioteca de registo do Java, e o Log4j 2 suportava «lookups» — marcadores de substituição escritos como ${...} — que substituía por um valor real, como uma variável de ambiente, sempre que escrevia uma mensagem. Fazia isto com qualquer texto que registasse, incluindo texto proveniente dos utilizadores. Um tipo de consulta, ${jndi}, instrui o Java a ir buscar um objeto a partir de um servidor de diretório; assim, um atacante que inserisse uma consulta ${jndi} apontando para o seu próprio servidor num cabeçalho do navegador ou numa mensagem de chat do Minecraft poderia fazer com que o Log4j descarregasse uma classe Java e a executasse.
A maioria das aplicações regista alguns dados introduzidos pelo utilizador, o que tornava praticamente qualquer campo de texto na Internet uma possível via de acesso. O Log4j também costumava estar situado várias camadas abaixo nas árvores de dependências, pelo que muitas equipas passaram os primeiros dias apenas a tentar determinar se o utilizavam. Os investigadores descobriram então falhas na primeira correção (2.15.0) e na seguinte, e as equipas continuaram a atualizar até que a versão 2.17.1 as corrigisse.
React2Shell (CVE-2025-55182)
Os React Server Components são executados no servidor e enviam a sua saída para o navegador, e o navegador pode chamar funções do servidor diretamente. O React transmite tudo isto num formato denominado «Flight». Quando chega um pedido «Flight», o servidor reconverte-o em objetos, um passo denominado «deserialização», e o React confiava na estrutura desses dados. Um atacante poderia criar um pedido que chegasse a funções integradas do Node.js, como a `child_process.execSync`, e executasse comandos de shell sem ter de iniciar sessão.
As aplicações ficavam expostas mesmo que nunca tivessem definido uma função de servidor, porque o código de descodificação do Flight é executado sempre que os Componentes de Servidor são suportados. As configurações predefinidas do React 19 estavam vulneráveis, e a CISA, a Agência de Cibersegurança e Segurança de Infraestruturas dos EUA, adicionou esta vulnerabilidade à sua lista de vulnerabilidades exploradas em ataques reais. Um bug subsequente, o CVE-2025-67779, contornou a correção original, pelo que as equipas tiveram de atualizar pela segunda vez.
Por que é que os erros do 2Shell continuam a surgir?
O PHP2Shell, o Node2Shell e o HTTP2Shell surgiram na mesma semana que foram detetadas falhas críticas no , no eMudhra, no GitLab, no NGINX, no Plex, na Railway e no OpenCode. Qualquer uma delas poderia ter sido a maior notícia do ano em matéria de segurança, e as pessoas começaram a chamar-lhe «Outubro Negro».
A IA está a detetar erros antigos mais rapidamente
O PHP tem estado na base de uma grande parte da Web há três décadas, pelo que a maioria das pessoas partia do princípio de que os seus bugs graves já tinham sido detetados há muito tempo; no entanto, o PHP2Shell permaneceu no código durante 14 anos. Após a divulgação, apontámos o análise de código com IA , do site Aikido, para o código-fonte do PHP, e este redescobriu o PHP2Shell em poucas horas. Se uma ferramenta de defesa consegue encontrar um bug como este numa tarde, as ferramentas dos atacantes não ficarão muito atrás.
Como o Aikido Security o ajuda a gerir as vulnerabilidades do 2Shell
Aikido A análise de imagens « análise de composição de software » da Security (SCA) e a verificação de imagens docontainer mostram quais repositórios e imagens ainda executam um ambiente de execução ou biblioteca vulnerável, incluindo pacotes Brotli transitivos.
Se não for possível atualizar de imediato, as imagens corrigidas gratuitas doAikido , disponíveis no registo público do Amazon Elastic Container do site Aikido, abrangem as versões do PHP 5.5 a 8.5, com exceção, por enquanto, das versões 8.0 e 8.1. Nas versões que não dispõem de correcções do fornecedor original, as correcções são adaptadas para que possa manter o seu número de versão. No que diz respeito à falha do Brotli, as imagens corrigidas do Node.js e do Ubuntu disponíveis em Aikidopermitem-lhe manter a sua versão atual em plataformas sem correcções do fornecedor, incluindo o Node.js 18 e 20.
O verificador gratuito PHP2Shell analisa um URL público e indica o seu estado, desde vulnerável até totalmente atualizado.
{{walkthrough}}
