Problemas de segurança do OpenAI Codex: sincronização de plugins selecionados, Heapjack, Overpatch e Plugin4Shell

A OpenAI passou grande parte de 2026 aprofundando o uso de IA na segurança de software.

Em março, lançou o Codex Security em prévia de pesquisa como um agente de segurança de aplicações projetado para encontrar, validar e ajudar a corrigir vulnerabilidades. Em junho, a OpenAI apresentou o Patch the Planet, uma iniciativa Daybreak com a Trail of Bits voltada a ajudar mantenedores de projetos de código aberto a encontrar e corrigir problemas de segurança. No fim de julho, a OpenAI também lançou o CLI de código aberto do Codex Security e o SDK TypeScript.

Isso torna a história de segurança em torno do Codex especialmente importante.

O Codex não é apenas um modelo de geração de código. Ele é um agente de programação conectado a ambientes locais e em nuvem, capaz de ler repositórios, editar arquivos, invocar ferramentas, executar comandos, carregar plugins, conectar-se a serviços MCP e operar em ambientes de desenvolvimento que frequentemente contêm código-fonte e credenciais.

Em setembro, um relatório da BAAI/New Zhiyuan destacou uma nova alegação de segurança sobre o Codex atribuída ao 360 Tulongfeng, um sistema chinês de testes de segurança de IA. O relatório afirma que o problema envolvia o caminho de sincronização do plugin Git selecionado do Codex e poderia ultrapassar o limite de aprovação que os usuários normalmente esperam antes de ações sensíveis.

Essa nova descoberta específica do 360 não foi acompanhada por um comunicado público da OpenAI ou por um relatório técnico público detalhado que prove de forma independente que se trata de um zero-day distinto. No entanto, o risco mais amplo descrito no artigo é real: relatórios públicos anteriores sobre problemas do Codex já haviam mostrado que a sincronização de inicialização de plugins selecionados poderia ser executada fora do sandbox do modelo e, em determinadas condições do ambiente Git, operar no repositório do usuário em vez do cache do plugin.

A diferença é importante. Este artigo preserva a estrutura da história original enquanto separa incidentes públicos confirmados, descobertas relatadas por pesquisadores e alegações atribuídas a fornecedores.

A OpenAI apresentou o Codex Security em 6 de março de 2026.

O produto foi projetado para criar contexto sobre uma base de código, identificar fragilidades de segurança, validar se uma descoberta é relevante e propor correções. Diferentemente de um simples scanner de padrões, a OpenAI o posiciona como um sistema de segurança agentivo capaz de raciocinar sobre um projeto e reduzir falsos positivos.

Posteriormente, a OpenAI ampliou esse esforço com o Patch the Planet.

A iniciativa combina pesquisa de vulnerabilidades assistida por IA com revisão humana para que os mantenedores recebam descobertas verificadas, que podem ser acompanhadas de patches e testes.

A mensagem central é direta: a IA pode aumentar a velocidade tanto da criação de software quanto da descoberta de vulnerabilidades; por isso, as equipes de defesa precisam de formas mais rápidas de revisar e corrigir o código.

A ironia destacada pelo artigo de origem é que o mesmo tipo de infraestrutura de agentes de programação usado para encontrar falhas de outras pessoas também se tornou um alvo valioso para pesquisadores de segurança.

Do que trata a nova alegação sobre a sincronização de plugins selecionados

O artigo de origem atribui uma vulnerabilidade recém-descoberta do Codex ao sistema Tulongfeng, da 360, e afirma que o problema está relacionado ao mecanismo de sincronização de plugins Git selecionados do Codex.

No uso normal, o Codex depende de vários controles de segurança:

• Um sandbox define onde os comandos orientados pelo modelo podem ler ou escrever.
• As políticas de aprovação determinam quando o Codex deve pausar e solicitar autorização antes de ações sensíveis.
• Os mecanismos de plugins e MCP ampliam o agente com recursos adicionais.
• O Git é usado para buscar e sincronizar código e conteúdo de plugins.

O risco aparece quando o código de inicialização ou de infraestrutura é executado fora do mesmo sandbox usado pelos comandos orientados pelo modelo.

