Pesquisadores usam Claude Opus 5 para hackear o fórum da OpenAI, tomar contas de ChatGPT/Codex e alcançar o repositório interno

Notícia

Pesquisadores usam Claude Opus 5 para hackear o fórum da OpenAI, tomar contas de ChatGPT/Codex e alcançar o repositório interno

Rodrigo ColissiRodrigo Colissi
18 de setembro de 202611 min de leitura—
VulnerabilidadesAICloud

Introdução

No dia 25 de julho de 2026, a equipe de pesquisa Hacktron (laboratório de segurança ofensiva especializado em IA) anunciou ter comprometido o fórum comunitário da OpenAI (empresa de pesquisa em inteligência artificial, criadora do ChatGPT) — community.openai.com — através de uma cadeia de exploração que começou com o upload de uma imagem HEIC maliciosa. O ataque, conduzido com o auxílio do recém-lançado Anthropic (empresa de IA responsável pelo Claude) Claude Opus 5, escalou de uma vulnerabilidade remota no decoder de imagens libheif (CVE-2026-32882) para o takeover total de contas ChatGPT e Codex de funcionários da OpenAI, culminando no acesso ao repositório interno de código-fonte da empresa.

A operação foi coordenada e divulgada hoje (18/09/2026) após a correção completa por parte da OpenAI e do Discourse (plataforma de fórum open-source utilizada pela comunidade) em aproximadamente 14 horas. A OpenAI recompensou os pesquisadores com US$ 6.500.

Contexto

Esta não é uma falha isolada. O caso expõe como a federação de identidade entre sistemas periféricos (um fórum) e serviços críticos (ChatGPT, Codex e GitHub corporativo) pode transformar uma vulnerabilidade de processamento de imagem em uma ameaça ao núcleo do negócio. Para o ecossistema brasileiro, o incidente serve como alerta: organizações que utilizam Discourse, ImageMagick ou processam uploads de imagens HEIC/HEIF/AVIF podem estar expostas à mesma cadeia de ataque.

O cenário também marca um ponto de inflexão na capacidade de modelos de linguagem auxiliarem — e acelerarem drasticamente — a engenharia de exploração de vulnerabilidades. Enquanto o Claude Opus 4.8 falhou em produzir um exploit confiável com ASLR ativado, o Claude Opus 5, lançado um dia antes da operação, produziu o exploit funcional em questão de horas.

A cadeia de exploração: do upload de imagem ao monorepo

HEIC/HEIF, FastImage e o bypass

O fórum da OpenAI roda sobre o Discourse, que utiliza a biblioteca FastImage para validar metadados de imagens no upload. FastImage, no entanto, não suporta os formatos HEIC (High Efficiency Image Coding — formato de imagem compactado usado por dispositivos Apple) e HEIF (High Efficiency Image File Format — container que abriga HEIC e outros codecs). Quando um arquivo HEIC/HEIF é enviado, o Discourse passa o processamento para o ImageMagick (conjunto de ferramentas de linha de comando para manipulação de imagens), que por sua vez carrega a biblioteca libheif (decodificador open-source de HEIC/HEIF).

O container Docker do Discourse utilizava Debian 12 com libheif 1.19.7, uma versão que não recebera os backports de segurança necessários. O Debian 13, na época, ainda distribuía a versão vulnerável 1.19.8. A correção upstream existia, mas não foi identificada como correção de segurança e não recebeu CVE — o que atrasou o backport.

Heap overflow no libheif (CVE-2026-32882)

Ao decodificar um arquivo HEIC malicioso, a libheif 1.19.7 apresenta um heap-buffer overflow — uma condição em que o programa escreve dados além do limite da memória alocada no heap (região de memória dinâmica do processo). Isso concede primitivas de leitura e escrita fora dos limites (OOB read/write) ao atacante, permitindo corromper a memória do processo e desviar o fluxo de execução.

O commit que corrigiu o problema no upstream (85e21ad) simplificava o cálculo de área de sobreposição de overlays no decoder, mas não foi sinalizado como correção de segurança. O Debian publicou posteriormente o aviso DSA-6417-1, alertando que a falha poderia causar negação de serviço, vazamento de memória ou execução arbitrária de código.

Claude Opus 4.8: exploit funcional apenas sem ASLR

