Se estiver a executar o PHP em qualquer parte da sua pilha e não tiver feito a atualização, pare de ler isto e atualize para uma versão corrigida. Encontrará mais informações sobre isto no nosso blog de avisos, e consulte php2shell.aikido.io para verificar se o seu serviço está potencialmente vulnerável.
A semana passada foi, potencialmente, a mais intensa de sempre no que diz respeito à cibersegurança, e não creio que esteja a exagerar. A enxurrada começou com as vulnerabilidades, mas a notícia mais importante foi o PHP2shell.
Muitos sites ficaram fora de serviço para serem atualizados, o que surpreendeu muitos de nós ao percebermos a grande parte da Web que ainda funciona com PHP (70 %, segundo algumas fontes!). O assunto ganhou grande destaque.
O PHP2Shell permaneceu oculto no ambiente de execução do PHP durante cerca de vinte anos, mas, este ano, vários grupos descobriram a mesma vulnerabilidade num curto espaço de tempo. Este mês, os atacantes tentaram explorá-la dias antes mesmo de o PHP ter anunciado que estava a preparar uma correção. A IA mudou as regras do jogo, e quaisquer fugas de informação sobre uma vulnerabilidade ou as respetivas correções são mais perigosas do que antes. Isto significa que a próxima grande vulnerabilidade poderá surgir com menos antecedência, e as equipas responsáveis têm de estar preparadas para reagir e aplicar correções rapidamente.
Como se desenrolaram as revelações sobre o PHP2Shell
Um resumo da cronologia das revelações sobre o PHP2Shell, para contextualizar a situação.
O problema de esgotamento de memória subjacente à primeira das duas vulnerabilidades PHP2Shell já tinha sido detetado numa auditoria realizada em 2024 pela OSTIF e pela Quarkslab, mas permaneceu por corrigir porque ninguém tinha demonstrado que pudesse ser explorado. Foi detetado novamente em 2026, quando a Calif e Wiz identificaram as falhas de forma independente, apresentando provas de exploração (a Calif comunicou o caso no âmbito da iniciativa «Patch the Planet» da OpenAI). A equipa de segurança do PHP confirmou os relatórios e passou as semanas seguintes a desenvolver correções para todas as ramificações suportadas. Os detalhes foram mantidos em sigilo até ao lançamento coordenado.
O PHP tinha inicialmente previsto lançar as correções a 22 de outubro. Quando os identificadores CVE, CVE-2026-109618 e CVE-2026-109619, foram divulgados a 20 de outubro, o PHP publicou o seu pré-anúncio às 19h30 UTC dessa noite e antecipou o lançamento em um dia, para as 14h00 UTC de 21 de outubro.
Aikido Fizemos parte de um grupo de organizações que recebeu informações antecipadas, e o período que antecedeu o lançamento da correção foi caótico. Cada novo vazamento aumentava a probabilidade de os atacantes agirem antes do lançamento das correções, e os membros do grupo debateram se deviam partilhar medidas de mitigação antecipadamente ou ajustar os seus próprios prazos. Acreditamos que a divulgação coordenada merece apoio, pelo que as nossas imagens corrigidas foram lançadas após o anúncio do PHP, a 21 de outubro.
Antes do lançamento e nas horas que se seguiram, uma grande parte da Internet entrou em modo de manutenção enquanto se apressavam a aplicar as correções. A Censys tem vindo a acompanhar a exposição ao PHP2Shell desde 21 de outubro. A 27 de outubro, cerca de 11,2 milhões de serviços PHP tinham migrado para uma versão corrigida, o que corresponde a cerca de um quarto dos que indicavam uma versão, enquanto 32,5 milhões ainda executavam uma versão afetada. Mais de 60 milhões de serviços PHP não indicam qualquer versão, pelo que a exposição real é provavelmente superior. Acompanhe os números em tempo real na página PHP2Shell da Censys.
As tentativas de exploração são agora generalizadas, tendo-se registado também algumas tentativas bem-sucedidas. Num teste público, o investigador de segurança James Pavur configurou um servidor PHP 8.4.26 sem patches, com cerca de 2 000 dólares em bitcoin como prémio, e um participante conseguiu invadir o sistema cerca de três horas após o servidor ter começado a apresentar uma página que executava código PHP.
A análise pós-incidente da Fundação PHP e o relatório do Calif apresentam a cronologia completa, desde a descoberta até ao lançamento da correção.
A IA está a identificar mais vulnerabilidades mais rapidamente
O PHP tem estado na base de uma grande parte da Web há três décadas, pelo que quem o utiliza partia do princípio de que já tinha identificado todos os seus erros graves. «Não sabemos de onde virá o próximo CVE. E pode estar num software que ninguém sequer pensou em criar nos últimos 20 anos», afirma Benji Kalman, vice-presidente sénior de Engenharia da Aikido.
A vulnerabilidade PHP2shell também já existia há algumas décadas, mas como um fantasma por descobrir. O facto de a Calif e a Wiz a terem descoberto com apenas algumas semanas de diferença lembra-nos que a IA vai passar a detetá-las mais rapidamente.
AikidoTestámos a rapidez com que conseguíamos, por nós próprios, identificar estas vulnerabilidades do PHP. Após a divulgação, apontámos o análise de código com IA 's para o PHP, e este redescobriu o PHP2Shell em poucas horas. Temos vindo a testá-lo em bibliotecas de código aberto, mas ainda não tínhamos testado as linguagens subjacentes a estas.
Investigar mais estas vulnerabilidades para as trazer à luz pode ser considerado arriscado, se isso chamar a atenção para uma vulnerabilidade que ninguém conhecia há décadas. Mas se uma ferramenta de defesa consegue encontrar um bug como este numa tarde, as ferramentas dos atacantes não ficarão muito atrás. Trata-se, portanto, de uma espécie de dilema do prisioneiro — os atacantes vão começar a procurar vulnerabilidades em tudo o que conseguirem encontrar e as suas ferramentas vão continuar a melhorar, pelo que os defensores não podem ficar na ignorância. Os hackers éticos também terão de continuar a procurar vulnerabilidades em bibliotecas e linguagens de código aberto. As equipas de segurança devem preparar-se para que a próxima correção urgente seja lançada durante a noite.
A divulgação coordenada tem de avançar mais rapidamente
Com a IA, os atacantes podem começar a agir com muito pouca informação, o que torna difícil gerir uma divulgação desta gravidade. «Basta uma simples sugestão. Basta dizer que existe uma vulnerabilidade no PHP. Já consigo ouvir todas as GPUs a acelerar no centro de dados», afirma Charlie Eriksen, investigador principal de malware d Aikido. «Estamos perante situações em que o tempo entre a descoberta e a exploração está a ser significativamente reduzido, e há tantas pessoas diferentes capazes de descobrir estas vulnerabilidades muito rapidamente.»
A rapidez torna a divulgação coordenada mais valiosa do que nunca, mas também mais difícil de fazer corretamente. Os alertas e os pré-anúncios, embora ajudem as pessoas a prepararem-se para aplicar correções ou desativar serviços, também indicam aos atacantes onde devem procurar. «O alerta também pode causar-lhe prejuízos. É uma dinâmica realmente desafiante», afirma Charlie.
No caso do PHP2Shell, o pré-anúncio pode ter sido agendado com demasiada antecedência em relação ao lançamento inicial. A equipa do PHP antecipou o lançamento em um dia assim que os identificadores CVE e os POCs começaram a surgir. No entanto, a Amazon afirma que as primeiras tentativas de exploração tiveram início no sábado, 17 de outubro, três dias antes do pré-anúncio do PHP, a 20 de outubro (não podemos especular sobre as razões para tal).
Assim que uma correção é disponibilizada ao público, os atacantes têm muito mais recursos à sua disposição do que tinham anteriormente. Com as correções como base, o Charlie estima que alguém com conhecimentos na área poderia criar um exploit com um LLM em poucas horas. No caso do PHP2Shell, a Trail of Bits criou um exploit funcional num dia, utilizando o Codex.
No caso das vulnerabilidades que exigem uma divulgação coordenada, o processo tem de ser mais rápido e rigoroso. Os períodos de embargo devem ser mais curtos e os detalhes técnicos devem chegar ao menor número possível de pessoas, pois cada dia adicional e cada parte envolvida aumentam o risco de uma fuga de informação.
O que os períodos de embargo mais curtos significam para a maioria
Embargos mais curtos e rigorosos ajudam as equipas, reduzindo a janela de oportunidade para fugas de informação e ataques antecipados, mas também deixam menos tempo para que todos os envolvidos a jusante se preparem.
A correção oficial e a correção que uma equipa pode efetivamente instalar nem sempre são disponibilizadas ao mesmo tempo. Na tarde em que o PHP lançou o seu patch, as atualizações do SUSE e do Fedora ainda se encontravam em fase de testes, e a versão «unstable» do Debian continuava a distribuir a versão 8.4.26, que apresentava a vulnerabilidade. Em alojamentos partilhados, os proprietários de sites não podem aplicar a correção ao PHP por conta própria, pelo que têm de aguardar que o seu fornecedor o faça.
As camadas de proteção também dependem de um aviso prévio. Os fornecedores de CDN e WAF que são informados com antecedência podem implementar regras de bloqueio logo no primeiro dia, tal como fez a Cloudflare quando alargou as suas regras de WAF a todos os planos, incluindo o gratuito, antes de o patch ter sido lançado. Com menos fornecedores informados, a rede de segurança é criada mais tarde. Os avisos também podem tornar-se mais curtos e vagos para atrasar os hackers, o que deixa as equipas com menos tempo para planear a manutenção.
Se os prazos de aviso tiverem de ser reduzidos, as equipas de segurança têm de garantir que conseguem receber os alertas atempadamente e que estão preparadas para aplicar as correções rapidamente, ou que dispõem de ferramentas de segurança que o façam automaticamente.
O que as equipas podem fazer antes do próximo «internetbreaks2shell»
O essencial vem primeiro. Em primeiro lugar, comece por saber o que está a executar. «A primeira coisa que, obviamente, precisa de saber é: qual é a minha exposição potencial? Faça um inventário do que tem», diz Charlie. Esse inventário tem de abranger todos os ambientes de execução e dependências que utiliza, incluindo aqueles que não instalou você mesmo. O PHP2Shell é um bom exemplo, uma vez que o PHP aparece frequentemente em imagens base d container , imagens de CI, painéis de alojamento e software de fornecedores.
Em seguida, escolha cuidadosamente as suas fontes de informação. Nas primeiras horas de um incidente, as fontes mais úteis mantêm a informação atualizada à medida que a situação evolui e vão além da simples descrição do problema, fornecendo-lhe medidas de mitigação e, acima de tudo, soluções que pode implementar.
Consulte os seus fornecedores de segurança atuais ou potenciais para saber como estes ajudam e comunicam este tipo de questões:
- Atualizam as suas orientações à medida que a exploração avança?
- Enviam alertas de incidentes em tempo real para que a pessoa certa fique a par da situação sem ter de estar constantemente a percorrer o Twitter?
- Informam-te apenas dos incidentes mais importantes ou inundam-te com uma enxurrada de ruído irrelevante sobre vulnerabilidades de IA?
- Eles explicam como reduzir a exposição enquanto se aguarda uma correção?
- Eles fornecem-te as correções?
Durante o incidente PHP2Shell, atualizámos o nosso aviso à medida que o incidente se desenvolvia e enviámos alertas por e-mail em tempo real. Publicámos uma ferramenta de verificação gratuita em php2shell.aikido.io para que os proprietários de sites pudessem testar se os seus sites apresentavam o comportamento de esgotamento de memória do PHP2Shell.
Também disponibilizámos correções retroativas para o PHP2Shell através das imagens do Aikido . As imagens gratuitas no ECR público do Aikido abrangem o PHP 5.5, 5.6, a série 7.x e as versões 8.2 a 8.5, e foram lançadas pouco depois do lançamento oficial do PHP. As equipas podiam (e ainda podem!) obter uma imagem corrigida sem terem de realizar elas próprias uma atualização significativa do PHP.
«Queremos garantir que estamos a aplicar as correções no local, como costumamos dizer. Isso significa que não vos estamos a pedir para mudarem para um sistema operativo totalmente diferente ou algo do género», diz Benji. «É tão simples como obter a imagem do ECR e substituí-la no vosso Dockerfile.»
Não recomendamos o comportamento do tipo «bot» do Renovate, em que tudo é atualizado automaticamente para as versões mais recentes. Isso provoca falhas constantes na vossa aplicação, pelo que, eventualmente, as equipas acabam por desativar essa funcionalidade. É necessário proteger as equipas sem introduzir vulnerabilidades; por isso, fixem as versões com ficheiros de bloqueio e só atualizem à medida que forem surgindo CVEs.
«A rede é vasta e infinita»
Embora o PHP2Shell tenha sido stressante e um pouco caótico, os defensores ainda podem sair vencedores.
«Penso que, neste momento, os defensores ainda têm a vantagem. É claro que é preciso trabalhar para isso», afirmou Willem Debare, diretor executivo da Aikido, na semana passada, a propósito das vulnerabilidades.
Se começares a desenvolver resiliência agora, estarás entre aqueles que ainda se manterão de pé quando a poeira e os buffers de código assentarem.
P.S. Parte da Web não vai sobreviver a isto. Grande parte ainda funciona com versões antigas do PHP que já não são mantidas. A revista The Atlantic alerta que muitos serão retirados da Internet ou alvo de ataques informáticos, e alguns podem nunca mais voltar. Descanse em paz, bela Internet do início dos anos 2000.
