# Ataque à OpenAI via upload de imagem: 4 portas

> Published 2026-10-17T01:32:04.987Z on https://www.crazystack.com.br/pt/p/ataque-a-openai-via-upload-de-imagem-4-portas/
> Source video: https://www.youtube.com/watch?v=sT4EVoAx6vI

O ataque à OpenAI via upload de imagem encadeou quatro falhas conhecidas em menos de 72 horas, sem exigir código novo. Um HEIC malformado deu execução de código no servidor do fórum, o SSO do Discourse virou token de conta OpenAI, e o Codex do funcionário abriu pull request no repositório interno.

## O que foi o ataque à OpenAI via upload de imagem

Em setembro de 2026, a Hacktron encadeou quatro falhas para ir de um upload de imagem no fórum público da OpenAI até um pull request no repositório interno. Os pesquisadores pararam após provar o acesso, não leram código-fonte e reportaram pelo Bugcrowd e pelo HackerOne.

A OpenAI é a empresa por trás do ChatGPT; a Anthropic desenvolve o Claude Hacktron é a startup de segurança que conduziu o teste, segundo o próprio relato divulgado. O fórum community.OpenAI.com roda [Discourse](https://www.discourse.org/), software de fórum de código aberto que aceita anexos de imagem.

A cadeia tinha quatro elos: execução de código no servidor do fórum, conversão dessa posição em token de login real, uso das permissões já conectadas a um agente Codex, e alcance final ao monorepo. Nenhum elo exigiu descoberta de vulnerabilidade inédita.

O ponto central do caso é econômico, não técnico. A parte difícil costumava ser transformar um bug de memória em exploit funcional; esse trabalho foi comprimido por um modelo de linguagem em cerca de três horas.

## Porta 1: FastImage, ImageMagick e o overflow no libheif

O upload de um HEIC passou pela checagem do [FastImage](https://github.com/sdsykes/fastimage), que não reconhece esse formato e liberou o arquivo sem validação real. O Discourse então entregou o arquivo ao [ImageMagick](https://imagemagick.org/), que delegou a decodificação ao [libheif](https://github.com/strukturag/libheif), biblioteca que interpreta o formato HEIF/HEIC usado por iPhones.

O servidor rodava libheif 1.19.7 sobre Debian com um heap overflow já conhecido e corrigido upstream. O Debian costuma aplicar correções isoladas em versões antigas em vez de adotar o lançamento mais novo, e a correção ainda não tinha chegado àquela máquina.

Um HEIC construído sob medida sobrescreveu memória fora dos limites do bloco alocado. Isso deu leitura e escrita dentro do processo e, na sequência, execução de código no servidor do fórum. Os pesquisadores confirmaram o acesso lendo um arquivo de sistema direto do servidor.

A lição prática é direta: se sua checagem rápida não identifica um formato, não deixe a ferramenta lenta entregá-lo a um parser desatualizado. Corrija, isole em sandbox ou recuse o formato na entrada.

### O que o Claude fez nessa etapa

O [Claude](https://www.anthropic.com/claude), assistente de IA da [Anthropic](https://www.anthropic.com/), entrou no meio da investigação em uma versão posterior do modelo. Segundo o relato da Hacktron, a versão anterior já havia sinalizado a correção ausente, e a nova escreveu um exploit funcional em cerca de três horas.

O modelo não escolheu o alvo, não desenhou a cadeia e não cuidou da divulgação. Pessoas fizeram essas três coisas. O que a IA comprimiu foi o meio lento da especialização: converter um bug de memória em código que roda em duas arquiteturas de chip diferentes.

## Porta 2: como o SSO do Discourse virou conta OpenAI

O login do fórum passava pelo single sign-on da OpenAI, então uma identidade cobria todos os sites da empresa, o fórum incluído. Uma falha na forma como esse login estava configurado permitiu converter controle do fórum em token de sessão válido para a conta real de uma pessoa.

Não era uma sessão do fórum nem uma conta parecida: era a conta de verdade, com acesso aos produtos conectados a ela. Segundo os pesquisadores, qualquer usuário ou funcionário que já tivesse entrado no fórum de ajuda poderia ter a conta do ChatGPT e do Codex assumida.

O agravante é de arquitetura. O fórum não era hospedado pela OpenAI, e sim na nuvem do Discourse. Um serviço de terceiros na borda da infraestrutura não deveria conseguir emitir identidade para as contas mais sensíveis da empresa.

Para quem opera sistemas parecidos, a regra é separar identidade de aplicação. Um serviço externo pode autenticar o usuário, mas não deve conseguir criar credenciais que valham dentro do domínio principal.

## Porta 3: o que um agente Codex conectado pode alcançar

Logado como funcionário, o atacante herdou o ChatGPT e o [Codex](https://openai.com/codex/), agente de codificação da OpenAI conectado a repositórios reais. O Codex daquele funcionário estava ligado à organização GitHub da empresa.

Uma integração conectada carrega as próprias permissões permanentes. Tudo que o agente pode fazer, uma sessão roubada também pode, sem nova autorização. Os pesquisadores enviaram um prompt pedindo um pull request em OpenAI/OpenAI, o monorepo interno, e o agente executou.

O alcance termina aqui: eles não leram código-fonte, e o pull request era apenas prova de conceito. Assim que demonstraram o acesso, encerraram os testes e abriram o relatório.

A defesa é limitar o raio de explosão. Restrinja o que cada agente e cada integração podem tocar, use escopos mínimos e mantenha esses tokens com validade curta.

### O que a OpenAI fez depois

A OpenAI confirmou a correção cerca de 14 horas após o relatório. O Discourse lançou correção em poucos dias, o Debian publicou um aviso de segurança, e a OpenAI pagou uma recompensa de 6.500 dólares.

A recompensa veio com uma ressalva: testar o fórum Discourse estava fora do escopo declarado, e o valor reconheceu a descoberta do lado OpenAI, não o ataque ao fórum. O elo mais perigoso da cadeia rodava em um servidor que a OpenAI já não tratava como próprio.

## Quais erros comuns esse caso expõe

O caso não revela uma técnica nova. Ele mostra quatro descuidos comuns empilhados: dependência desatualizada, identidade compartilhada entre serviços, integração com permissões amplas e ativos esquecidos na borda.

A tabela abaixo separa cada porta, o erro original e a correção que teria interrompido a cadeia naquele ponto.

| Porta | Erro | Correção que interrompe |
| --- | --- | --- |
| 1. Upload | libheif 1.19.7 sem a correção do overflow | Atualizar, isolar em sandbox ou recusar HEIC |
| 2. SSO | Fórum externo emitindo token de conta principal | Separar identidade do fórum da identidade corporativa |
| 3. Agente | Token do Codex com permissões permanentes | Escopo mínimo e tokens de curta duração |
| 4. Divulgação | Ativo de terceiros fora do escopo | Inventariar e monitorar serviços na borda |

Cada correção age sozinha. Fechar qualquer uma das portas interrompe a sequência, e é por isso que defesa em camadas importa mais do que encontrar o bug perfeito.

O padrão se repete em aplicações comuns. O seu código não chama a biblioteca perigosa diretamente; uma ferramenta três camadas abaixo faz isso, e o ponto fraco fica invisível na auditoria das dependências que você acha que tem.

## O que mudou no custo de atacar

A parte barata nunca foram os bugs. O overflow era público, a correção existia e a falha de login era má configuração. O recurso escasso era a pessoa capaz de encadear tudo e transportar o exploit entre arquiteturas.

O relato da Hacktron resume a mudança: trabalho que exigia uma equipe bem financiada e meses pode ser comprimido em dias ao transformar especialização escassa em processamento barato. Isso não significa que qualquer pessoa executa a cadeia, porque alvo, desenho e divulgação continuaram humanos.

Para quem defende sistemas, a leitura prática é sobre o relógio, não sobre as ferramentas. Se o atacante itera mais rápido, a janela entre a publicação de uma correção e sua aplicação encurta.

Trate a correção pendente como exposição ativa. Priorize dependências de parsing, revisões regulares de backport e testes de escopo das integrações de agentes.

## Perguntas frequentes

- **A OpenAI foi invadida de verdade nesse caso?** Os pesquisadores obtiveram execução de código no servidor do fórum e acesso a uma conta de funcionário, e provaram o alcance chegando a um pull request no monorepo. Eles interromperam os testes imediatamente e não leram código-fonte da empresa.

- **Quais bibliotecas estavam envolvidas na primeira porta?** FastImage fazia a checagem rápida do upload, ImageMagick montava a miniatura e libheif 1.19.7 decodificava o arquivo HEIC. O overflow explorado estava no libheif, em uma versão que o Debian ainda não havia corrigido.

- **O Claude executou o ataque sozinho?** Não. O modelo escreveu um exploit funcional em cerca de três horas, mas a escolha do alvo, o desenho da cadeia e a divulgação responsável foram feitos pelas três pessoas da Hacktron.

- **Qual foi a resposta da OpenAI?** A empresa confirmou a correção cerca de 14 horas após o relatório e pagou 6.500 dólares de recompensa. O Discourse e o Debian publicaram correções em poucos dias, e a recompensa cobriu apenas a parte dentro do escopo.

- **O que devo corrigir primeiro no meu sistema?** Comece pelas dependências que processam arquivos enviados por usuários, depois separe identidades de serviços externos e, por fim, reduza o escopo e o tempo de vida dos tokens de agentes e integrações.

- **O caso prova que modelos de IA substituem especialistas em segurança?** Não. Ele mostra compressão de uma etapa específica, a de transformar um bug de memória em exploit. Julgamento, contexto do alvo e divulgação seguem dependendo de pessoas.

[Source video](https://www.youtube.com/watch?v=sT4EVoAx6vI)