Um bug no PHP tirou sites do ar no mundo todo

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: A PHP Bug Just Took Websites Offline Worldwide · Canal: Better Stack · 06:43 · Assistir no YouTube

Tópicos: Cibersegurança e segurança de software, Engenharia de software com IA

Resumo

Duas vulnerabilidades no próprio PHP permitem execução remota de código e levaram órgãos de segurança a recomendar que sistemas sem correção fossem tirados do ar. A divulgação descoordenada fez empresas e sites desligarem serviços enquanto administradores corriam para instalar os patches. Até o momento, não havia confirmação de exploração bem-sucedida, mas muitas instalações antigas podem continuar vulneráveis. O vídeo também discute o papel da IA na descoberta de falhas e na criação de exploits, além dos desafios para os processos tradicionais de divulgação responsável.

Pontos-chave

As vulnerabilidades estão no PHP, não no WordPress ou em plugins; por isso, atualizar apenas o aplicativo não resolve o problema.
Uma requisição preparada para provocar uma situação específica de falta de memória pode fazer o PHP confiar em dados incompletos e permitir execução remota de código.
Pesquisadores demonstraram a exploração em instalações recentes de WordPress, Drupal e Joomla e afirmaram que versões do PHP da última década são afetadas.
A divulgação foi antecipada após a publicação de informações incorretas sobre a gravidade e o vazamento de materiais antes do lançamento oficial.
Órgãos como NSA, CISA, FBI e NCSC recomendaram tirar sistemas do ar caso não fosse possível atualizá-los imediatamente.
Vários sites e serviços foram desligados preventivamente; até então, autoridades e pesquisadores citados não tinham confirmado explorações bem-sucedidas.
Versões antigas do PHP podem ser especialmente difíceis de corrigir, embora pacotes mantidos para Debian e Ubuntu tenham recebido correções até o PHP 7.4.
O vídeo destaca que IA pode acelerar a transformação de uma hipótese de vulnerabilidade em um exploit funcional, reduzindo o tempo disponível para resposta.

Capítulos

Início	Capítulo	Resumo
00:00	As vulnerabilidades no PHP e seu impacto	O vídeo apresenta as duas falhas, explica que estão no próprio PHP e descreve como podem permitir execução remota de código.
01:32	Uma divulgação conturbada	Informações antecipadas e a publicação de materiais antes do prazo oficial comprometeram a divulgação coordenada e aceleraram a corrida por exploits.
02:35	Sites desligados e tentativas de exploração	Órgãos de segurança recomendaram desligar sistemas sem correção, levando diversos sites a sair do ar, enquanto empresas aplicavam medidas de proteção.
04:06	Versões antigas e o papel da IA	O vídeo aborda a dificuldade de corrigir versões antigas, a disputa sobre quem descobriu a falha e a possível contribuição de modelos de IA.
05:41	Aceleração dos ataques e limites da divulgação responsável	Outros incidentes e a velocidade para desenvolver exploits com IA reforçam a preocupação com processos de divulgação pensados para um cenário diferente.

Citações

Isso está no próprio PHP, então atualizar seu aplicativo não resolve. Você precisa atualizar o PHP. — 00:30

Se não puder atualizar imediatamente, tire o sistema do ar. — 02:35

Até onde sabemos, metade da internet não foi hackeada. — 03:35

Uma pessoa fez em uma semana o que levaria meses para uma equipe de nível mundial. — 05:09

A divulgação foi criada para um mundo em que encontrar a falha era a parte difícil, e não acho que ainda estejamos nesse mundo. — 06:12

Conceitos e entidades

PHP (ferramenta): Linguagem de programação cuja implementação foi afetada pelas vulnerabilidades discutidas no vídeo.
PHP Foundation (empresa): Organização que explicou, no vídeo, como as vulnerabilidades podem permitir que dados incompletos sejam usados de forma insegura.
Wiz (empresa): Empresa de segurança que demonstrou a exploração em instalações de sistemas populares e atribuiu uma contribuição importante à IA.
Cloudflare (empresa): Empresa que preparou regras de firewall antecipadamente para ajudar a bloquear tentativas de exploração.
CISA (empresa): Agência de segurança cibernética dos Estados Unidos que recomendou tirar sistemas vulneráveis do ar se não fosse possível atualizá-los e informou não ter visto exploração bem-sucedida.
NSA (empresa): Agência dos Estados Unidos que recomendou desligar sites que não pudessem receber a correção.
Debian (ferramenta): Distribuição Linux cujos pacotes de PHP, segundo o vídeo, receberam correções para versões antigas.
Ubuntu (ferramenta): Distribuição Linux cujos servidores usam pacotes de PHP mencionados entre os que receberam correções para versões antigas.
Laravel (ferramenta): Framework PHP cujo criador, Taylor Otwell, comentou que incidentes desse tipo provavelmente não se limitarão ao PHP.