Essa distinção já é visível em relatórios públicos de problemas do Codex.

Um problema publicado no GitHub em julho documentou um caso em que a sincronização de inicialização de plugins selecionados executava comandos Git sem isolar completamente as variáveis de ambiente GIT_* locais ao repositório. Quando o Codex era iniciado em determinados contextos de hooks do Git ou de worktrees, a sincronização podia agir sobre o repositório do usuário em vez do cache de plugins pretendido.

O autor observou especificamente que --sandbox read-only não continha o comportamento porque a sincronização fazia parte da infraestrutura de inicialização do Codex, e não de um comando executado pelo modelo dentro do sandbox.

A OpenAI incorporou uma correção intitulada “Isolate curated plugin sync Git environment” em 24 de junho de 2026. Problemas públicos relacionados às versões 0.142.x afetadas e às primeiras versões 0.143 mostraram que a correção inicialmente estava presente na branch main antes de chegar às versões estáveis.

Esse histórico público sustenta o ponto mais amplo do artigo: os limites de segurança de um agente devem abranger a própria infraestrutura, e não apenas os comandos de shell solicitados diretamente pelo modelo.

O que permanece menos claro é se a alegação de setembro atribuída ao Tulongfeng representa um caminho de exploração separado do problema público anterior de isolamento da sincronização de inicialização. Sem um comunicado público, CVE ou relatório técnico da OpenAI ou da 360, esta versão não apresenta a alegação de “novo zero-day” como um fato comprovado de forma independente.

Por que os avisos de aprovação não são suficientes por si só

Um modelo conhecido de segurança do Codex funciona assim:

1. O agente solicita uma ação.
2. O sandbox verifica se a ação está dentro do limite permitido.
3. Se a ação exigir mais privilégios, o Codex pausa.
4. O usuário ou revisor aprova ou rejeita a ação.
5. Só então a ação sensível deve continuar.

As orientações atuais da OpenAI sobre segurança de agentes seguem o mesmo princípio geral: efeitos colaterais de alto risco devem ser restringidos de forma independente e, quando necessário, interrompidos para uma revisão humana explícita.

O problema é que um aviso de permissão só pode proteger uma ação se ela realmente passar pelo caminho de código que aplica o aviso.

Se um atualizador em segundo plano, sincronizador de plugins, processo auxiliar ou outro subsistema confiável realizar trabalho fora desse caminho, a interface de aprovação visível pode não ser o limite de segurança relevante.

Essa é uma das lições mais importantes dos relatórios de vulnerabilidades do Codex em 2026.

O modelo de ameaça para uma ferramenta de programação com IA não é mais apenas:

“O modelo vai pedir para executar um comando perigoso?”

Também é:

“Quais partes da plataforma do agente podem alterar arquivos, iniciar processos, buscar código, carregar plugins, ler credenciais ou interagir com o Git antes ou fora do fluxo normal de aprovação do modelo?”

Um bug de sincronização de plugins pode se transformar em um problema de cadeia de suprimentos de software

O artigo de origem ilustra o possível impacto com um cenário de cadeia de suprimentos de software.

A cadeia não exige que o malware chegue por meio de um download obviamente malicioso.

Uma sequência mais realista é:

1. Um desenvolvedor abre ou trabalha com um repositório não confiável ou comprometido.
2. Uma vulnerabilidade do agente de programação ultrapassa um limite esperado de sandbox ou aprovação.
3. O invasor alcança credenciais ou ferramentas de desenvolvimento disponíveis nessa estação de trabalho.
4. Essas credenciais são usadas para modificar código-fonte, CI/CD, publicação de pacotes ou infraestrutura de lançamento.
5. Uma versão maliciosa é publicada pelo canal normal e confiável de atualização do projeto.
6. Usuários posteriores instalam o que parece ser uma atualização legítima.

É por isso que as estações de trabalho de desenvolvedores são alvos de alto valor.

Elas podem conter:

• Tokens do GitHub ou GitLab
• Credenciais de nuvem
• Segredos de CI/CD
• Credenciais de publicação de pacotes
• Certificados de assinatura de código
• Acesso à produção
• Repositórios internos