Os pesquisadores da Hacktron — Harsh Jaiswal, Mohan Pedhapati e Rahul Maini — iniciaram uma sessão com o Claude Opus 4.8 em 23 de julho, fornecendo a imagem Docker do Discourse e pedindo uma auditoria de segurança do pacote libheif instalado. O modelo identificou o heap overflow e produziu um exploit que alcançava execução de código, mas apenas com ASLR (Address Space Layout Randomization — mecanismo que randomiza endereços de memória para dificultar exploração) desabilitado. Múltiplas tentativas de tornar o exploit confiável com ASLR ativado e com o alocador jemalloc (alocador de memória usado pelo Discourse, alternativo ao glibc malloc) não tiveram sucesso.

Claude Opus 5: o divisor de águas

Na noite de 24 de julho, a Anthropic lançou o Claude Opus 5. A equipe iniciou uma nova sessão com o mesmo problema. Em aproximadamente três horas, o modelo produziu um exploit funcional para ARM64 (arquitetura de processadores usada em Macs Apple Silicon) em um Mac local. Em seguida, os pesquisadores pediram que portasse o exploit para o ambiente x86-64 + jemalloc do Discourse — e conseguiu.

Às 06:00 UTC de 25 de julho, a equipe confirmou RCE local através do upload de uma imagem manipulada. Em seguida, colocaram o Opus 5 em um loop autônomo contra uma instância Discourse Cloud própria, usando o domínio rce.ee/ctf-forum para simular um cenário de Capture The Flag (o modelo se recusava a escrever exploits para instâncias remotas reais). Às 10:00 UTC, o agente havia obtido RCE na instância Cloud e lido /etc/hosts. Com o exploit gerado, a equipe replicou o ataque no fórum real da OpenAI.

Do fórum ao monorepo: a falha de SSO

A RCE no fórum, por si só, não exporia o repositório interno da OpenAI. O vetor crítico foi uma má configuração no sistema de identidade federada (SSO) da OpenAI: a sessão comprometida no Discourse atravessou as fronteiras de identidade, permitindo o takeover sem interação (no-interaction account takeover) de contas ChatGPT e Codex de funcionários ativos do fórum.

Como essas contas estavam conectadas ao GitHub corporativo da OpenAI, os pesquisadores usaram a conta Codex de um funcionário para abrir um pull request inócuo de número 1186742 no monorepo privado openai/openai — prova de acesso sem expor código revisado. O Wall Street Journal reportou de forma independente que os pesquisadores alcançaram uma conta ChatGPT de funcionário e puderam propor alterações no repositório confidencial.

Linha do tempo da resposta

  • 25/07, 06:00 UTC — RCE confirmada no Discourse local
  • 25/07, 08:00–10:00 UTC — Submissão do relato à OpenAI via Bugcrowd (após confirmar o impacto entre produtos)
  • 25/07, 13:30–15:30 UTC — Acesso à conta de funcionário, PR 1186742 aberto; testes encerrados
  • 25/07, 22:49:45 UTC — OpenAI confirma correção (aproximadamente 14 horas após a submissão)
  • 28/07 — Discourse publica o advisory GHSA-vhm9-85gw-x335 com patch e orientações de rebuild

A OpenAI recompensou US$ 6.500, esclarecendo que testar o fórum em si estava fora do escopo do programa de bug bounty — o valor reconheceu a descoberta do lado OpenAI, não a ação contra o Discourse.

Não foi autônomo: IA comprimiu engenharia, humanos dirigiram

Os pesquisadores enfatizam que a operação não foi totalmente autônoma. Expertise humana permaneceu necessária para direcionar as sessões, validar resultados e gerenciar a divulgação responsável. O que a IA fez foi comprimir o tempo de engenharia de exploração — trabalho que normalmente exigiria semanas de um time especializado foi reduzido a horas.

O projeto mais amplo da Hacktron, batizado de HEIF Heist, rastreou a mesma vulnerabilidade libheif através de Slack, Meta, GitHub Enterprise, Ruby on Rails e frameworks Node.js como Next.js, Astro e Gatsby — demonstrando que a dependência de uma única biblioteca de decodificação de imagens cria uma superfície de ataque sistêmica.

Como se proteger

Atualizar libheif e libde265. Instale as versões mais recentes com patches de segurança através dos canais oficiais de sua distribuição. A versão upstream segura mais recente é a v1.23.4 (setembro de 2026). Distribuições podem ter backports sob números de versão mais antigos — verifique o advisory específico.

Isolar o processamento de imagens em sandboxes efêmeras. Dada a complexidade do formato ISO Base Media File Format e o ritmo de atualizações do decoder, novas falhas de segurança de memória são prováveis. Ambientes de produção que não necessitam de decodificação HEIC/HEIF/AVIF de fontes não confiáveis devem desabilitá-la. Quando necessário, isole o pipeline de conversão dentro de sandboxes descartáveis e com recursos limitados.

