Falha na sandbox de HTML do ChatGPT permitia sequestrar contas com um único link

Pesquisadores da Parameter Labs encadearam três falhas distintas, de uma biblioteca de teclado virtual até o CSP do ChatGPT, para executar JavaScript arbitrário e vazar dados de quem abrisse um link compartilhado.

A empresa de segurança Parameter Labs publicou, em outubro de 2026, os detalhes de uma cadeia de exploits que permitia tomar conta de sessões do ChatGPT só com a vítima clicando num link compartilhado. O relato foi comentado por Simon Willison em seu blog no dia 31 de outubro, chamando atenção de quem constrói produtos sobre LLMs para um ponto que costuma ficar invisível: a sandbox que isola código HTML gerado por IA.

O alvo era o recurso que o ChatGPT usa para rodar HTML interativo criado durante a conversa, o que a OpenAI chamava de Canvas e hoje chama de HTML previews. A ideia do recurso é simples: o modelo gera uma página HTML com gráfico, formulário ou app pequeno, e o ChatGPT renderiza isso num iframe isolado, para que o código não consiga ler cookies, tokens ou dados privados da conta logada. Essa isolação (a sandbox) é a única coisa que separa código gerado por um modelo, potencialmente manipulado por um atacante, do resto da aplicação.

A trinca de falhas que furou o isolamento

A Parameter Labs não encontrou uma falha única, e sim uma cadeia onde cada peça sozinha parecia inofensiva. O ChatGPT usa a biblioteca MathLive para renderizar fórmulas matemáticas em gráficos, e essa biblioteca tem um teclado virtual próprio que pode ser acionado pela página principal a partir de uma mensagem postMessage() enviada pelo iframe isolado.

O problema é que o código que recebe essa mensagem na página principal usa innerHTML para inserir o conteúdo recebido. Qualquer iframe sandboxed, incluindo o de HTML previews, podia mandar essa mensagem, e não havia checagem de origem nem de que tipo de frame tinha permissão para chamar aquele código. Na prática, um app HTML gerado por IA podia injetar HTML arbitrário na página principal do ChatGPT, fora da sandbox.

Um exemplo simplificado (ilustrativo, não o código real da OpenAI) mostra o padrão perigoso:

// Página principal: recebe mensagem do iframe sandboxed
window.addEventListener('message', (event) => {
  // Falta checar event.origin e a identidade do iframe
  keyboardContainer.innerHTML = event.data.html;
});

O corretivo mínimo para esse padrão passa por validar origem, tipo de remetente e nunca tratar o payload como HTML de confiança:

window.addEventListener('message', (event) => {
  if (event.origin !== TRUSTED_ORIGIN) return;
  if (event.data.type !== 'keyboard:update') return;
  keyboardContainer.textContent = event.data.text; // nunca innerHTML com dado externo
});

De HTML injetado a JavaScript rodando de verdade

innerHTML não executa diretamente uma tag <script>, então a injeção de HTML sozinha não bastava. Mas ela permitia inserir um novo iframe sem as restrições de sandbox da OpenAI, já que a página principal confiava no conteúdo que ela mesma estava montando.

Faltava ainda contornar o CSP (Content Security Policy, a lista de origens autorizadas a carregar script numa página) do ChatGPT, que bloqueava script inline e só liberava um punhado de domínios. Um desses domínios liberados era o do YouTube, e a Parameter Labs descobriu que o endpoint de oEmbed do YouTube podia ser usado para refletir JavaScript de volta de um jeito que o navegador executava.

Com essas três peças encaixadas (vazamento via postMessage, injeção de iframe sem sandbox via innerHTML, e execução de script via oEmbed do YouTube liberado pelo CSP), o atacante conseguia rodar JavaScript com o mesmo privilégio da página principal do ChatGPT, não mais dentro da sandbox.

O golpe final: roubo de dados por um link compartilhado

Uma vez com JavaScript rodando fora da sandbox, buscar dados privados da conta via chamadas às APIs internas do ChatGPT e exfiltrar o resultado é trabalho padrão de quem já fez pentest em aplicação web: o próprio Willison descreve como "trivial" usar uma referência de imagem para enviar os dados roubados para um servidor controlado pelo atacante, técnica clássica de exfiltração que não deixa rastro visível na tela.

O vetor de entrega tornava o ataque especialmente perigoso: bastava gerar uma URL de compartilhamento do ChatGPT com o HTML malicioso embutido. Qualquer usuário logado que abrisse esse link executava o exploit, e o atacante podia ler dados privados da conta ou agir em nome dela, sem precisar de senha, token ou qualquer interação além do clique.

OpenAI fechou a brecha e pagou uma recompensa de 5 mil dólares, o que considero um valor baixo para uma vulnerabilidade tão séria.

OpenAI closed the hole and paid out a $5,000 bug bounty, which I think was a bit cheap for a vulnerability this serious.Simon Willison, criador do blog Simon Willison's Weblog

O que isso muda para quem constrói agentes e sandboxes próprias

A OpenAI já corrigiu a falha, mas o padrão de erro que a Parameter Labs expôs se repete em qualquer produto que renderize conteúdo gerado por LLM dentro da própria aplicação, de agentes que geram dashboards a ferramentas internas que mostram HTML de resposta de um modelo. Três pontos valem revisão imediata em qualquer sandbox que o time já tenha montado:

• Checagem de origem em postMessage: todo listener de mensagem entre iframe e página principal precisa validar event.origin e o tipo esperado do payload, nunca confiar que só o frame sandboxed vai chamar aquele canal.
• innerHTML é sempre suspeito com dado externo: se o conteúdo pode vir, direta ou indiretamente, de um iframe não confiável ou de saída de modelo, a inserção tem que passar por sanitização explícita ou usar textContent.
• CSP não é lista de domínios "confiáveis em geral": liberar um domínio grande como YouTube para um caso de uso (embutir vídeo) pode abrir uma porta lateral para execução de script via outro endpoint do mesmo domínio, como o oEmbed. Cada entrada do CSP merece justificativa específica, não confiança por reputação da marca.

Para quem constrói agentes que executam ou renderizam código gerado por IA, o caso reforça uma lição que já valia antes dos LLMs: sandbox não é uma linha de configuração isolada, é a soma de todas as superfícies de comunicação entre o conteúdo não confiável e o resto do sistema. Uma falha em cada peça isolada pode parecer de baixo risco; encadeadas, elas chegam a execução de código arbitrário e roubo de conta. Vale revisar cada canal de postMessage, cada uso de innerHTML e cada domínio liberado no CSP como se fosse, individualmente, a última linha de defesa, porque num ataque em cadeia é exatamente isso que ela acaba sendo.

Fonte 1: Simon Willison (https://simonwillison.net/2026/Oct/31/how-we-took-over-chatgpt-accounts/)

How We Took Over ChatGPT Accounts.

Fonte: Simon Willison