A primeira máquina comprometida pode não ser o verdadeiro objetivo do invasor.

O objetivo pode ser a confiança associada à identidade desse desenvolvedor e ao pipeline de lançamento.

Essa é a característica definidora do risco da cadeia de suprimentos: o invasor tenta transformar um caminho de software confiável no mecanismo de distribuição.

O Codex enfrentou várias descobertas de segurança em 2026

A história dos plugins selecionados faz parte de uma sequência mais ampla de pesquisas de segurança em torno dos agentes de programação com IA.

O artigo de origem agrupa vários incidentes de 2026, e a maioria pode ser verificada de forma independente.

Maio: a Pwn2Own Berlin inclui agentes de programação com IA como alvos formais

A Pwn2Own Berlin 2026 introduziu uma categoria dedicada de Coding Agent, com OpenAI Codex, Anthropic Claude Code e Cursor como alvos.

Os resultados oficiais do primeiro dia da Zero Day Initiative mostram que a Compass Security explorou com sucesso o OpenAI Codex usando um problema CWE-150 e recebeu US$ 40.000, além de quatro pontos de Master of Pwn.

A Doyensec também demonstrou uma exploração contra o Codex, mas o resultado foi classificado como uma colisão, porque o fornecedor já conhecia o bug subjacente.

O evento como um todo terminou com 47 vulnerabilidades zero-day únicas e US$ 1.298.250 em prêmios em todas as categorias.

A Pwn2Own é especialmente útil como ponto de referência porque suas regras para agentes de programação excluíam jailbreaks simples e modos inseguros. Uma entrada bem-sucedida precisava ultrapassar um limite de segurança relevante por meio de um fluxo comum de agente de programação.

Agosto: a 360 afirma que o Tulongfeng encontrou seis vulnerabilidades de alto valor no Codex

Em 12 de agosto, a 360 declarou publicamente que seu sistema de segurança de IA Tulongfeng havia encontrado seis vulnerabilidades de segurança de alto valor no OpenAI Codex.

Segundo o anúncio da 360, as descobertas incluíam casos de alto risco que poderiam levar à execução remota arbitrária de código e contornar os avisos de confiança do Codex quando os usuários abrissem diretórios de projetos não confiáveis.

A divulgação foi reproduzida por diversos veículos de mídia chineses e pela Xinhua por meio de um relatório distribuído.

No entanto, os relatórios técnicos detalhados e identificadores no estilo CVE para todas as seis descobertas não foram publicados nas fontes analisadas para este artigo.

A forma correta de apresentar a alegação é, portanto:

A 360 afirma que o Tulongfeng encontrou seis vulnerabilidades de alto valor no Codex, incluindo casos com impacto de execução remota de código.

Isso é diferente de validar de forma independente todas as seis cadeias de exploração com base em material técnico público.

Agosto–setembro: Overpatch e Heapjack

O pesquisador de segurança Oren Yomtov, da Accomplish, relatou duas fugas do sandbox do Codex à OpenAI em 12 de agosto.

Os pesquisadores deram a elas os nomes Overpatch e Heapjack.

A Overpatch afetava o caminho de aplicação de patches do CLI de código aberto do Codex e podia escapar do limite pretendido de gravação no workspace.

A Heapjack tinha como alvo um auxiliar JavaScript usado pelo Codex Desktop e, segundo os pesquisadores, podia terminar em execução de comandos fora do sandbox mesmo quando o Codex estava operando em modo somente leitura.

Os pesquisadores afirmam que a OpenAI corrigiu os dois problemas em oito dias.

As orientações de correção publicadas por eles dizem que os usuários deveriam atualizar para:

Esses números de versão vêm da divulgação dos pesquisadores, e não de um comunicado de segurança separado da OpenAI.

17 de setembro: Plugin4Shell atinge quatro grandes agentes de programação

A AIR Security divulgou o Plugin4Shell em 17 de setembro.

A falha afetava a lógica de instalação e atualização de plugins em:

• Claude Code
• OpenAI Codex
• GitHub Copilot
• Gemini CLI