Restringir o ImageMagick via security policy. Configure a política de segurança do ImageMagick para aceitar apenas formatos estritamente necessários (GIF, JPEG, PNG) e limitar recursos (memória, tempo de processamento, disco). A política de segurança nativa do ImageMagick permite essa restrição.

Revisar a federação de identidade entre sistemas. O vetor crítico deste incidente não foi a RCE isolada, mas a capacidade de uma sessão comprometida no fórum atravessar as fronteiras de identidade para ChatGPT e Codex. Toda aplicação conectada a um SSO corporativo deve ser tratada como parte da superfície de ataque — o que inclui revisar o escopo de confiança federada entre sistemas periféricos e sistemas críticos.

Para autogestores de Discourse: execute git pull seguido de ./launcher rebuild app a partir de /var/discourse. Uma atualização via interface web pode não substituir a imagem Docker subjacente. Clientes do Discourse Cloud já foram corrigidos automaticamente.

Conclusão

A operação da Hacktron demonstra, na prática, o fim de uma suposição de segurança que muitos consideravam implícita: a de que transformar uma vulnerabilidade de memória em um exploit confiável continuaria sendo caro, lento e restrito a equipes especializadas. O Claude Opus 5 comprimiu semanas de trabalho em horas. A falha de identidade federada fez o resto.

Para organizações de todos os portes, a lição é clara: dependências de software obscuras (como libheif) e a federação de identidade entre sistemas precisam estar no radar de segurança — porque hoje, um upload de imagem pode levar ao código-fonte interno.

O que é um heap-buffer overflow?

Um heap-buffer overflow ocorre quando um programa escreve dados além do espaço alocado na memória dinâmica (heap). Isso pode corromper dados adjacentes, causar negação de serviço ou permitir que um atacante desvie o fluxo de execução do programa para código arbitrário.

Por que o Claude Opus 4.8 não conseguiu fazer o exploit funcionar com ASLR?

ASLR randomiza os endereços de memória onde bibliotecas e estruturas do processo são carregadas, tornando mais difícil prever para onde desviar a execução. O Opus 4.8 não conseguiu superar essa randomização combinada com o alocador jemalloc usado pelo Discourse. O Opus 5, lançado um dia depois, conseguiu adaptar o exploit para esse ambiente.

Este ataque foi totalmente autônomo?

Não. Os pesquisadores da Hacktron enfatizam que a IA não operou de forma independente — humanos dirigiram as sessões, validaram os resultados, gerenciaram a divulgação e decidiram quando interromper os testes. A IA comprimiu o trabalho de engenharia de exploração que normalmente levaria semanas.

Qual foi o papel da falha de SSO da OpenAI?

A RCE no fórum Discourse não dava acesso direto ao repositório. Uma má configuração no sistema de identidade federada (SSO) da OpenAI permitiu que a sessão comprometida fosse usada para assumir contas ChatGPT e Codex de funcionários ativos do fórum — contas que estavam conectadas ao GitHub corporativo da OpenAI.

Que tipo de recompensa a OpenAI pagou?

A OpenAI pagou US$ 6.500 pela descoberta do lado OpenAI (a falha de SSO). A empresa esclareceu que testar o fórum community.openai.com estava explicitamente fora do escopo do programa de bug bounty.

O que é CVE-2026-32882?

CVE-2026-32882 é o identificador atribuído ao heap-buffer overflow na biblioteca libheif nas versões 1.19.7 e anteriores. A falha permite que imagens HEIC maliciosas causem leitura/escrita fora dos limites da memória, podendo levar à execução arbitrária de código.

O que é o HEIF Heist?

HEIF Heist é um projeto de pesquisa da Hacktron que rastreia a vulnerabilidade libheif em cascata por dezenas de plataformas e frameworks — Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro, Gatsby — demonstrando o impacto sistêmico de uma única dependência de decodificação de imagens.

Como saber se minha organização está vulnerável?

Se sua aplicação processa imagens enviadas por usuários e aceita formatos HEIC/HEIF/AVIF, é altamente provável que esteja afetada. Verifique a versão instalada do libheif e libde265 através do gerenciador de pacotes da sua distribuição. Considere desabilitar decodificação HEIC/HEIF se não for necessária para seu caso de uso.

Fontes e leituras adicionais

Gostou? Receba novos conteúdos por e-mail.

Entre na comunidade

Discussões técnicas e novidades em primeira mão.