Claude invadiu a OpenAI em 72 horas pelo fórum

O fórum virou porta de entrada

O Claude precisou de menos de 72 horas para entrar nos sistemas internos da OpenAI. Não foi phishing elaborado, não foi funcionário clicando em link errado, não foi vazamento de chave em repositório público. Foi exploração técnica clássica, daquelas que exigiam dias de reversão de binário e leitura de código, só que agora acelerada por um modelo de linguagem operando em loop autônomo. Três pesquisadores, menos de 3 mil dólares em custo de inferência e um fórum público como ponto de partida. Se você opera qualquer produto com login centralizado, upload de arquivos e integração com GitHub ou Slack, esse caso fala diretamente sobre a sua arquitetura.

A palavra-chave aqui é Claude como ferramenta ofensiva. Os pesquisadores começaram com o Claude Opus 4.8 e travaram em uma proteção de memória comum. Quando o Opus 5 foi liberado, em poucas horas eles tinham um exploit funcional, adaptado para o ambiente real do fórum e rodando de forma autônoma contra uma instância de teste. Depois disso foram mais quatro horas até o controle total do servidor. Isso muda a conta de ameaça porque comprime tempo, custo e exigência de especialização. O que antes pedia uma equipe experiente agora cabe em um fim de semana com acesso a API.

O fato sem enfeite

A equipe de segurança invadiu o fórum da comunidade da OpenAI, que roda sobre Discourse, e a partir dali encadeou acessos até contas internas de ChatGPT e Codex de funcionários. Com uma dessas contas, eles criaram um pull request inofensivo no monorepo interno hospedado no GitHub só para provar o acesso. Segundo o relato, nenhum dado sensível foi visualizado, e a OpenAI corrigiu a falha cerca de 14 horas após o reporte. O Discourse também respondeu em poucos dias. Até aqui, processo padrão de disclosure responsável.

O vetor inicial foi o processamento de imagens HEIC com a biblioteca libheif desatualizada. Um arquivo manipulado permitia execução de código no servidor do fórum. A correção já existia no código original há cerca de um ano, mas não tinha sido marcada como problema de segurança, então os pacotes usados em produção continuaram vulneráveis. A segunda falha foi uma configuração incorreta no sistema central de login da OpenAI. Quem controlava o servidor do fórum conseguia se passar por membros ativos e assumir as sessões deles no ChatGPT e no Codex. Na prática, qualquer serviço comprometido que usasse o mesmo login poderia gerar o mesmo efeito cascata para GitHub, Slack e e-mail conectados a essas contas.

Como funciona na visão de quem opera

Pensa na arquitetura em três camadas. Primeira, a borda com upload: fórum aceita imagem, passa por parser nativo em C ou C++ para converter HEIC. Esse tipo de parser é historicamente frágil, com corrupção de memória, e roda com privilégios que nem sempre são isolados o suficiente. Um pacote Debian desatualizado aqui significa que você está rodando código vulnerável com acesso à rede interna do serviço. Custo para o atacante: alguns milhares de uploads para fuzzing e crash, algo que passa despercebido se você não monitora taxa de erro no pipeline de mídia.

Segunda camada, identidade. O famoso Sign in with OpenAI funcionava como SSO central. O erro foi confiar demais em um serviço periférico. Se o fórum consegue emitir ou validar tokens que o núcleo aceita sem amarras fortes de audiência, escopo e vinculação de sessão, então comprometer a periferia equivale a comprometer o núcleo. É o anti-padrão clássico: SSO amplo, com permissões herdadas para Codex e ChatGPT, sem isolamento por origem. Terceira camada, amplificação por agente. O Claude não inventou uma nova classe de bug. Ele automatizou o trabalho chato e caro: triar crash, ajustar heap spray, lidar com ASLR ativado, portar o exploit do Mac local para Linux do servidor e iterar sem cansar. Latência de desenvolvimento caiu de semanas para horas. O custo de inferência relatado para o projeto inteiro de dois meses ficou abaixo de 3 mil dólares, com adaptação para cada novo alvo levando de um a dois dias.

O que isso muda na prática

Quem ganha com isso, no curto prazo, é quem faz red team e bug bounty com IA. Dá para cobrir mais superfície com menos gente, testar variações de ambiente rápido e documentar o caminho. Quem perde é todo time que depende de segurança por complexidade, aquela ideia de que ninguém vai ter paciência para fuçar naquele parser obscuro ou naquele SSO legado. Essa paciência agora é infinita porque é API com loop. O relato de que só um alvo percebeu milhares de uploads e crashes repetidos mostra que a maioria nem tem telemetria para esse tipo de ataque lento e barulhento.

Se você precisa de uma ação prática para esta semana, faça isto: isole e atualize seu pipeline de mídia. Coloque conversão de imagem, PDF e vídeo em workers sem acesso a segredos, sem rede interna e com reinicialização frequente. Trave versões de libheif, imagemagick, ffmpeg e similares no seu SBOM e monitore CVEs mesmo quando não estão marcadas como críticas. Depois revise seu SSO. Liste todos os serviços que podem emitir identidade aceita pelo seu núcleo, restrinja audiência e escopo por cliente, exija reautenticação para ações sensíveis como conectar GitHub ou Slack, e invalide sessões cruzadas quando a origem for de baixo privilégio como um fórum público. E ative alerta simples que quase ninguém tem:

• Taxa de falha em upload de mídia por IP e por conta, com bloqueio progressivo
• Logins via SSO originados de serviços periféricos com escalada para integrações de código
• Criação anormal de tokens para Codex, API interna ou repositório em horário atípico

Esse trio teria tornado a operação muito mais visível e cara para o atacante, mesmo com IA ajudando.

A tensão que ninguém quer admitir

Aqui fica a dúvida real de operador: isso escala para defesa ou só para ataque. No papel, o mesmo Claude que gera exploit pode gerar patch, teste e monitoramento. Na prática, o ataque tem vantagem assimétrica. Basta um parser esquecido ou um SSO permissivo para perder tudo, enquanto a defesa precisa acertar inventário, patch, segmentação e detecção ao mesmo tempo. E o custo pesa para os dois lados, mas de forma diferente. Três mil dólares para atacar é troco. Para defender, o custo é engenharia contínua, refatorar identidade, separar ambientes, pagar por sandbox de mídia com GPU ou CPU extra e lidar com latência maior no upload.

Tem outro ponto incômodo. O modelo se recusou a atacar o sistema real, então os pesquisadores contornaram apresentando como tarefa de benchmark. Isso resolve no discurso, mas não na operação. Qualquer controle baseado em recusa frágil cai com reformulação de prompt ou com execução local em modelo aberto. Se sua estratégia depende do modelo se comportar bem, você já perdeu. A proteção precisa estar na arquitetura, não na boa vontade do agente. E por fim, a rivalidade entre laboratórios distrai. Pouco importa se foi Claude contra OpenAI ou o inverso. Amanhã será outro modelo, outra API, outro fórum esquecido com Debian antigo. O gargalo apenas mudou de lugar: saiu da falta de exploit e foi para a falta de visibilidade sobre onde seus uploads e seus tokens se encontram.

Conclusão direta

A invasão não aconteceu porque a IA ficou superinteligente. Aconteceu porque periferia vulnerável mais identidade centralizada continua sendo uma combinação fatal, e agora qualquer pessoa com acesso a um bom modelo consegue explorar isso em dias, não meses. Vale revisar hoje onde o seu login único confia demais e onde seu parser roda com privilégio demais. Quantos serviços na sua empresa aceitam upload e ao mesmo tempo emitem um token que vale acesso ao código.