ChatGPT GitHub Connector Flaw Could Expose Private Repository Secrets

A critical vulnerability has been identified in ChatGPT's integration with GitHub, potentially enabling attackers to exfiltrate sensitive secrets from private repositories. Researcher Sunil Tripathy disclosed that by manipulating instructions within a public repository, an AI agent could be tricked into modifying a different, private repository and triggering GitHub Actions. This indirect prompt injection technique bypasses standard security measures by leveraging the AI's trusted execution context.

Tripathy's findings, which he assigned a CVSS 4.0 score of 9.3, detail a scenario involving two GitHub accounts. An attacker controls a public repository containing hidden, malicious instructions. A victim account, which has granted ChatGPT access to its repositories, would then interact with the AI. When the AI agent reviewed the public repository, it would follow the embedded instructions, treating them as legitimate commands. Instead of merely analyzing the content, the agent would then commit a malicious GitHub Actions workflow into a separate, private repository belonging to the victim.

The compromised GitHub Actions workflow, once executed, could then exfiltrate sensitive data, such as test secrets like 'AUDIT_CANARY,' to an external server controlled by the attacker. Tripathy reported that the victim would not have explicitly named the target private repository or approved this write operation, highlighting the stealthy nature of the attack. This method falls under the category of indirect prompt injection, where malicious commands are embedded within data that an AI assistant processes.

While Tripathy's disclosure outlines a potential attack vector, it's important to note that the findings are researcher-reported and not yet vendor-confirmed by OpenAI. Tripathy's own testing used researcher-owned accounts and a dummy secret, with no customer data or third-party systems affected. He also noted that direct wording of malicious requests was refused by ChatGPT, but framing them as deployment requirements succeeded. The attack reportedly involved a custom action containing data theft logic, triggered by an innocent-looking workflow reference.

Further reported outcomes from Tripathy's research include the discovery of private repositories, the ability for attackers to commit files with their own content, and the retrieval of attack instructions from Git history. However, these results remain unverified by the vendor. A key point of ambiguity is the exact nature of the GitHub integration. OpenAI's documentation for the standard ChatGPT GitHub app states it is read-only, directing users to Codex for editing capabilities. This contrasts with the reported workflow commits, making the precise permissions and execution path crucial for confirming the vulnerability's scope.

Tripathy initially reported related behavior on September 4th, demonstrating secret theft on September 28th, and received an 'out of scope' closure on October 14th, with the attack reportedly still functional upon retesting the following day. These timelines do not confirm a vendor-acknowledged vulnerability or an official patch status. For organizations utilizing ChatGPT's GitHub integration, the primary recommendation is to strictly limit repository access to only what is necessary for specific tasks. OpenAI has confirmed that repository permissions can be managed through GitHub app settings.

Defensive measures suggested by Tripathy include vigilant review of unexpected workflow commits and prompt rotation of any secrets that may have been exposed. His control tests indicated that restricting access to a single repository effectively blocked cross-repository writes, reinforcing the importance of granular permissions as a practical safeguard against this demonstrated attack path. The potential for such a flaw underscores the evolving risks associated with AI agents interacting with sensitive code repositories.