ChatGPT GitHub connector permissions: the all repositories grant
A researcher says an all repositories grant let text in a public repository reach private ones. What is reported, what is unconfirmed, and the settings to change today.
Founder, Newly
Published Last updated
On October 15, 2026 a researcher published a report that the ChatGPT GitHub connector, set to all repositories, could be steered by text in a public repository to reach private ones. There is no CVE, the write-up does not say who assigned its score, and the researcher says OpenAI closed the report as out of scope. Treat it as unconfirmed, and narrow the grant anyway. It takes a few minutes.
What was reported, and what is confirmed?
The source is the researcher's own write-up of October 15, 2026. We read it on October 24, 2026. We found no vendor advisory, no vendor statement and no CVE record, so every fact below is the researcher's claim, labelled as such.
| Item | What the write-up says | Status at our check, October 24, 2026 |
|---|---|---|
| Setting involved | The connector's all repositories grant, said to be the default | Researcher claim; not vendor confirmed |
| Condition | You ask ChatGPT to review a public repository whose documentation carries hidden instructions | Researcher claim; not reproduced by us |
| Reported reach | Repository secrets, private repository names, chat transcripts and workflow commits to repositories you did not mention | Researcher claim |
| Score | CVSS 9.3 (Critical); the write-up does not say who scored it | No CVE, no vendor score |
| Vendor response | Reported September 4, closed as out of scope on October 14, with the connector described as working as designed; the researcher disputes that | Researcher account only |
| Control test | Selected repositories stopped it in the researcher's test | One researcher, one setup |
How to read the 9.3
In CVSS v4.0, base metrics are normally supplied by the organization that maintains the affected system, and a base score alone is not a measure of risk. A score with no named scorer and no CVE record is a claim about severity, and it tells you how the author weighed the scenario.
Why does an all repositories grant widen the damage?
Two ideas meet here. The first is indirect prompt injection: OWASP LLM01 describes how an assistant that reads external content, such as a file or a web page, can have its behavior changed by instructions hidden in that content. No wording of a prompt removes this risk, so the lasting control is what the assistant is allowed to touch.
The second is excessive agency. OWASP LLM06 lists excessive permissions and excessive autonomy among its root causes, and recommends least privilege and human approval for significant actions. An all repositories grant is the opposite of least privilege. A request to review one repository runs with the reach of your whole account.
If the connector authorizes through GitHub, the scope is also what GitHub shows you in settings. For OAuth apps, GitHub documents the repo scope as full access to public and private repositories, including write access to code. A separate workflow scope covers adding and updating Actions workflow files. We could not confirm which of these, or which GitHub App permissions, the ChatGPT connector requests, because OpenAI's help page returned an access error to our fetch. Read the permissions on your own consent screen.
The table compares the two grant choices. The right column describes the researcher's reading of their test, not a guarantee.
| Grant | What a steered agent can reach | Where it leaves you |
|---|---|---|
| All repositories | Every repository the account can reach, public and private | Unknown. Audit workflows and secrets across the account. |
| Selected repositories | Only the repositories you listed | Smaller reach. The listed repositories still need the same care. |
| Disconnected | Nothing through the connector | Existing commits and secrets still need the checks below if you used the connector before |
How do you narrow the grant?
GitHub documents the steps for an installed GitHub App. Open the app from your Settings, then under Repository access choose Only select repositories, pick the repositories, and save. Do this for your personal account and for each organization where the app is installed, because uninstalling affects one account only.
1. Find every authorization (5 minutes)
In GitHub, open Settings, then Applications. The Authorized GitHub Apps tab lists the apps with access to your account, and Revoke removes one. Look at the Installed tab and the Authorized OAuth Apps tab as well, since a connector can show up in either place.
2. Choose what stays in reach
- Leave out any repository that holds deployment workflows, store credentials or customer data.
- Leave out the repository that holds your app's server code if it has secrets in Actions.
- Keep read-only code you want reviewed. Add a repository only when you need it, and remove it afterwards.
3. Reduce what a workflow can do
Under Settings, Actions, General in each repository, Workflow permissions lets you choose read access for contents and packages instead of read and write. GitHub's own hardening guide recommends the read default, raised per job, and a CODEOWNERS rule so changes to workflow files need a named reviewer.
What should you check after reviewing outside code with the connector?
If you used the connector on a repository you did not write, assume nothing until you have looked. The table maps each check to where it lives and what the result means.
| Check | Where | If you find a problem |
|---|---|---|
| App authorizations | Your security log (90 days of events) | Revoke the app, then re-add it with selected repositories |
| Workflow files | Commit history of .github/workflows | Revert changes you cannot account for and treat the secrets those workflows could read as exposed |
| Organization activity | The organization audit log (180 days, owners only) | Look for app installs and workflow events you did not make |
| Secrets | Actions secrets, and the issuer of each key | Create a new key, switch to it, revoke the old one |
If a secret may have reached a workflow log, delete the log and rotate the secret. GitHub's page on using secrets in Actions explains how secrets are handled in workflows. For the order of rotation, read how to rotate app secrets after a platform breach and the red.run.cloud rotation guide. If a leaked key was an AI provider key, see how to check and rotate a leaked OpenAI key.
What does this mean for an app you built with AI?
Newly builds a real iPhone and Android app with React Native and Expo, and you can download the code or connect your own repository. That repository is yours, so it is also one more repository on your GitHub account. Under an all repositories grant, any assistant with that grant can reach it, whatever the assistant is used for.
The same logic applies to every tool you connect. A coding assistant, a chat connector and an MCP server each hold a grant. For the tool side, the MCP authorization checklist covers what a server should require. For the repository side, the pre-launch review and the 15-minute check cover keys in the bundle and database rules. The wider supply-chain pattern for AI tooling shows how often a trusted tool becomes the way in.
Agencies that ship apps for clients should list, per client, which repositories each connector can reach, and keep client repositories out of a personal grant. The hub at newly.app/security has the other checks.
Where do you stand?
Everything starts as unknown. Move an item to detected when you find the problem, and to confirmed only when you hold the evidence listed under it. Nobody outside your account can do this check for you.
Your connector grant check
- Detected: You found the problem.
- Unknown: Not checked yet, or the check could not tell.
- Confirmed by owner evidence: You checked and kept the proof.
Your answers stay in this browser tab. Nothing is saved or sent.
Frequently asked questions
Is the ChatGPT GitHub connector vulnerable?
One researcher says so, and the claim is unconfirmed. Their write-up of October 15, 2026 describes a scenario with the connector set to all repositories. It has no CVE, the write-up does not say who assigned its score, and it says OpenAI closed the report as out of scope, calling the connector working as designed. Use it as a reason to narrow your grant. It settles nothing about whether the connector is vulnerable.
Does choosing selected repositories fully stop it?
In the researcher's control test it did. That is one researcher's result on one setup, so read it as a strong hint rather than proof. A narrower grant limits what a steered agent can reach, and it does nothing about the repositories you still allow.
I used the connector on a repository I did not write. What do I check?
Open your GitHub security log and your repositories' recent commits for workflow files you did not write, review the Actions secrets those workflows can read, and rotate any secret you cannot account for. Then narrow the grant before you use the connector again.
Does this affect the app I built with Newly?
Not through Newly itself. The report is about a connector between ChatGPT and your GitHub account. It touches your app only if the repository holding your app code is reachable by that connector, which is true under an all repositories grant.
Should I disconnect the connector completely?
That is the strongest option and costs you the convenience. If you keep it, grant selected repositories only, keep private and secret-holding repositories off the list, and read any write action before you approve it.
Can a scan tell me if my repositories are exposed this way?
No. The grant lives inside your GitHub account, and a scan works from outside on a live site. A scan can check what your deployed app and domain show an outsider, which is a separate question.
Sources
All sources checked October 24, 2026. The OpenAI help page and one news report returned errors or empty pages to our fetch, so neither is cited.
- ChatGPT GitHub connector vulnerability write-up, October 15, 2026, Sunil Tripathy (researcher)
- Changing repository access for an installed GitHub App, GitHub Docs
- Reviewing and revoking authorization of GitHub Apps, GitHub Docs
- Scopes for OAuth apps, GitHub Docs
- Security hardening for GitHub Actions, GitHub Docs
- Using secrets in GitHub Actions, GitHub Docs
- Managing GitHub Actions settings for a repository, GitHub Docs
- Reviewing your security log, GitHub Docs
- Reviewing the audit log for your organization, GitHub Docs
- LLM01:2025 Prompt Injection, OWASP GenAI Security Project
- LLM06:2025 Excessive Agency, OWASP GenAI Security Project
- CVSS v4.0 specification, FIRST