Um canal indireto no runtime Linux usado para análise de dados podia vazar mensagens, arquivos enviados e saídas geradas pelo modelo sem aviso ao usuário; a correção foi implantada em 20 de fevereiro de 2026.
| Componente | Ambiente Linux isolado usado pelo ChatGPT para execução de código e análise de dados com Python. |
| Vetor | Prompt malicioso ou instruções embutidas em um GPT personalizado acionavam resolução DNS para transportar dados em subdomínios. |
| Impacto | Exfiltração silenciosa de mensagens, conteúdo extraído de arquivos enviados e respostas condensadas pelo modelo, além de possibilidade de canal bidirecional para execução remota no runtime. |
| Prioridade | Considerar a falha corrigida na plataforma desde 20 de fevereiro de 2026 e revisar usos de prompts externos, GPTs personalizados e exposição de dados sensíveis em assistentes com execução de código. |
| Artefatos | Não há CVE, hash, domínio, endereço IP ou payload público específico no material analisado. |
| Mitigação | Controlar uso de GPTs de terceiros, restringir dados sensíveis enviados a assistentes, revisar governança de ferramentas de IA e monitorar integrações externas autorizadas. |
Uma vulnerabilidade no runtime de execução de código do ChatGPT permitia que uma conversa comum fosse convertida em canal de exfiltração sem depender de uma ação externa visível para o usuário. A falha atingia a fronteira entre dois comportamentos esperados da plataforma: de um lado, ferramentas capazes de analisar arquivos, executar Python e produzir respostas a partir de dados sensíveis; de outro, controles que deveriam impedir acesso direto à internet a partir do ambiente de análise de dados. O problema apareceu porque a contenção de tráfego convencional não eliminava todos os caminhos de saída. A resolução DNS continuava disponível como parte do funcionamento normal do ambiente, e essa capacidade podia ser usada como meio de transporte para dados codificados.
O impacto prático era relevante porque o usuário não precisava aprovar uma integração externa, aceitar uma chamada de API ou visualizar um aviso de compartilhamento. Um único prompt malicioso podia instruir o modelo a coletar informações de mensagens futuras, arquivos carregados ou respostas geradas e encaminhar esses dados por um canal lateral. Em um cenário demonstrado com um GPT de finalidade médica, um arquivo PDF com resultados laboratoriais e identificação do paciente foi analisado de forma aparentemente normal, enquanto dados extraídos do documento e a avaliação produzida pelo modelo eram transmitidos para um servidor controlado por atacante. A correção foi implantada em 20 de fevereiro de 2026.
O fluxo de ataque começava com a inserção de uma instrução maliciosa em uma sessão do ChatGPT ou dentro da configuração de um GPT personalizado. No primeiro caso, o usuário podia copiar o texto de uma página, fórum, publicação social ou lista de prompts que prometia produtividade, recursos avançados ou comportamento semelhante a um plano pago. No segundo caso, a lógica ofensiva ficava embutida nas instruções e arquivos de um GPT disponibilizado como assistente especializado. A partir desse ponto, cada nova interação passava a ser uma fonte potencial de coleta: texto digitado pelo usuário, conteúdo extraído de documentos enviados, conclusões produzidas pelo modelo, resumos de contratos, avaliações médicas ou sínteses financeiras.
A exfiltração usava DNS como canal indireto. Em vez de tentar abrir uma conexão HTTP ou outro tráfego de saída bloqueado, o conteúdo era fragmentado em partes compatíveis com nomes de domínio e colocado em rótulos de subdomínio. Quando o runtime resolvia esses nomes, a cadeia recursiva de DNS transportava o hostname consultado até a infraestrutura do atacante, permitindo reconstruir os dados recebidos. O mesmo caminho também podia ser explorado em sentido inverso, com pequenos comandos codificados em respostas DNS e remontados dentro do container. Essa bidirecionalidade permitia estabelecer uma forma de shell remota no ambiente Linux usado para execução de código e análise de dados, fora do fluxo normal de mensagens visíveis ao usuário.
A condição crítica era a diferença entre o modelo mental de isolamento e a superfície real do ambiente. Como o runtime era tratado como um espaço sem acesso direto à internet, o comportamento não era interpretado como transferência externa de dados que exigisse recusa, aviso ou aprovação explícita. A chamada legítima de GPT Actions, por outro lado, tem uma etapa visível de consentimento antes do envio de informações a serviços externos. A falha explorava justamente um caminho que não se apresentava como integração externa, embora atravessasse a fronteira de isolamento por meio de resolução de nomes.
A superfície de risco envolvia conversas nas quais o usuário fornecia dados que o assistente pudesse processar e condensar. Isso inclui mensagens com sintomas, histórico médico, informações financeiras, dívidas, impostos, contratos, documentos de identidade, PDFs corporativos, relatórios internos e qualquer arquivo cujo conteúdo pudesse ser lido pelo modelo. O atacante não precisava necessariamente obter o documento completo. Em muitos casos, a informação mais valiosa seria a saída processada: um diagnóstico textual, uma avaliação jurídica preliminar, uma conclusão sobre risco financeiro, um resumo executivo ou uma extração de nomes, datas, valores e relações.
GPTs personalizados ampliavam a exposição porque removiam a necessidade de convencer a vítima a colar um prompt longo em uma conversa nova. Um assistente apresentado como médico, analista financeiro, revisor de contrato ou ferramenta de produtividade podia incluir instruções maliciosas em sua própria configuração. Embora construtores de GPTs não devessem ter acesso direto às conversas individuais dos usuários, a vulnerabilidade permitia que o próprio assistente acionasse a transmissão seletiva de dados para fora da sessão. Para organizações, o risco era maior em ambientes onde funcionários usam GPTs de terceiros para interpretar documentos internos ou dados pessoais de clientes.
- Conversas com arquivos enviados para análise, especialmente PDFs com dados pessoais, laboratoriais, financeiros ou contratuais.
- GPTs personalizados de terceiros que recebem instruções, documentos ou perguntas sobre dados sensíveis.
- Sessões em que o runtime de análise de dados executa código e consegue acionar resolução DNS mesmo sem acesso convencional à internet.
- Saídas geradas pelo modelo que condensam informações sensíveis em formato curto e mais fácil de exfiltrar.
A investigação defensiva depende do ponto de observação disponível. Usuários finais normalmente não têm acesso a logs do runtime interno do provedor, portanto a capacidade de hunting direto no container é limitada. Em ambientes corporativos, a prioridade é revisar governança e registros de uso: quais equipes enviaram dados sensíveis a assistentes com execução de código, quais GPTs personalizados foram usados, quais integrações externas foram aprovadas e quais fluxos envolveram documentos regulados. A ausência de aviso na interface não deve ser usada como evidência suficiente de que nenhum dado saiu durante o período vulnerável.
Para equipes que operam gateways, proxies DNS corporativos ou soluções CASB/SSE, a telemetria útil está na correlação entre uso de ferramentas de IA e padrões anômalos de resolução. O canal descrito depende de subdomínios com dados codificados, o que pode produzir consultas longas, alta entropia, volume incomum de rótulos e domínios recém-observados. Esses sinais não confirmam exploração isoladamente, mas ajudam a identificar túneis DNS em geral. No lado de identidade e SaaS, também é importante diferenciar chamadas legítimas de GPT Actions, que têm autorização explícita, de interações com GPTs de terceiros sem necessidade operacional clara.
- Consultas DNS com subdomínios longos, alta entropia, muitos rótulos ou volume repetitivo associado a sessões de ferramentas de IA.
- Uso de GPTs personalizados desconhecidos por usuários que manipulam documentos médicos, financeiros, jurídicos ou corporativos internos.
- Histórico de upload de PDFs, planilhas ou contratos em assistentes que executam análise de dados.
- Aprovações de GPT Actions para serviços externos que não correspondem a fluxos de negócio documentados.
- Relatos de respostas do assistente afirmando que dados permaneceram internos sem evidência técnica independente.
A resposta imediata para essa falha específica é considerar a correção de plataforma implantada em 20 de fevereiro de 2026. Como o componente vulnerável era parte do ambiente de execução administrado pelo provedor, não há pacote local, versão de biblioteca, configuração de cliente ou patch de endpoint a aplicar pelo usuário. Ainda assim, a correção técnica não elimina o problema operacional de base: assistentes com execução de código, leitura de arquivos e integrações externas devem ser tratados como ambientes de processamento sensível, não como simples caixas de texto.
Organizações devem reduzir a exposição por política e por controle técnico. Dados regulados ou confidenciais só devem ser enviados a assistentes aprovados, com contrato, retenção, auditoria e configuração avaliados. GPTs de terceiros precisam passar por revisão antes de uso com documentos internos, principalmente quando prometem análise especializada. Prompts copiados de fontes públicas devem ser tratados como código não confiável quando instruem o modelo a executar etapas longas, manipular arquivos ou acionar ferramentas. Quando houver suspeita de exposição no período anterior à correção, a contenção deve focar nos dados enviados, nos usuários envolvidos e nas obrigações de privacidade aplicáveis.
Equipes de segurança também devem ajustar seus modelos de ameaça para runtimes de IA. Bloquear conexões HTTP diretas não basta quando camadas auxiliares, como DNS, continuam atravessando o isolamento. Controles de saída precisam incluir resolução de nomes, tamanhos de consulta, domínios permitidos, resposta de resolvedores e canais usados por bibliotecas de sistema. Em paralelo, avaliações de segurança de IA devem verificar se o modelo reconhece transferências indiretas como saída de dados e se eventos desse tipo geram logs, alertas e pontos de consentimento compreensíveis para o usuário.
- Inventariar GPTs personalizados usados pela organização e bloquear assistentes de terceiros sem justificativa operacional.
- Proibir envio de documentos sensíveis a ferramentas de IA não aprovadas, incluindo PDFs médicos, contratos, relatórios financeiros e dados de clientes.
- Revisar prompts reutilizados de fontes públicas e remover instruções opacas, codificadas ou voltadas a execução de ferramentas.
- Correlacionar uso de assistentes de IA com telemetria DNS e alertas de túnel DNS no período de exposição.
- Atualizar políticas de AppSec, privacidade e DFIR para tratar ambientes de execução de IA como superfícies de processamento e exfiltração.
0 Comentários