Tradução completa (pt-BR)

00:00 A NSA e outras agências de cibersegurança do mundo todo estão dizendo às organizações para tirar seus sites do ar se não conseguirem aplicar as correções. Grandes nomes como o 4chan ficaram fora do ar, partes da Wikimedia também, e até fóruns de hackers como o BreachForums se desligaram. Tudo isso por causa de dois bugs no PHP, que roda em cerca de 70% da internet, então o impacto pode ser enorme. Os pesquisadores que os encontraram estão comparando isso ao Heartbleed e ao Log4Shell. >> [música]

00:30 >> Esses dois bugs estão sendo chamados de PHP to Shell e se tornaram públicos na quarta-feira, com uma pontuação de 9,2 em 10. Uma coisa importante a observar é que isso não está no WordPress nem em algum plugin duvidoso, como já vimos antes. Está no próprio PHP, então atualizar seu aplicativo não resolve. Você precisa atualizar o PHP. Em resumo, segundo a PHP Foundation, se uma requisição faz o PHP ficar sem memória no momento exato, o PHP pode deixar para trás dados parcialmente construídos e confiar neles depois. E, com a requisição certa, isso significa que alguém na internet pode executar o próprio código no seu servidor sem fazer login. Ou seja, pode

01:01 executar código remotamente. Os pesquisadores de segurança da Wiz mostraram esse exploit funcionando em instalações novas das versões mais recentes do WordPress, Drupal e Joomla, e dizem que isso pode afetar até mesmo um aplicativo “hello world”, já que a vulnerabilidade está na própria linguagem. Eles afirmam que todas as versões do PHP da última década podem ser exploradas por uma dessas vulnerabilidades. Então, se você está assistindo a este vídeo e acabou de lembrar que tem um servidor PHP configurado em algum lugar, vá em frente e atualize-o. Inscreva-se também, porque vejo que cerca de 80% de vocês não estão inscritos, e isso realmente nos ajuda. Agora, a divulgação desses dois bugs foi meio conturbada.

01:32 Era para ser um lançamento coordenado e tranquilo. O plano era publicar tudo na quinta-feira. Na tarde de terça, os dois números de CVE foram publicados no Hacker News com a gravidade errada, dizendo que ambos eram nota 10. A pessoa que publicou isso já pediu desculpas e disse que sua fonte havia informado que não havia embargo. Mas, por causa disso, naquela noite o PHP avisou todo mundo com antecedência e antecipou o lançamento em um dia. Mais ou menos na mesma época, a Kaliff, uma das empresas que encontrou o bug, publicou por engano um vídeo do exploit funcionando contra alvos reais. O vídeo foi apagado, mas cópias estavam circulando pelo

02:03 Twitter. Então, na manhã de quarta-feira, mais de 6 horas antes do lançamento, a Chain Guard publicou imagens corrigidas do PHP, e a PHP Foundation diz que isso quebrou o embargo unilateralmente, porque agora qualquer pessoa podia estudar a correção enquanto todo mundo ainda estava esperando. Assim, quando a correção foi finalmente lançada, às 2h UTC, todo mundo já sabia mais ou menos onde procurar. O que aconteceu com a divulgação responsável? Agora, é claro, as pessoas começaram a correr para criar um exploit e, como há muitos servidores que não serão corrigidos em um dia, as recomendações ficaram bem drásticas. A NSA, a CISA, o FBI e o NCSC do Reino Unido disseram