A AIR descreveu o problema como um caminho de execução remota de código sem interação do usuário, baseado na falha em verificar se o código obtido após a instalação do plugin correspondia ao commit que o marketplace pretendia fixar.

Como o Codex e o Claude Code podiam atualizar automaticamente os plugins instalados, um plugin previamente confiável poderia se transformar em um caminho de cadeia de suprimentos sem exigir um novo clique do usuário.

A AIR afirma que a OpenAI corrigiu o Codex na versão 0.146.0.

O Plugin4Shell é importante porque não foi uma falha de comportamento do modelo. Foi uma falha clássica de projeto da cadeia de suprimentos de software na camada de distribuição ao redor do agente.

O que esses incidentes têm em comum

As descobertas do Codex em 2026 não compartilham todas a mesma causa-raiz.

Algumas envolvem limites de sandbox.

Algumas envolvem processos auxiliares.

Algumas envolvem o tratamento do ambiente Git.

Algumas envolvem a distribuição de plugins.

O que elas compartilham é uma base computacional confiável ampliada.

Um agente de programação moderno não é apenas:

prompt do usuário -> modelo -> resposta

Ele se aproxima mais de:

usuário
  -> modelo
  -> estrutura do agente
  -> roteador de ferramentas
  -> shell
  -> sistema de arquivos
  -> Git
  -> gerenciador de plugins
  -> serviços MCP
  -> credenciais
  -> rede
  -> CI/CD

Cada camada introduz recursos úteis.

Cada camada também pode introduzir um novo limite de segurança.

É por isso que “o modelo está em um sandbox” não é, por si só, um argumento completo de segurança.

A plataforma do agente também precisa provar que o atualizador, o carregador de plugins, o editor de arquivos, a ponte de terminal, o proxy de rede, os daemons auxiliares e os caminhos de credenciais obedecem às mesmas premissas de segurança.

A IA está aumentando tanto a produção de software quanto a descoberta de vulnerabilidades

O ponto mais amplo do artigo de origem é que a IA está acelerando os dois lados da segurança de software.

No desenvolvimento, agentes de programação podem criar recursos, testes, infraestrutura, integrações e projetos inteiros muito mais rápido do que os fluxos manuais tradicionais.

Isso aumenta a quantidade de código novo produzido.

No lado defensivo, sistemas como o Codex Security e o Tulongfeng foram projetados para analisar grandes bases de código e encontrar vulnerabilidades em escala de máquina.

Isso aumenta a velocidade com que vulnerabilidades antigas e novas podem ser descobertas.

As duas tendências se reforçam.

Mais código cria uma superfície de ataque maior.

Uma automação de segurança melhor descobre uma parcela maior dessa superfície.

O resultado não é necessariamente um ecossistema de software menos seguro. Mas significa que a revisão de segurança precisa operar em uma velocidade mais próxima daquela do desenvolvimento assistido por IA.

Por que as ferramentas de programação com IA são uma camada especialmente sensível

Os agentes de programação ocupam uma posição incomum na pilha de software.

Eles ficam a montante das aplicações que os usuários finalmente instalam.

Eles podem ter acesso a:

• Código-fonte
• Scripts de build
• Execução de shell
• Histórico do Git
• Arquivos de dependências
• Segredos de desenvolvimento
• Fluxos de lançamento

Uma falha em um chatbot comum pode produzir uma resposta ruim.

Uma falha em um agente de programação pode produzir, em alguns casos, um arquivo alterado, um processo iniciado, um repositório modificado, uma credencial exposta ou um caminho de build comprometido.

É por isso que a segurança de agentes de programação se aproxima cada vez mais da segurança de endpoints e da segurança da cadeia de suprimentos de software, e não apenas da segurança de modelos.

As próprias orientações atuais de sandbox da OpenAI refletem essa realidade. Elas recomendam isolar cargas de trabalho, restringir o acesso de saída à rede, separar credenciais, manter chaves de aplicação fora dos ambientes de execução do agente e usar controles de aprovação independentes para ações consequentes.

Quem encontra a vulnerabilidade primeiro é importante

A parte final do artigo de origem concentra-se no 360 Tulongfeng e na corrida entre defensores e invasores.

