Vulnerabilidades em ambientes de IA permitiam canal DNS oculto no runtime do ChatGPT e abuso de nomes de ramos do GitHub para execução de comandos no Codex.
| Componente | ChatGPT com runtime Linux usado para execução de código e análise de dados; OpenAI Codex em fluxos integrados ao GitHub. |
| Vetor | No ChatGPT, um prompt malicioso ou um GPT personalizado adulterado podia acionar comunicação DNS codificada pelo runtime. No Codex, comandos podiam ser contrabandeados pelo parâmetro de nome de ramo do GitHub durante a criação de tarefas. |
| Impacto | A falha do ChatGPT podia exfiltrar mensagens, arquivos enviados e conteúdo sensível sem aviso ao usuário; a falha do Codex podia expor tokens de acesso do GitHub e permitir execução de comandos dentro do contêiner do agente. |
| Prioridade | Confirmar que as correções aplicadas pela OpenAI estão efetivas, revisar integrações de agentes de IA com repositórios e monitorar padrões anômalos de DNS, criação de tarefas e uso de tokens GitHub. |
| Correção | A vulnerabilidade do Codex foi corrigida em 5 de fevereiro de 2026; a falha do ChatGPT foi tratada em 20 de fevereiro de 2026. |
| Artefatos | O problema do Codex afetava ChatGPT website, Codex CLI, Codex SDK e Codex IDE Extension. |
| Exploração | O contexto informado afirma que não há evidência de exploração maliciosa da falha do ChatGPT. |
A OpenAI corrigiu duas vulnerabilidades distintas em ambientes de IA que ampliam a superfície de risco quando assistentes passam a operar como ambientes computacionais completos. A primeira falha afetava o ChatGPT e estava relacionada ao runtime Linux usado para execução de código e análise de dados. Embora o produto tivesse controles para impedir compartilhamento não autorizado e requisições externas diretas, a vulnerabilidade explorava um caminho lateral de comunicação baseado em DNS, permitindo transformar uma conversa aparentemente comum em um canal de exfiltração sem aviso visível ao usuário.
O impacto técnico do problema no ChatGPT estava no desalinhamento entre o modelo de segurança assumido pelo sistema e as capacidades reais do ambiente de execução. A plataforma tratava o runtime como isolado para fins de saída de dados, mas a resolução DNS podia ser usada como transporte oculto. Com dados codificados em consultas DNS, um agente malicioso podia vazar mensagens, arquivos enviados e outros conteúdos sensíveis sem acionar um diálogo de consentimento, sem exigir aprovação explícita e sem apresentar ao usuário um sinal claro de que informação estava deixando a sessão.
A segunda vulnerabilidade envolvia o OpenAI Codex, agente de engenharia de software baseado em nuvem. O problema estava no processamento de nomes de ramos do GitHub durante a criação de tarefas. Por sanitização insuficiente de entrada, um atacante podia inserir comandos por meio do parâmetro de nome de ramo em uma requisição HTTPS POST para a API de backend do Codex. O resultado condicionado pelo fluxo descrito era execução de comandos dentro do contêiner do agente e acesso a dados de credenciais usados pelo próprio Codex para autenticação no GitHub.
Essas correções expõem uma mudança operacional relevante para equipes de segurança: agentes de IA não devem ser tratados apenas como interfaces conversacionais. Quando o agente executa código, manipula arquivos, interage com repositórios, recebe comentários em pull requests ou acessa tokens de terceiros, ele passa a compor uma fronteira de aplicação e identidade. A defesa precisa cobrir entrada de prompts, parâmetros vindos de sistemas externos, runtime, rede, contêineres, permissões de repositório e trilhas de auditoria associadas ao uso do agente.
Na falha do ChatGPT, o vetor começava por conteúdo controlado pelo atacante inserido no fluxo de interação do usuário. O contexto descreve dois cenários principais: um usuário convencido a colar um prompt malicioso sob pretexto enganoso, ou um GPT personalizado já preparado com lógica maliciosa embutida. A diferença operacional é importante. No primeiro caso, a engenharia social depende de ação explícita do usuário dentro de uma conversa. No segundo, o comportamento hostil pode estar encapsulado no próprio GPT, reduzindo a necessidade de convencer a vítima a inserir manualmente uma instrução especial a cada sessão.
O mecanismo abusado não era uma requisição externa comum exibida como navegação, chamada de API ou transferência direta de arquivo. A técnica utilizava DNS como canal de transporte oculto, codificando informações em consultas geradas pelo runtime Linux. Como o sistema assumia que aquele ambiente não poderia enviar dados diretamente para fora, o comportamento não era classificado como transferência externa que exigiria resistência do modelo ou mediação do usuário. Essa condição cria um ponto cego de segurança porque a ação ocorre abaixo da camada conversacional esperada, em uma área tradicionalmente tratada como infraestrutura auxiliar.
O contexto também indica que o mesmo caminho de comunicação poderia ser usado para estabelecer acesso remoto ao runtime Linux e alcançar execução de comandos. Para fins defensivos, o ponto relevante não é reproduzir a cadeia, mas reconhecer que a existência de saída DNS não controlada em um ambiente de execução de IA pode transformar dados de sessão em tráfego externo codificado. Isso inclui conteúdo digitado pelo usuário, arquivos carregados para análise, trechos de código, documentos corporativos e outros materiais processados pela ferramenta durante tarefas legítimas.
No Codex, a cadeia se concentra em entrada não confiável originada do GitHub. O nome do ramo era consumido durante a criação de tarefas no backend do Codex e, por validação insuficiente, podia carregar comandos arbitrários. A execução acontecia dentro do contêiner do agente usado para processar a tarefa. Como esse agente precisava autenticar no GitHub para operar sobre repositórios, o ambiente continha tokens sensíveis, incluindo GitHub User Access Token e, conforme o contexto, possibilidade de abuso envolvendo GitHub Installation Access tokens.
O fluxo de acionamento citado envolve um ramo malicioso e a referência ao Codex em um comentário de pull request. Nessa condição, o agente iniciava um contêiner de revisão de código, criava uma tarefa contra o repositório e ramo fornecidos e processava a entrada contaminada. O risco decorrente era grave porque o token usado para autenticação podia conceder acesso de leitura e escrita ao código da vítima, além de abrir um caminho de movimentação entre repositório, agente de IA e recursos de desenvolvimento. A falha foi reportada em 16 de dezembro de 2025 e corrigida em 5 de fevereiro de 2026.
A superfície do ChatGPT envolve sessões nas quais usuários submetem conteúdo sensível para análise e usam recursos de execução de código ou processamento de arquivos. O risco cresce em ambientes corporativos onde colaboradores carregam documentação interna, dados de clientes, propriedade intelectual, planilhas, logs, código-fonte ou artefatos de investigação. Mesmo sem evidência de exploração maliciosa no contexto, a classe da falha mostra que controles nativos do fornecedor podem não ser suficientes quando o agente possui um runtime com saídas de rede indiretas.
A superfície do Codex fica concentrada em integrações de desenvolvimento. O contexto cita ChatGPT website, Codex CLI, Codex SDK e Codex IDE Extension como artefatos afetados. Também há exposição em fluxos de revisão de código nos quais o agente é acionado por comentários em pull requests e consome nomes de ramos do GitHub. Repositórios compartilhados aumentam o impacto porque um atacante com capacidade de influenciar ramo, pull request ou parâmetros processados pelo agente pode atingir usuários que interagem com o mesmo projeto.
O risco não deve ser lido apenas como uma vulnerabilidade de interface. Em agentes de codificação, o token do GitHub é um ativo de alto valor operacional porque conecta a sessão do agente ao controle de versão, histórico, permissões de escrita e automações de engenharia. Se o contêiner do agente permite execução de comandos derivados de entrada não confiável, a fronteira de segurança passa a incluir isolamento do contêiner, escopo do token, política de comentários que acionam o agente, validação de metadados do repositório e monitoramento de saídas externas.
- Sessões do ChatGPT com arquivos enviados, mensagens sensíveis e tarefas de análise executadas no runtime Linux.
- GPTs personalizados que possam incorporar instruções maliciosas capazes de acionar comportamento não esperado pelo usuário.
- Fluxos do Codex que processam nomes de ramos do GitHub durante criação de tarefas no backend.
- Ambientes que usam ChatGPT website, Codex CLI, Codex SDK ou Codex IDE Extension com acesso a repositórios GitHub.
- Revisões de pull request nas quais comentários mencionam o agente e fazem o Codex criar contêineres de revisão.
Para a falha do ChatGPT, a telemetria mais útil está em camadas de rede e governança de uso de IA. Equipes que intermediam acesso corporativo a ferramentas de IA devem revisar se há logs de DNS, egress filtering e inspeção de padrões anômalos associados a sessões de análise de código ou arquivos. A anomalia esperada não é uma conexão HTTP direta para um destino suspeito, mas uma sequência de consultas DNS com alta entropia, volumes incomuns, subdomínios longos ou padrões compatíveis com codificação de dados.
Em endpoints e gateways corporativos, a investigação deve correlacionar uso de ChatGPT com horários de upload de arquivos sensíveis, execução de tarefas de análise e picos de DNS que não se explicam por navegação normal. Como o contexto não fornece domínios, IPs ou hashes, a abordagem defensiva deve ser comportamental. O objetivo é identificar canais de saída que não deveriam existir para uma sessão de IA, especialmente quando o usuário não recebeu alerta de transferência externa e não aprovou compartilhamento de dados.
No Codex, os sinais principais estão em auditoria do GitHub, logs de criação de tarefas do agente, eventos de pull request, uso de tokens e execução de contêineres. A caça deve buscar nomes de ramos atípicos, caracteres inesperados em metadados de ramificação, tarefas criadas imediatamente após menções ao Codex em comentários e atividade de token que não combine com a intenção declarada da revisão. Também é importante verificar se houve acesso de leitura ou escrita fora do conjunto de arquivos esperado para a tarefa.
A exposição de tokens exige análise de uso posterior. Mesmo que a falha tenha sido corrigida, tokens que tenham sido acessíveis no período vulnerável devem ser tratados como credenciais potencialmente sensíveis quando houver evidência de execução anômala. A investigação deve revisar operações autenticadas no GitHub, alterações em repositórios, criação de ramos, comentários automatizados, acessos a código e eventos de instalação. A ausência de IoCs públicos no contexto reforça a necessidade de detecção por comportamento, escopo de permissão e sequência temporal.
- Consultas DNS com subdomínios longos, alta entropia ou volume incomum durante sessões de IA com análise de arquivos.
- Uso de GPTs personalizados associado a acesso a conteúdo sensível sem aprovação explícita de transferência externa.
- Nomes de ramos do GitHub contendo padrões incomuns para convenções internas de versionamento.
- Criação de tarefas do Codex logo após menções ao agente em comentários de pull request.
- Uso de GitHub User Access Token ou GitHub Installation Access tokens fora do padrão esperado da revisão de código.
- Operações de leitura ou escrita em repositórios que não se alinham ao escopo do pull request analisado.
A primeira ação é confirmar que os ambientes afetados estão cobertos pelas correções da OpenAI: 20 de fevereiro de 2026 para a falha do ChatGPT e 5 de fevereiro de 2026 para a vulnerabilidade do Codex. Em seguida, equipes devem revisar políticas internas de uso de IA, principalmente quando usuários enviam arquivos sensíveis, código-fonte, dados de clientes ou documentação operacional. A mitigação efetiva não se limita ao fornecedor; ela exige controle local sobre quais dados podem entrar no agente e quais saídas de rede são aceitáveis.
Para ChatGPT e ferramentas similares, a defesa deve incluir camada de inspeção e governança entre usuários e serviços de IA. Isso pode envolver classificação de dados antes do upload, bloqueio de conteúdo sensível, logs de uso, proxy corporativo, políticas de DNS e restrição de canais de saída quando houver execução de código. Também é recomendável tratar GPTs personalizados como componentes de software de terceiros: revisar origem, finalidade, permissões, comportamento esperado e risco de instruções embutidas antes de permitir uso com dados corporativos.
Para Codex, a mitigação deve focar em validação de entrada, escopo de credenciais e isolamento de execução. Organizações devem reduzir permissões dos tokens usados por agentes de codificação ao mínimo necessário, separar identidades humanas de identidades de automação, restringir quando comentários em pull requests podem acionar o agente e auditar nomes de ramos consumidos por automações. Repositórios compartilhados exigem atenção adicional porque um único parâmetro controlado por colaborador, fork ou integração pode influenciar o contêiner onde o agente opera.
A resposta pós-correção deve incluir revisão histórica. Equipes devem procurar tarefas do Codex criadas antes de 5 de fevereiro de 2026 com ramos anômalos, menções ao agente em pull requests e atividade incomum de tokens. Para o ChatGPT, a revisão deve priorizar usuários que processaram arquivos sensíveis antes de 20 de fevereiro de 2026 e ambientes com logs de DNS disponíveis. Quando houver indício de exposição de credenciais, a medida defensiva adequada é rotação de tokens, invalidação de sessões, revisão de permissões e análise de alterações em repositórios.
- Verificar se as correções da OpenAI estão aplicadas nos fluxos de ChatGPT e Codex usados pela organização.
- Restringir upload de dados sensíveis para ferramentas de IA quando não houver controle corporativo de entrada, saída e retenção.
- Monitorar e limitar tráfego DNS associado a ambientes de execução de IA e análise de código.
- Revisar permissões de GitHub User Access Token e GitHub Installation Access tokens usados por agentes de codificação.
- Auditar tarefas do Codex, comentários em pull requests e nomes de ramos processados antes da correção.
- Rotacionar credenciais quando houver evidência de execução anômala no contêiner do agente ou uso inesperado de tokens.
0 Comentários