Um upload de imagem derrubou a defesa da OpenAI

Claude invadiu a OpenAI e isso deveria incomodar qualquer um que opera infraestrutura com IA hoje. Não foi um ataque de estado, não foi um zero-day exótico em modelo de fronteira, foi uma imagem HEIF maliciosa enviada para o fórum da comunidade. Três pessoas, uma assinatura de cerca de 200 dólares por mês e o modelo certo do outro lado da mesa foram suficientes para encadear duas falhas críticas e chegar até contas de funcionários com acesso a Codex e GitHub. Se você mantém fórum, pipeline de upload ou integrações entre chat e código, esse caso fala diretamente com você.

O desconforto aqui não é só a invasão, é a ferramenta usada para invadir. Um modelo de linguagem fez o trabalho pesado de transformar um bug obscuro de memória em exploit funcional. E falhou com uma versão, para passar de primeira com a versão seguinte. Isso muda a conta de risco para todo time de segurança, porque a barreira entre achar um bug e explorar um bug está caindo rápido demais.

PublicidadeAnuncie aqui336x280 / responsivo

O fato

O time de três pesquisadores da startup Hacktron AI participava de um programa de bug bounty da OpenAI quando encontrou a porta de entrada no dia 25 de julho. O ponto fraco estava no Discourse, o software de terceiros que alimenta o fórum da comunidade da OpenAI. Eles enviaram um arquivo HEIF ou HEIC, o formato padrão de fotos do iPhone, e esse arquivo seguiu para uma cadeia de conversão até virar JPEG.

Nessa cadeia, o Discourse chamou o ImageMagick, um utilitário open source antigo usado para redimensionar imagens. Como o ImageMagick não lida bem com o formato da Apple, ele repassou a decodificação para outra biblioteca chamada libheif. Ali dentro havia um bug de memória que calculava errado a posição de uma imagem sobreposta a outra. Com um arquivo moldado sob medida, os pesquisadores conseguiram sequestrar a execução no servidor do fórum. A partir daí, exploraram uma segunda falha que permitia assumir sessões de ChatGPT e Codex, incluindo contas de funcionários da OpenAI. Uma dessas contas tinha o Codex conectado à organização da OpenAI no GitHub. Eles reportaram tudo e receberam 6.500 dólares. As falhas já foram corrigidas no servidor do Discourse e na OpenAI em 27 de julho.

Como funciona na visão de quem opera

Pensa na arquitetura como três camadas coladas com fita. Camada um, o fórum Discourse exposto à internet e aceitando upload de qualquer usuário. Camada dois, um worker de conversão que pega esse upload e joga para ImageMagick e depois para libheif sem sandbox forte o suficiente. Camada três, identidade e integrações, onde uma sessão de ChatGPT vira chave para Codex e daí para GitHub. O ataque quebrou a camada dois com corrupção de memória e usou isso para pular para a camada três via sequestro de sessão.

O detalhe mais espinhoso para quem opera é que o bug na libheif já tinha sido corrigido pelos mantenedores meses antes, mas sem CVE, sem alerta formal, sem aquele número padrão que faz seu scanner gritar. Sem CVE, dependência transitiva vira ponto cego. O Discourse continuava rodando a versão vulnerável porque nada no processo normal de atualização acusou gravidade. Quem já sofreu com patch silencioso em biblioteca C sabe como isso dói. Você só descobre quando alguém transforma em exploit.

E aqui entra a parte do modelo. Segundo o relato dos pesquisadores, uma versão especial do Opus 4.8 liberada para pesquisa em segurança tentou por várias sessões gerar um exploit funcional e não conseguiu. Horas depois do lançamento do Opus 5, com o mesmo problema e o mesmo contexto, o modelo conseguiu. Em termos de operador, isso sugere um salto em raciocínio sobre memória, offsets, layout e iteração sobre falhas de compilação ou crashes. Não é mágica, é capacidade de manter estado longo, testar hipóteses e ajustar o payload sem perder o fio. A inferência plausível é que o custo de explotação caiu, a latência entre ideia e prova de conceito caiu junto, e o gargalo voltou para onde sempre esteve, higiene de dependências e isolamento.

O custo real por trás do hack

Se você traduzir para custo e latência, o cenário fica ainda mais claro. Antes, explorar um bug de heap em libheif exigia um especialista em binários, horas de fuzzing e depuração manual. Agora, parte desse loop pode ser acelerada por API, com iterações rápidas e baratas. Não elimina o especialista, mas multiplica ele. Para o defensor, isso significa que janela de exposição que antes era de semanas agora pode ser de horas depois que um modelo mais capaz sai do forno.

O que isso muda na prática

Quem ganha com isso no curto prazo são times pequenos de ofensiva e programas de bounty, que agora conseguem fazer mais com menos gente. Quem perde são todos os times que tratam fórum, help center, upload de avatar e conversor de mídia como sistema de baixo risco. Não são mais. Qualquer endpoint que aceita arquivo e passa por biblioteca nativa em C ou C++ precisa ser tratado como fronteira crítica, com sandbox, limites de recurso e atualização agressiva.

  • Isolar conversão de mídia: rode ImageMagick, libheif, ffmpeg e similares em microVM ou container sem rede, sem segredos e com seccomp restritivo.
  • Travar dependências nativas: mapeie o que seu Discourse, WordPress ou portal usa por baixo e force rebuild quando houver commit de segurança mesmo sem CVE.
  • Separar identidade de engenharia: conta de funcionário não deveria ter sessão de chat com acesso direto a GitHub produtivo sem step-up de autenticação e escopo mínimo.

A ação prática para esta semana é simples e direta. Liste todos os pontos onde usuário externo envia arquivo para seu sistema e rastreie qual biblioteca nativa toca esse arquivo. Se você não sabe responder isso de cabeça, você já tem um achado. Depois, verifique se o serviço de conversão roda com as mesmas credenciais do app principal e se um comprometimento ali permite roubo de sessão. No caso da OpenAI, foi exatamente essa ponte entre fórum comprometido e sessão de ChatGPT que transformou um bug chato em acesso sensível.

Isso escala ou só move o gargalo?

A pergunta que fica é incômoda. Se três pessoas com um modelo de prateleira entram na OpenAI, o que um time bem financiado faz com o mesmo acesso. O comentário que circulou sobre nação estado não é hype, é aritmética. O ataque não exigiu acesso interno, só paciência, automação e um modelo que não desiste no meio do exploit. E o fato de o Opus 4.8 falhar e o Opus 5 passar sugere que estamos subindo uma escada de capacidade onde cada degrau destrava uma classe nova de vulnerabilidades exploráveis por quem não é especialista.

Por outro lado, nada disso resolve o problema raiz, só move o gargalo. O bug era conhecido, o patch existia, o processo falhou em propagar. IA mais capaz não cria mais bugs de memória, ela só cobra mais caro pela nossa preguiça em atualizar e isolar. Vale a pena pagar por modelos defensores também, para fuzzing contínuo e triagem de dependências, mas o custo só compensa se o básico estiver feito. Sem inventário de SBOM, sem sandbox de upload e sem separação de sessão e código, você só está dando um alvo mais rápido para um atacante mais rápido.

Conclusão

No fim, a OpenAI pagou 6.500 dólares para descobrir que até gigante tropeça em lib desatualizada e sessão com poder demais. A lição para quem constrói é clara, trate upload como código não confiável e identidade como zona de blast radius. E fica a pergunta no ar, quantos outros fóruns e conversores seus ainda rodam hoje a mesma versão vulnerável sem CVE para avisar.