A ideia central é válida: uma vulnerabilidade existe independentemente de o fornecedor conhecê-la.

Se um defensor a encontrar primeiro, existe uma oportunidade de corrigir o sistema antes que a exploração se espalhe.

Se um invasor a encontrar primeiro, o mesmo bug pode se transformar em um incidente.

Esse é o argumento econômico por trás da pesquisa automatizada de vulnerabilidades.

As iniciativas Codex Security e Patch the Planet da OpenAI baseiam-se na mesma premissa, embora venham de uma organização diferente.

O objetivo é antecipar a descoberta de vulnerabilidades no ciclo de vida do software.

O que a 360 afirma que o Tulongfeng faz

A 360 descreve o Tulongfeng como um sistema de descoberta de vulnerabilidades com IA construído em torno de dois componentes:

1. Um modelo especializado em segurança, treinado com dados de longo prazo sobre vulnerabilidades e ataque e defesa.
2. Um conjunto de agentes especializados que reproduzem partes dos fluxos de trabalho de especialistas em segurança, como análise da superfície de ataque, avaliação de vulnerabilidades, análise de código, uso de ferramentas e validação dinâmica.

A 360 afirma que o produto foi usado para testar código-fonte, binários, firmware, sistemas empresariais e cadeias de ferramentas de IA.

A empresa também afirma que o Tulongfeng havia encontrado mais de 10.000 vulnerabilidades até o fim de agosto/setembro de 2026.

Esse total é um número cumulativo informado pelo fornecedor.

Um anúncio da comunidade da 360 publicado em 25 de agosto afirmou que o sistema havia encontrado mais de 10.000 vulnerabilidades e que quase 400 organizações haviam se conectado e concluído testes de segurança. Uma publicação posterior de setembro repetiu o número superior a 10.000.

O artigo de origem também afirma que 260 descobertas haviam sido verificadas por autoridades chinesas de vulnerabilidades e que quase 500 organizações haviam se conectado. Esses números exatos não foram encontrados na fonte mais recente da 360 analisada para esta versão; por isso, não são repetidos aqui como números confirmados de forma independente.

O ciclo de “autoaperfeiçoamento” do Tulongfeng

O artigo de origem descreve a abordagem do Tulongfeng como uma forma de melhoria recursiva.

O conceito está menos relacionado à reescrita dos próprios pesos do modelo-base e mais à criação de uma memória operacional reutilizável a partir de tarefas de segurança concluídas.

O fluxo pode ser resumido assim:

1. Um agente encontra um problema difícil de análise de vulnerabilidade.
2. O sistema registra todo o processo de raciocínio e uso de ferramentas.
3. O fluxo de trabalho é abstraído em uma estratégia reutilizável.
4. Outros agentes podem acessar essa estratégia posteriormente.
5. Tarefas futuras começam com mais experiência acumulada.

Isso é semelhante à forma como as equipes de segurança criam playbooks, bases de conhecimento de exploração, regras de detecção e procedimentos de resposta a incidentes.

A diferença é que um sistema de agentes pode potencialmente reutilizar essa experiência em uma velocidade muito maior e em muitas tarefas paralelas.

A alegação do fornecedor é que isso transforma descobertas de segurança individuais em uma capacidade compartilhada por toda a frota de agentes.

A corrida de segurança não termina com um único patch

O artigo termina com uma imagem da cadeia de suprimentos que vale a pena manter.

Quando um usuário toca em “Atualizar”, o software pode ter passado por:

• Um repositório de código aberto
• Uma estação de trabalho de desenvolvedor
• Uma ferramenta de programação com IA
• Um sistema de build
• Um pipeline de CI/CD
• Um processo de assinatura
• Uma loja de aplicativos ou registro de pacotes
• Um mecanismo de atualização automática

Cada estágio herda a confiança do estágio anterior.

Os agentes de programação com IA agora ficam próximos do início dessa cadeia.

Isso faz com que seus próprios controles de segurança sejam parte do modelo de segurança de cada aplicação que ajudam a criar e distribuir.

A lição prática não é que os desenvolvedores devam parar de usar agentes de programação.

É que os agentes de programação precisam ser tratados como uma infraestrutura de desenvolvimento poderosa.