02:35 que, se você não puder atualizar imediatamente, tire o sistema do ar. Até o primeiro-ministro do Japão publicou um tuíte sobre isso. Em resposta, vimos uma onda de sites saindo do ar. Nos Países Baixos, o DigiD, o serviço nacional de login, ficou fora do ar, junto com o site do Parlamento e até o site nacional de cibersegurança. No Reino Unido, sites de Edimburgo, Bristol e Oxford saíram do ar. A Wikimedia tirou alguns sistemas do ar, e o 4chan e o Something Awful também ficaram offline enquanto aguardavam a correção. Levels, um dos maiores fãs de PHP que sigo no Twitter, desconectou todos os servidores da empresa antes de a correção

03:05 ser lançada. E um administrador de sistemas no Reddit disse que foi a primeira vez em 20 anos que tiraram deliberadamente o site do ar. E, numa ironia divertida, o Breach Forums também ficou offline, e o moderador disse que o fórum continuará fora do ar até o PHP ser corrigido, porque levamos nossa segurança a sério. Quer dizer, sim, imagino que o fórum cheio de hackers também tenha grandes chances de ser hackeado. Agora, um dos motivos pelos quais o impacto talvez não tenha sido tão grande quanto poderia ser é que a Cloudflare e algumas outras empresas foram avisadas com semanas de antecedência, então criaram regras de firewall discretamente. A Cloudflare ativou as regras para todos os clientes às 3h UTC de quarta-feira,

03:35 e diz que viu atacantes publicarem seus payloads em tuítes para tentar contornar as regras. Então, metade da internet foi hackeada? Bem, até onde sabemos, não. A Watchtower diz que está vendo tentativas reais no mundo todo, usando ferramentas de exploração codificadas com IA, mas, nas palavras da empresa, ninguém conseguiu até agora. A CISA também diz que ainda não viu tentativas de exploração bem-sucedidas. Então, por enquanto, os danos se resumem principalmente aos sites que as pessoas decidiram tirar do ar. Mas a preocupação de verdade está na longa cauda. Só as versões 8.2 e mais recentes tiveram lançamentos oficiais de correções, e para as versões mais antigas você precisa compilar as correções por conta própria. E uma análise constatou que 59% dos

04:06 servidores usam PHP 8.1 ou mais antigo, e provavelmente esses não serão corrigidos nesta semana, ou talvez nunca. Vale mencionar aqui Andre Suri, que mantém os pacotes do PHP usados por muitos servidores Debian e Ubuntu. Esses pacotes receberam correções até a versão PHP 7.4, o que foi uma iniciativa absolutamente incrível. Agora, outro ponto caótico dessa história é quem realmente encontrou esse bug. A Open AI diz que a Kali encontrou o bug usando GPT 5.6 Soul, como parte do programa Patch the Planet da Open AI, e que a Open AI liderou o grupo que preparou todo mundo. Eles estão chamando

04:37 isso de uma das vulnerabilidades mais impactantes dos últimos tempos. A Wiz encontrou o bug de forma independente e diz que o Gemini 4 Argon deu uma contribuição inestimável; vale notar que a Wiz agora pertence ao Google. Depois, a Kali publicou dizendo: “Vamos esclarecer os fatos”, afirmando que seu pesquisador foi o primeiro e apontando para um tuíte de 5 de agosto como prova. E, no relatório da Kali, eles dizem que o pesquisador não usou harnesses especiais nem modelos que não estivessem disponíveis para todos. Escolheram o PHP porque conheciam seu histórico e tinham uma teoria sobre onde os bugs estavam escondidos. E o que ele está mencionando aqui é uma auditoria de segurança de 2024 da PHP

05:09 Foundation, que já havia encontrado os primeiros sinais desse problema específico, mas ninguém conseguia provar que ele podia ser explorado, então a correção continuava emperrada. Em outras palavras, foi uma falha estrutural, e eles até analisaram o PHP com o Claude Mythos da Anthropic no começo do ano, mas, aparentemente, ele também não detectou o problema. Então, o que mudou desta vez? Bem, essa classe de bug remonta a uma pesquisa de 2004. O que mudou foi o quanto alguém que sabe onde procurar consegue transformar uma teoria antiga em um exploit funcional. A Wiz diz que um pesquisador fez em uma semana o que levaria meses para uma equipe de nível mundial. E essa é a parte assustadora. Nada

