Falha no conector do GitHub do ChatGPT pode expor repositórios privados
Uma vulnerabilidade no conector do GitHub usado pelo ChatGPT pode permitir que instruções ocultas em um repositório público levem o agente a acessar dados privados e alterar arquivos em outros repositórios da conta. A técnica, demonstrada pelo pesquisador Sunil Tripathy, combina injeção indireta de prompt com permissões amplas concedidas à integração.
O ataque começa quando a pessoa pede ao ChatGPT que examine um repositório público controlado pelo invasor. Nesse conteúdo, o agente encontra instruções maliciosas disfarçadas de orientações técnicas. Em vez de tratá-las como material não confiável, pode interpretá-las como parte da tarefa e executá-las.
Uma solicitação explícita para roubar informações foi recusada durante o teste. A estratégia que funcionou foi apresentar as instruções como requisitos para uma implantação. Com esse pretexto, o agente gravou um workflow do GitHub Actions que aparentava ser legítimo, mas encaminhava a execução para uma ação externa com código destinado a retirar dados do ambiente.
Na demonstração, um segredo fictício chamado `AUDIT_CANARY` foi enviado a um servidor controlado pelo pesquisador. O teste também indicou que o agente conseguiu localizar repositórios privados e criar neles arquivos preparados pelo atacante. Esses resultados apontam para riscos tanto de exposição de informações quanto de alteração de conteúdo.
Para que o cenário se concretize, a conta precisa ter conectado o GitHub ao ChatGPT com permissão para acessar todos os repositórios. Ainda assim, a pessoa não precisa indicar qual repositório privado deve ser atingido nem aprovar individualmente a gravação. O invasor, por sua vez, precisa controlar o repositório público que será analisado.
O caso chama atenção porque a documentação da integração descreve o aplicativo do GitHub como uma ferramenta somente de leitura, enquanto o fluxo demonstrado incluiu a criação de conteúdo em outro repositório. Segundo o relato, não havia um identificador CVE associado à falha, e a comunicação do problema foi encerrada como fora de escopo em 14 de outubro. O pesquisador informou que o teste ainda funcionava no dia seguinte.
Até que exista uma correção confirmada, a principal medida preventiva é reduzir as permissões do conector. Em vez de liberar a conta inteira, conceda acesso apenas aos repositórios necessários para a tarefa em questão. No teste descrito, restringir a integração dessa forma impediu a gravação entre repositórios.
Também é recomendável revisar as permissões concedidas a aplicativos conectados ao GitHub. Acesso amplo facilita o trabalho, mas aumenta o impacto de uma instrução maliciosa ou de uma falha no agente. Quando possível, mantenha repositórios sensíveis fora do alcance de ferramentas que não precisam consultá-los.
Equipes de desenvolvimento devem inspecionar workflows adicionados ou modificados recentemente, sobretudo arquivos de GitHub Actions que chamem componentes externos. Verifique quem realizou a alteração, o conteúdo executado e os dados aos quais o processo pode ter acesso. Um arquivo com aparência rotineira não deve ser considerado seguro sem revisão.
Se houver suspeita de exposição, revogue ou substitua imediatamente os segredos que poderiam ter sido acessados. A investigação deve incluir logs de execução, histórico de commits, alterações em workflows e atividades incomuns nos repositórios privados. A rotação de credenciais não substitui a apuração, mas limita o uso posterior de valores comprometidos.
O episódio também reforça uma regra importante para o uso de agentes de IA: conteúdo encontrado durante uma análise – como arquivos, comentários e documentação de um projeto – deve ser tratado como dado, não como autoridade. Instruções embutidas em um repositório podem tentar desviar o agente do pedido original, e a combinação desse comportamento com permissões excessivas transforma uma manipulação textual em risco operacional.