Eles precisam de gerenciamento de versões, isolamento, privilégio mínimo, separação de segredos, governança de plugins, monitoramento de segurança e aplicação rápida de patches, assim como qualquer outra ferramenta privilegiada.

Lista de verificação prática de segurança para usuários do Codex

Com base nas orientações atuais da OpenAI e nas divulgações públicas de vulnerabilidades de 2026, os desenvolvedores podem reduzir a exposição com algumas práticas concretas.

Mantenha o Codex atualizado

As correções de segurança conhecidas chegaram rapidamente.

Para os problemas divulgados pelos pesquisadores e abordados acima, os usuários afetados devem estar além das versões corrigidas informadas para Plugin4Shell, Overpatch e Heapjack.

Trate repositórios não confiáveis como código não confiável

Não presuma que “eu apenas fiz uma pergunta ao agente” significa que nenhum caminho de código pode ser executado.

Use isolamento ao revisar repositórios desconhecidos.

Separe credenciais de longa duração

Evite expor credenciais de alto valor de nuvem, registros de pacotes, assinatura e produção diretamente a um ambiente de execução do agente.

Restrinja o acesso à rede

Permita apenas os destinos de saída necessários para a tarefa.

Um agente de programação com saída arbitrária e credenciais amplas tem um raio de impacto muito maior.

Revise plugins e integrações MCP

Um agente confiável ainda pode ser comprometido por meio de uma extensão ou canal de atualização não confiável.

Fixe versões, audite e atualize plugins de forma deliberada.

Mantenha a aprovação humana fora do limite de execução não confiável

Para operações de alto impacto, as aprovações devem ser aplicadas por um componente confiável separado, e não apenas por uma lógica executada dentro do mesmo ambiente de execução do agente.

Monitore a infraestrutura ao redor do agente

Registre e revise:

• Chamadas de ferramentas
• Atualizações de plugins
• Operações do Git
• Conexões de rede
• Uso de credenciais
• Escritas no sistema de arquivos
• Eventos de aprovação

A resposta final do modelo é apenas uma parte do que o agente fez.

Perguntas frequentes

O que é o problema de sincronização de plugins selecionados do Codex?

O Codex usava um mecanismo de inicialização para sincronizar plugins selecionados por meio do Git. Problemas públicos no GitHub mostraram que versões anteriores podiam herdar o estado das variáveis de ambiente Git locais ao repositório e executar operações de sincronização no repositório do usuário em vez do cache de plugins pretendido, fora do sandbox do modelo.

O Tulongfeng, da 360, encontrou um novo zero-day do Codex em setembro de 2026?

O artigo da BAAI/New Zhiyuan atribui um novo caminho de ataque de sincronização do Git selecionado ao Tulongfeng, da 360. No entanto, não foi encontrado nenhum comunicado público da OpenAI ou divulgação técnica detalhada da 360 que estabeleça de forma independente essa alegação específica de setembro como um novo zero-day distinto. Portanto, ela deve ser tratada como um relato atribuído, e não como uma descoberta pública totalmente verificada.

O que são Overpatch e Heapjack?

São duas fugas do sandbox do Codex divulgadas pelo pesquisador Oren Yomtov, da Accomplish. O pesquisador afirma que ambas foram comunicadas à OpenAI em 12 de agosto e corrigidas em oito dias.

O que é o Plugin4Shell?

O Plugin4Shell é uma vulnerabilidade da cadeia de suprimentos de plugins divulgada pela AIR Security em 17 de setembro de 2026. A AIR afirma que ela afetou Claude Code, Codex, GitHub Copilot e Gemini CLI ao quebrar a garantia de que um plugin instalado correspondia ao commit que o marketplace pretendia fixar.

O Codex foi explorado na Pwn2Own Berlin 2026?

Sim. A Zero Day Initiative informou uma exploração bem-sucedida do Codex pela Compass Security no primeiro dia e outra exploração bem-sucedida do Codex pela Ikotas Labs no terceiro dia. A Doyensec também demonstrou uma exploração classificada como colisão porque o fornecedor já conhecia o bug subjacente.

O Codex Security é de código aberto?