05:41 disso vai desacelerar. No mesmo dia, o Node.js corrigiu um bug próprio de execução remota de código, e o GitLab lançou uma correção para uma falha que estou classificando com nota 10 em 10. Então, naquela mesma noite, acabei de ver que a Railway anunciou uma violação de segurança. Eles dizem que alguém acessou os sistemas que armazenam as variáveis de ambiente dos clientes e, em alguns casos, obteve os valores descriptografados. Ou seja, chaves de API, bancos de dados e senhas foram vazados. Nada liga isso ao PHP to Shell, mas a Railway diz que parece fazer parte de uma série de ataques a plataformas com o objetivo de obter chaves de provedores de IA.

06:12 A OpenAI diz que o PHP to Shell é um dos vários bugs importantes que já encontrou e espera que o número de descobertas aumente bastante nos próximos meses. Taylor Otwell, que criou o Laravel, resumiu bem a situação. Ele disse que provavelmente não será a última vez e que o PHP provavelmente não será a única linguagem a passar por isso. No geral, acho que o bug em si foi a parte menos interessante dessa história. A correção estava pronta, a CDN estava pronta, mas, ainda assim, tudo virou caos porque a notícia vazou um dia antes e, por causa da IA, bastam algumas horas para pessoas com agents de IA começarem a criar exploits. A divulgação foi concebida para um mundo em que encontrar o bug era

06:43 a parte difícil, e não acho que ainda vivamos nesse mundo. Então, se você usa PHP em qualquer lugar, até mesmo em algum servidor de que se esqueceu, vá em frente e atualize-o. Conte nos comentários abaixo o que acha de tudo isso ou inscreva-se e, como sempre, até a próxima. >> [música]

Transcrição original

[00:00] The NSA and other cyber agencies across the world are telling organizations to take their websites offline if they can’t patch them. Big names like 4chan went down, parts of Wikimedia went down, and even hacker forums like BreachForums have switched themselves off. All of this because of two bugs in PHP, and PHP runs roughly 70% of the internet, so the scale of this could be massive. The researchers who found them are comparing this to Heartbleed and Log4Shell. >> [music]

[00:30] >> So these two bugs are being called PHP to shell, and they went public on Wednesday with a score of 9.2 out of 10. An important thing to note here is this isn’t WordPress or some dodgy plugin like we’ve seen before. This is in PHP itself, so updating your app doesn’t fix this. You have to update PHP. The PHP Foundation’s short version of how this works is if a request runs PHP out of memory at exactly the wrong moment, PHP can leave half-built data behind and later trust it. And with the right request, that means someone on the internet can run their own code on your server without logging in. So they can

[01:01] have remote code execution. The security researchers Wiz showed this exploit working against fresh installs of the latest versions of WordPress, Drupal, and Joomla, and they say this can even impact a hello world application as it’s the language itself that’s vulnerable. They say that every version of PHP from the last decade can be exploited by one of these vulnerabilities. So if you’re watching this video and you just remember that you have a PHP server set up somewhere, go ahead and update it. Also subscribe because I see about 80% of you aren’t subscribed, and it really helps us out. Now, how these two bugs were disclosed was a bit of a rocky

[01:32] ride. It was meant to be a calm coordinated release. The plan was to publish everything on a Thursday. On Tuesday afternoon, the two CVE numbers got posted to Hacker News with the wrong severity, claiming they were both a perfect 10. The person who had posted this since apologized and said their source told them there was no embargo. But because of this, that evening PHP gave everyone advanced notice and pulled the release forward a day. Around the same time, Kaliff, one of the firms that found the bug, mistakenly published a video of their exploit working against real targets, and it did get deleted, but copies of it were going around

[02:03] Twitter. Then on Wednesday morning, more than 6 hours before the release, Chain Guard published patched PHP images, and the PHP Foundation says that unilaterally broke the embargo, because anyone can now go study the fix while everyone else was still waiting. So, by the time the patch actually landed at 2:00 a.m. UTC, everyone already knew roughly where to look. Whatever happened to responsible disclosure? Now, obviously, people began racing to build an exploit, and since there’s a lot of servers that won’t be patched in a day, the advice got pretty drastic. The NSA, CISA, the FBI, and the UK’s NCSC all

