Uma ligação partilhada do ChatGPT podia executar código malicioso e ler conversas privadas

Uma única ligação de partilha do ChatGPT — do tipo que se cola todos os dias em e-mails, pedidos de suporte e redes sociais — bastava para executar o código de um atacante na sessão de quem a abrisse. A partir daí, o código podia listar as conversas recentes da vítima, abrir uma conversa privada que nunca tinha sido partilhada e enviar o seu conteúdo para um servidor externo. A OpenAI já corrigiu o problema e os utilizadores do ChatGPT não precisam de fazer nada.

O que aconteceu

A falha foi comunicada através do programa de recompensas por bugs da OpenAI a 18 de outubro e corrigida oito dias depois. A OpenAI reproduziu tanto a execução de código como o acesso às conversas privadas, elevou a gravidade de P2 para P1 — a sua categoria mais grave — e aplicou a correção em duas versões do front-end web do ChatGPT. A 26 de outubro, ambas as versões já rejeitavam as mensagens de que o ataque dependia. Foi paga uma recompensa de 5000 dólares.

A demonstração foi um teste controlado entre contas separadas. Não há registo de a técnica ter sido usada contra utilizadores reais.

Como funcionava o ataque

O isco era uma conversa partilhada de aspeto normal. A vítima não tinha de instalar nada, iniciar sessão através do atacante nem aderir a um espaço de trabalho. Na versão mais fiável, abria a ligação e carregava uma vez no botão Preview do ChatGPT; uma variante posterior abria a pré-visualização automaticamente, pelo que bastava visitar a ligação.

O ataque encadeava três decisões de design que, isoladamente, pareciam inofensivas:

1. Uma pré-visualização isolada. O ChatGPT pode apresentar um bloco de HTML de uma conversa como uma pequena página web. Essa pré-visualização corre numa moldura isolada, num endereço separado, e não consegue ler a página principal do ChatGPT. Esse isolamento aguentou.
2. Um listener demasiado confiante. A mesma conversa continha um gráfico interativo que carregava a biblioteca MathLive na página principal do ChatGPT. O MathLive deixava ativo um listener para mensagens sobre o seu teclado no ecrã — sem verificar que moldura as tinha enviado.
3. HTML dentro de um «esquema de teclado». Essas mensagens podiam transportar HTML em bruto como dados de esquema de teclado. Assim, a pré-visualização isolada conseguia enviar uma mensagem através da fronteira entre molduras e fazer com que o seu HTML fosse inserido na página principal, de confiança.

Esse HTML injetado criava uma nova moldura, sem isolamento, que o navegador tratava como parte de chatgpt.com. A política de segurança de conteúdo bloqueava scripts inline, mas permitia scripts servidos pelo YouTube, pelo que a carga final era obtida a partir daí. A correr com todo o acesso web da vítima, o código chamava diretamente as APIs autenticadas do ChatGPT — o seu alcance ia muito além do que estivesse no ecrã. Em princípio, podia agir em nome da vítima em toda a conta.

O passo pelo YouTube foi apenas um contorno à política de segurança, não a causa de fundo. Bloqueá-lo, por si só, deixaria ainda uma pré-visualização não fiável capaz de injetar HTML no site principal.

Porque é que isto importa

Os assistentes de IA guardam cada vez mais material sensível: código-fonte, contratos, dados de clientes, planos internos. Uma ligação partilhada é um formato de confiança e fácil de abrir, e este caso mostra como uma funcionalidade pensada para a conveniência pode tornar-se um vetor de ataque. É também um exemplo clássico de como um bom isolamento pode ser anulado por um componente de terceiros do outro lado do muro: bastou um único handler de mensagens sem verificação de origem.

O que fazer

• Utilizadores do ChatGPT: não há nada a instalar nem a repor — a correção é do lado da OpenAI. Ainda assim, tenha cuidado com conversas partilhadas por remetentes desconhecidos e evite carregar em Preview em conteúdos em que não confia.
• Organizações que usam assistentes de IA: tratem o histórico de conversas como dados sensíveis. Definam regras sobre o que pode ser lá colocado e revejam que contas e integrações têm acesso.
• Equipas web e de produto: auditem cada listener de postMessage no vosso código e nas bibliotecas incluídas. Validem a origem do remetente, nunca aceitem HTML em bruto através de um canal de mensagens e considerem qualquer script de terceiros permitido pela política de segurança de conteúdo como parte da vossa superfície de ataque.

Falhas como esta vivem nas junções entre componentes — um listener numa biblioteca, uma exceção de política noutra. É precisamente o tipo de problema que a nossa revisão de código assistida por IA foi criada para detetar: acompanha o percurso dos dados não fiáveis pelo front-end e pelas dependências, assinalando verificações de origem em falta e inserções de HTML inseguras antes de chegarem a produção.