Tecnologia / [49]

PHP2Shell e Railway: o que aconteceu em 21/10 e qual foi o papel da IA

PHP2Shell e Railway: entenda as falhas de 21/10, o que a IA fez na descoberta do bug do PHP, o que ainda não se sabe e o que atualizar hoje no servidor.

Linha do tempo do PHP2Shell e do incidente da Railway, da auditoria de 2024 até o aviso da Railway em 21 de outubro de 2026

O dia 21 de outubro de 2026 teve dois incidentes de segurança que tomaram conta da internet. O primeiro foi o PHP2Shell, um par de falhas críticas no próprio PHP, a linguagem que roda boa parte dos sites do mundo, inclusive todo site em WordPress. O segundo foi um acesso indevido na Railway, uma plataforma de hospedagem muito usada por quem coloca app e agente de IA no ar.

São casos bem diferentes. E a IA aparece nos dois, só que de jeitos diferentes e com graus de certeza diferentes. Calma que eu explico cada um.

Linha do tempo do PHP2Shell e do incidente da Railway, da auditoria de 2024 até o aviso da Railway em 21 de outubro de 2026

1. O que é o PHP2Shell

PHP2Shell é o apelido de duas falhas no núcleo do PHP, a CVE-2026-109618 e a CVE-2026-109619. O time de segurança do PHP deu nota 9,2 de 10 pras duas no CVSS 4.0. Elas permitem que alguém, sem login nenhum, execute código no servidor.

As duas nascem do mesmo problema: quando uma requisição termina de forma anormal, o PHP pode deixar a memória num estado corrompido. Na primeira, isso acontece quando falta memória no meio da preparação da requisição. Na segunda, sobra um “resto” de uma requisição que aponta pra memória já liberada, e a próxima requisição atendida pelo mesmo processo usa esse resto.

Diagrama em quatro passos do PHP2Shell: requisição sem login, término anormal, memória corrompida e execução de código pelo mesmo processo

Segundo o próprio PHP, toda instalação que atende requisições web está em risco: PHP-FPM, Apache com mod_php, php-cgi, FrankenPHP e LiteSpeed. O risco maior é no mod_php, onde o ataque demonstrado dispara antes de qualquer linha da aplicação rodar. A Calif, que publicou a análise técnica, diz que o caminho vulnerável mais antigo que encontrou vem do PHP 5.4.

O que aconteceu no dia

Os identificadores das falhas vazaram em 20/10. O PHP tinha planejado o lançamento pra 22/10 e antecipou pra 21/10, às 11h de Brasília. Saíram as versões 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Pras versões 7.4 a 8.1, que já não têm suporte, o time publicou só correções mínimas em código-fonte.

A CISA, agência de cibersegurança dos EUA, pediu atualização imediata e recomendou tirar do ar o que não pudesse ser atualizado. O centro canadense e o de Singapura publicaram alertas no mesmo dia.

Teve ataque? A Amazon disse ter visto uma tentativa de exploração em 17/10, quatro dias antes do anúncio, e mais tentativas em 21/10. Cloudflare, watchTowr e outras empresas também relataram tentativas. Mas os relatos não batem entre si: a CISA dizia, na hora da publicação, que não tinha visto exploração, e a watchTowr disse que não tinha visto nenhuma tentativa bem-sucedida. A Amazon recomenda investigar os logs a partir de 17/10, e não a partir do dia do anúncio.

2. O papel da IA no PHP2Shell

Aqui a IA tem papel comprovado, e na descoberta. Segundo o comunicado da PHP Foundation relatado pelo The Record, uma auditoria externa já tinha apontado o problema de memória em 2024, mas a correção travou por meses, porque nenhuma saída parecia boa e ninguém tinha mostrado um caminho até a execução de código.

Isso mudou com as ferramentas de revisão de código com IA. Um pesquisador da Calif reportou as falhas em 11 de agosto, dentro do programa Patch the Planet da OpenAI. A Wiz diz que encontrou a falha em 19 de agosto e reportou em 24, usando o Wiz Atlas, o Gemini 4 Argon e o GPT-5.6 Sol na descoberta, no desenvolvimento do exploit e na validação do patch. A Calif e a Wiz afirmam que usaram modelos de IA na pesquisa, e a PHP Foundation credita Calif, OpenAI e Wiz, entre outros.

Do lado da exploração, não achei nenhuma fonte confiável dizendo que os atacantes usaram IA. O que acelerou os exploits, segundo a PHP Foundation, foi um vídeo publicado por engano pela Calif mostrando a prova de conceito funcionando. Do lado da defesa, a IA aparece em ferramentas comerciais, como a Tenable sugerindo o assistente dela pra achar servidores vulneráveis. Nenhuma fonte mediu se isso ajudou de fato.

3. O que aconteceu na Railway

No aviso publicado em 21/10, a Railway disse que detectou atividade anômala nos sistemas que guardam as variáveis de ambiente dos clientes. Um terceiro sem autorização pode ter acessado essas variáveis criptografadas e, em parte delas, o conteúdo já descriptografado. Variável de ambiente é onde costuma ficar chave de API, senha de banco e credencial de registro de imagens.

A empresa pausou todos os deploys, recomendou que todo cliente trocasse todas as variáveis e, segundo a página de status, começou a trocar as credenciais dos buckets às 19h37 de Brasília. No guia de 22/10, contou que também invalidou os tokens do GitHub que guardava, e que o cliente precisa reconectar o GitHub e fazer redeploy dos serviços.

4. O papel da IA no caso da Railway

Aqui é preciso cuidado. A Railway disse acreditar que o ataque faz parte de uma série contra empresas de plataforma “com o objetivo de comprometer provedores de inferência de IA”, e que avisou esses provedores pra revogarem chaves. Ou seja, a IA aparece como alvo: as chaves de API de serviços de IA guardadas nas variáveis.

Não há, nas fontes oficiais até agora, nada dizendo que IA foi usada pra invadir a Railway, nem que ela ajudou a detectar o ataque. A empresa também não disse como o invasor entrou nem quantas contas foram afetadas. Não encontrei relação entre esse caso e o PHP2Shell.

5. O que fazer agora

Checklist de proteção com cinco ações para PHP e três para clientes da Railway

Se você tem site ou sistema em PHP:

  • Atualize pra 8.5.12, 8.4.27, 8.3.36 ou 8.2.35. O PHP diz que só a atualização resolve de vez.
  • Se está no 8.1 ou anterior, fale com o fornecedor ou com a distribuição, ou migre.
  • Procure PHP onde ninguém lembra que tem: containers, painéis de hospedagem, equipamentos com interface web.
  • Um WAF, como as regras que a Cloudflare liberou até no plano grátis, ajuda a ganhar tempo. A própria Cloudflare chama isso de tapa-buraco.
  • Olhe os logs desde 17/10 atrás de processos do PHP abrindo shell ou baixando ferramentas.

Se você usa a Railway:

  • Troque todas as variáveis de ambiente e chaves de API guardadas lá, inclusive as de provedores de IA.
  • Reconecte o GitHub e faça redeploy dos serviços que usam buckets.
  • Revise os logs dos serviços ligados a essas chaves.

Se quiser entender a base disso tudo, escrevi sobre o que é segurança digital na prática.

Os dois casos mostram a IA em lados diferentes. No PHP, ela ajudou a encontrar uma falha que estava parada desde 2024. Na Railway, as chaves de IA eram o que o invasor queria. Você já conferiu a versão do PHP dos seus sites?

Leave a Reply

Your email address will not be published. Required fields are marked *