A OpenAI lançou o CLI e o SDK TypeScript do Codex Security como software de código aberto em julho de 2026. O acesso a alguns recursos de cibersegurança e a descobertas protegidas ainda pode exigir acesso apropriado à OpenAI ou o Trusted Access for Cyber.

Usar o modo de sandbox somente leitura garante que nada perigoso possa acontecer?

Não. Nenhum modo isolado deve ser tratado como uma garantia absoluta. Várias descobertas de 2026 foram relevantes especificamente porque o componente vulnerável operava fora do sandbox esperado do modelo ou atravessava o limite de segurança pretendido.

Como as equipes devem proteger agentes de programação com IA?

Use versões atuais, isole código não confiável, restrinja o acesso à rede, mantenha credenciais de longa duração fora do ambiente de execução, audite plugins, use aprovações humanas independentes para ações consequentes e registre as atividades reais de ferramentas e sistemas do agente.

Ferramentas relacionadas

• OpenAI Codex: CLI de código aberto do Codex e código principal usado em fluxos de trabalho locais com agentes de programação.
• Codex Security: CLI e SDK TypeScript da OpenAI para definir políticas de segurança e encontrar, validar e corrigir vulnerabilidades.
• OpenAI Deployment Safety Hub: cartões oficiais de sistema e informações de segurança de implantação dos modelos da OpenAI.
• Zero Day Initiative: programa de divulgação de vulnerabilidades e organizadora da Pwn2Own Berlin 2026.
• AIR Security: empresa de segurança de agentes que divulgou o Plugin4Shell.
• 360 Tulongfeng: introdução pública da 360 ao seu sistema de agentes de IA para descoberta de vulnerabilidades.

Links relacionados

• Prévia de pesquisa do OpenAI Codex Security: anúncio oficial de março de 2026 sobre o Codex Security.
• OpenAI Patch the Planet: iniciativa oficial Daybreak para trabalho de segurança de código aberto assistido por IA.
• Repositório do Codex Security no GitHub: repositório oficial de código aberto do CLI e do SDK.
• Problema #31498 de sincronização de plugins selecionados do Codex: relatório público mostrando que a sincronização Git de inicialização podia operar fora do limite do sandbox somente leitura sob um estado herdado do ambiente Git.
• Resultados do primeiro dia da Pwn2Own Berlin 2026: resultados oficiais da ZDI documentando uma exploração bem-sucedida do Codex e uma colisão.
• Accomplish: Escapando do sandbox do OpenAI Codex, duas vezes: divulgação dos pesquisadores sobre Overpatch e Heapjack, incluindo as versões corrigidas informadas.
• AIR Security: Plugin4Shell: publicação de pesquisa primária sobre a vulnerabilidade da cadeia de suprimentos de plugins que afetou vários agentes.

Resumo

A OpenAI está usando o Codex Security e o Patch the Planet para acelerar a pesquisa defensiva de vulnerabilidades, mas o próprio Codex se tornou um alvo de segurança cada vez mais importante porque fica próximo do código-fonte, das ferramentas, das credenciais, dos plugins e dos fluxos de lançamento de software.

Os incidentes de 2026 verificados publicamente incluem explorações do Codex na Pwn2Own, bugs de isolamento na sincronização de inicialização de plugins selecionados, as fugas de sandbox Overpatch e Heapjack e o Plugin4Shell. O “novo zero-day” de setembro atribuído ao 360 Tulongfeng deve ser tratado com mais cautela até que um comunicado público detalhado estabeleça como ele difere dos problemas anteriores de sincronização de plugins.

A lição mais ampla é consistente em todos esses casos: o limite de segurança de um agente de programação com IA inclui muito mais do que o modelo. O atualizador, o gerenciador de plugins, a integração com o Git, o runtime de ferramentas, os processos auxiliares, o acesso à rede, o tratamento de credenciais e o sistema de aprovação também passam a fazer parte da base computacional confiável.

As ferramentas de programação com IA agora são infraestrutura de software a montante. Seus próprios controles de segurança devem ser tratados com o mesmo rigor aplicado às aplicações e cadeias de suprimentos que ajudam a construir.