[02:35] said that if you can’t update straight away, take the system offline. Even Japan’s Prime Minister tweeted about this. As a response, we saw a wave of websites going down. In the Netherlands, DigiD, the national login service, went down, along with Parliament’s website, and even the national cybersecurity one. In the UK, Edinburgh, Bristol, and Oxford had sites go offline. Wikimedia took some systems down, and 4chan and Something Awful also went offline to wait for the patch. Levels, one of the biggest PHP fans that I follow on Twitter, disconnected every single server of his business before the patch

[03:05] dropped. And one sysadmin on Reddit said it was the first time in 20 years they’d deliberately taken their website down. In a fun bit of irony as well, Breach Forums also went offline, and the moderator said they’ll stay down until PHP is patched, and we take our security seriously. I mean, yeah, I suppose the forum with all of the hackers is most likely to be hacked as well. Now, one of the reasons this might not have the scale that it could potentially have is because Cloudflare and several and a few others were told weeks in advance, so they quietly built firewall rules. Cloudflare switched theirs on for every customer at 3:00 a.m. UTC on Wednesday,

[03:35] and they say they watched attackers tweet their payloads to try and get around them. So, has half the internet been hacked? Well, not as far as we know. Watchtower says they are seeing real attempts in the world using exploit tools 5 coded with AI, but in their words, nobody’s been successful to date. CISA also says it hasn’t seen successful exploitation attempts yet. So right now, the damage is mostly in the websites that people chose to switch off. But the real worry is in the long tail. Only 8.2 and newer got proper releases, and older versions got patches you have to build yourself. And one scan found that 59% of

[04:06] servers show a PHP version of 8.1 and older, and that’s the stuff that probably won’t get patched this week or maybe ever. It’s worth mentioning here Andre Suri, who maintains the PHP packages a lot of Debian and Ubuntu servers pull from. Those packages had fixes all the way back to PHP 7.4, which is an absolutely awesome move. Now, another bit of chaos in this story is who actually found this bug. Open AI says Kali found this using GPT 5.6 Soul as part of Open AI’s Patch the Planet program, and that Open AI led the group that got everyone ready. They’re calling

[04:37] it one of the most impactful vulnerabilities in recent memory. Wiz found this independently, and they say Gemini 4 Argon made an invaluable contribution, and it’s worth noting that Wiz is owned by Google now. Then Kali posted saying let’s set the record straight, saying their researcher was first and pointing to a tweet from August 5th as the proof. And in Kali’s write-up, they say the researcher used no special harnesses and no models that weren’t available to everyone. They picked PHP because they knew its history and had a theory about where the bugs were hiding. And what he’s referring to here is a 2024 security audit by the PHP

[05:09] Foundation that already found the first signs of this exact problem, but nobody could prove it was exploitable, so the fix kept stalling. In other words, that was actually a structural failure, and they’d even scan PHP with Anthropic’s Claude Mythos earlier in the year, and that seemingly missed it, too. So what had changed this time? Well, the bug class itself goes back to a research from 2004. What changed is how far someone who knows where to look can turn an old theory into a working exploit. Wiz says one researcher did in a week what would have taken a world-class team months. And that’s the scary part. None

[05:41] of this is going to slow down. On the same day, Node.js patched a remote code execution bug of its own, and GitLab shipped a fix for I’m rating a full 10 out of 10. Then on the same evening, I’ve literally just seen that Railway announced a breach. They say someone got into the systems that store customer environment variables and for some of them got decrypted values. So API keys, databases, passwords all have been leaked. Nothing links this to PHP to shell, but Railway says it looks like part of a series of attacks on platforms aimed at getting AI provider keys.

[06:12] OpenAI says that PHP to shell is one of several big bugs it’s already found and it expects findings are likely to increase sharply in the coming months. Taylor Otwell, who created Laravel, put this pretty well. He said it probably won’t be the last time and PHP probably won’t be the only language that goes through it. Overall, I think the bug itself was the least interesting part of this story. The fix was ready, the CDN is ready, but it still turned into chaos because news got out a day early and because of AI, a few hours is all it needs for people with AI agents to start building exploits. Disclosure was built for a world where finding the bug was

[06:43] the hard part and I don’t think in that world anymore. So if you’re on PHP anywhere, even on some server you forgot about, go ahead and update it. Let me know what you think about all of this in the comments down below or either subscribe and as always, see you in the next one. >> [music]