{ "schema_version": "0.4", "id": "REG-0005", "title": "GitHub MCP server: a public issue hijacks a user's agent into leaking private-repository data, disclosed 26 May 2025", "batch": "B0", "family": "software", "context": { "domain": "Software agent (an MCP client with repository tools)", "autonomy_level": "supervised", "actor_type": "Software: any agent using the GitHub MCP server", "actors": { "count": 1, "text": "1", "roles": [ "defender" ] }, "mandate_context": "demonstration", "jurisdiction": [ "Global (open-source tooling)" ], "autonomy_level_text": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do)", "mandate_context_text": "Demonstration" }, "provenance_tier": "disclosure_corroborated", "status": "confirmed", "fields": [ { "layer": "Mandate", "facet": "principal", "value": "A developer asking the agent to look at the open issues in a public repository", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Mandate", "facet": "objective", "value": "Review issues in one public repository", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Actor", "facet": null, "value": "Claude Desktop (a general MCP client, not specifically a coding agent) running Claude 4 Opus, connected to the GitHub MCP server; the researchers say the flaw is not specific to any agent or MCP client", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Inputs", "facet": null, "value": "A malicious issue on the public repository containing a prompt injection, which by standard GitHub rules an attacker can create", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false, "downgraded_by": "verifier" }, { "layer": "Decision", "facet": null, "value": "The agent followed the injected instruction, pulled private-repository data into its context and wrote pieces of it (the name of a private repository, 'Jupiter Star', a plan to relocate to South America, and a salary) into a pull request on the public repository", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false }, { "layer": "Envelope", "facet": "authority", "value": "The agent was connected to the user's account with permission for the private repositories as well as the public one; the researchers call this a fundamental architectural issue, not a flaw in the server's code", "assertion_type": "assertion", "source_ids": [ "INV", "DEVCLASS" ], "confidence": "high", "disputed": false }, { "layer": "Action", "facet": null, "value": "In the researchers' demonstration, the agent leaked private-repository data into a public pull request", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false }, { "layer": "Outcome", "facet": null, "value": "State: averted. Demonstration only; the reproduction used blank repositories. As of 2025.", "assertion_type": "fact", "source_ids": [ "INV", "GH-844" ], "confidence": "high", "disputed": false }, { "layer": "Evidence", "facet": "event", "value": "A reproduction posted as an issue on the server's own repository, using both OAuth and personal access tokens on otherwise blank repositories", "assertion_type": "fact", "source_ids": [ "GH-844" ], "confidence": "high", "disputed": false }, { "layer": "Evidence", "facet": "causality", "value": "The researchers assess that it affects any agent using the server, regardless of the underlying model", "assertion_type": "assertion", "source_ids": [ "INV" ], "confidence": "high", "disputed": false }, { "layer": "Evidence", "facet": "scope", "value": "The author of issue #844 reports that a token limited to public repositories still read the private repositories but did not write their contents out, and that the full leak needed the broad-scope token; the reproduction's independence from the researchers is not established", "assertion_type": "assertion", "source_ids": [ "GH-844" ], "confidence": "medium", "disputed": false }, { "layer": "Recovery", "facet": "technical", "value": "On 10 December 2025 GitHub shipped an opt-in 'lockdown mode' for its MCP server, enabled by a request header, which surfaces only content from collaborators with push access on public repositories (private repositories are unaffected), and said content sanitization against prompt injection is on by default. On the server's issue tracker a GitHub maintainer listed mitigations on 20 April 2026 (lockdown mode, read-only mode, secret scanning on public-repository calls, OAuth 2.1, strict fine-grained tokens) and on 21 April 2026 wrote that it was 'not really a vulnerability in the conventional sense' but true of 'any tools that enable lethal trifecta' (his term for the agent-risk pattern). A proposal that the server accept issues only from users with push access was raised in the tracker (issue #427, per DevClass).", "assertion_type": "assertion", "source_ids": [ "GH-LOCKDOWN", "GH-844", "DEVCLASS" ], "confidence": "high", "disputed": false }, { "layer": "Recovery", "facet": "accountability", "value": "The researchers published on 26 May 2025; the sources record no disclosure to GitHub before publication and no regulator action. On the server's tracker a question whether a CVE (a public vulnerability identifier) was issued went unanswered, and a GitHub maintainer wrote on 21 April 2026 that the report 'was reviewed' but was 'not really a vulnerability in the conventional sense'", "assertion_type": "assertion", "source_ids": [ "INV", "GH-844" ], "confidence": "medium", "disputed": false } ], "controls": { "failed": [], "succeeded": [], "absent": [ { "id": "C-E1", "note": "Per-task token scoping", "confidence": "high", "basis": "curated" }, { "id": "C-I1", "note": "Retrieved issue text treated as instruction", "confidence": "high", "basis": "reviewer 2026-10-06" }, { "id": "C-E5", "note": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. No approval prompt is recorded stopping it: Claude Desktop, used in the researchers' run, confirms individual tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do", "confidence": "medium", "basis": "curated" } ] }, "applicable_rules": [ "None applicable; voluntary guidance only" ], "unmapped": [ "C-O1 (coordinated disclosure): not evidenced; the record shows public disclosure by the researchers but no report to GitHub before publication", "Content-source trust filter (not in the canonical set): The issue author's identity was not in doubt (any GitHub user may open an issue on a public repository); what was missing was a filter on whose content the agent reads, later shipped by GitHub as opt-in lockdown mode on 10 December 2025" ], "corrections": [ { "date": "2026-10-13", "field": "fields and sources", "old": "'independent reproduction by a third party'; 'responsible disclosure'; 'affects any agent regardless of model' cited to the reproduction; push-access filter as a researcher proposal", "new": "reproduction described as posted, independence not established; disclosure wording as the record shows; claims attributed to the researchers and to the reproduction separately; maintainers' response recorded", "reason": "claims aligned to what each linked record says, found on review" }, { "date": "2026-10-13", "field": "fields", "old": "developer asked to 'check and fix' issues; maintainers' response paraphrased", "new": "request as the researchers quote it; maintainer's response in his own terms; push-access proposal attributed", "reason": "independent check against the linked records before right-of-reply letters" }, { "date": "2026-10-14", "field": "reviewed_by", "old": "none", "new": "Saurabh Bhatnagar (editor)", "reason": "case checked by the editor against its linked records" }, { "date": "2026-10-14", "field": "named_parties[GitHub].right_of_reply", "old": "{\"offered\": null, \"response\": null}", "new": "{\"offered\": \"2026-10-14\", \"response\": null}", "reason": "right of reply offered by email from register@secureautonomous.com to press@github.com on 14 October 2026 (confirmed in the Sent folder); recorded at the editor's instruction" }, { "date": "2026-10-16", "field": "inference.value", "old": "The injection is the trigger but the excessive authority is the enabling condition; with a repository-scoped token the same injection has nothing to exfiltrate", "new": "The injected text was the trigger, but the excess authority made the harm possible. With a token scoped to one repository, the same injection would have had nothing private to leak.", "reason": "Reworded for readers before the editor's sign-off, after an outside review found it read as internal notes; the interpretation itself is unchanged" }, { "date": "2026-10-16", "field": "controls.C-O1", "old": "succeeded: Responsible disclosure", "new": "not counted: C-O1 (coordinated disclosure): not evidenced; the record shows public disclosure by the researchers but no report to GitHub before publication", "reason": "Found in an outside review of the published record on 16 October 2026: the record has no disclosure to the vendor before publication, so a coordinated disclosure cannot be credited" }, { "date": "2026-10-20", "field": "title", "old": "GitHub MCP server: a public issue hijacks a coding agent into leaking private-repository data, disclosed 26 May 2025", "new": "GitHub MCP server: a public issue hijacks a user's agent into leaking private-repository data, disclosed 26 May 2025", "reason": "Found in the editor's source re-check of 19-20 October 2026: the Invariant Labs post describes 'a user's agent' and demonstrates with Claude Desktop, a general MCP client; 'coding agent' was the Register's label, not the source's" }, { "date": "2026-10-20", "field": "context.domain", "old": "Software agent (coding agent with repository tools)", "new": "Software agent (an MCP client with repository tools)", "reason": "Found in the editor's source re-check of 19-20 October 2026: the Invariant Labs post says the user 'is using an MCP client like Claude Desktop' and the demonstration ran on Claude Desktop with Claude 4 Opus" }, { "date": "2026-10-20", "field": "context.autonomy_level_text", "old": "Machine acts, human supervises (approval prompts present but often set to always allow)", "new": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; neither run records which setting was in force)", "reason": "Found in the editor's source re-check of 19-20 October 2026: Invariant Labs: 'Claude Desktop by default requires the user to confirm individual tool calls. However, many users already opt for an \"Always Allow\" confirmation policy'; neither the post nor issue #844 says which setting its run used" }, { "date": "2026-10-20", "field": "fields.Actor", "old": "A coding agent connected to the GitHub MCP server", "new": "Claude Desktop (a general MCP client, not specifically a coding agent) running Claude 4 Opus, connected to the GitHub MCP server; the researchers say the flaw is not specific to any agent or MCP client", "reason": "Found in the editor's source re-check of 19-20 October 2026: Invariant Labs: 'the user merely prompts Claude 4 Opus'; 'our experiments focused on Claude Desktop, the vulnerability is not specific to any particular agent or MCP client'" }, { "date": "2026-10-20", "field": "fields.Decision", "old": "The agent followed the injected instruction to read the user's other repositories and publish their contents", "new": "The agent followed the injected instruction, pulled private-repository data into its context and wrote pieces of it (the name of a private repository, 'Jupiter Star', a plan to relocate to South America, and a salary) into a pull request on the public repository", "reason": "Found in the editor's source re-check of 19-20 October 2026: Invariant Labs says the agent 'pulls private repository data into context' and exfiltrated 'several pieces of private information', naming the repository, the relocation plan and the salary; it does not say whole repository contents were published" }, { "date": "2026-10-20", "field": "fields.Envelope authority", "old": "The agent's token had access to the user's private repositories as well as the public one; the researchers called this an architectural issue rather than a code flaw", "new": "The agent was connected to the user's account with permission for the private repositories as well as the public one; the researchers call this a fundamental architectural issue, not a flaw in the server's code", "reason": "Found in the editor's source re-check of 19-20 October 2026: wording aligned to the primary record: Invariant Labs, 'this is not a flaw in the GitHub MCP server code itself, but rather a fundamental architectural issue'; DevClass, 'configured with permission for the private repositories'" }, { "date": "2026-10-20", "field": "fields.Envelope authority.source_ids", "old": "[\"DEVCLASS\"]", "new": "[\"INV\", \"DEVCLASS\"]", "reason": "Found in the editor's source re-check of 19-20 October 2026: the primary record (Invariant Labs) makes the architectural claim; the press summary only repeats it (runbook rule 15)" }, { "date": "2026-10-20", "field": "fields.Evidence scope", "old": "In the reproduction, a token limited to public repositories could still read private repositories but did not write their contents out; the full leak needed the broad token", "new": "The author of issue #844 reports that a token limited to public repositories still read the private repositories but did not write their contents out, and that the full leak needed the broad-scope token; the reproduction's independence from the researchers is not established", "reason": "Found in the editor's source re-check of 19-20 October 2026: issue #844 is a report by its author ('I reproduced the issue'; 'The token with only permission to public repositories did read the private repositories but not write information from them'); nothing in the record establishes who the author is or their independence" }, { "date": "2026-10-20", "field": "fields.Evidence scope.assertion_type", "old": "fact", "new": "assertion", "reason": "Found in the editor's source re-check of 19-20 October 2026: the claim is the issue author's own account, not a record by the responsible company or an established independent reproduction (runbook rule 2)" }, { "date": "2026-10-20", "field": "fields.Evidence scope.confidence", "old": "high", "new": "medium", "reason": "Found in the editor's source re-check of 19-20 October 2026: single unverified reporter; the reproduction's independence is not established" }, { "date": "2026-10-20", "field": "fields.Recovery technical", "old": "A GitHub maintainer called it an example of the 'lethal trifecta' risk for agents rather than a vulnerability in the conventional sense, and listed mitigations including lockdown and read-only modes and fine-grained tokens; a proposal to accept issues only from users with push access was raised in the server's tracker (issue #427, per DevClass)", "new": "On 10 December 2025 GitHub shipped an opt-in 'lockdown mode' for its MCP server, enabled by a request header, which surfaces only content from collaborators with push access on public repositories (private repositories are unaffected), and said content sanitization against prompt injection is on by default. On the server's issue tracker a GitHub maintainer listed mitigations on 20 April 2026 (lockdown mode, read-only mode, secret scanning on public-repository calls, OAuth 2.1, strict fine-grained tokens) and on 21 April 2026 wrote that it was 'not really a vulnerability in the conventional sense' but true of 'any tools that enable lethal trifecta' (his term for the agent-risk pattern). A proposal that the server accept issues only from users with push access was raised in the tracker (issue #427, per DevClass).", "reason": "Found in the editor's source re-check of 19-20 October 2026: the field omitted the fix GitHub shipped: the GitHub changelog of 10 December 2025 ('Lockdown mode ensures that only content from trusted collaborators with push access is surfaced'; 'Private repositories are unaffected'); the maintainer's comments on issue #844 are dated 20 and 21 April 2026" }, { "date": "2026-10-20", "field": "fields.Recovery technical.source_ids", "old": "[\"GH-844\", \"DEVCLASS\"]", "new": "[\"GH-LOCKDOWN\", \"GH-844\", \"DEVCLASS\"]", "reason": "Found in the editor's source re-check of 19-20 October 2026: new source GH-LOCKDOWN added for the shipped mitigation" }, { "date": "2026-10-20", "field": "fields.Recovery accountability", "old": "No regulator involved; the researchers published on 26 May 2025, and no record of prior disclosure to GitHub is public", "new": "The researchers published on 26 May 2025; the sources record no disclosure to GitHub before publication and no regulator action. On the server's tracker a question whether a CVE (a public vulnerability identifier) was issued went unanswered, and a GitHub maintainer wrote on 21 April 2026 that the report 'was reviewed' but was 'not really a vulnerability in the conventional sense'", "reason": "Found in the editor's source re-check of 19-20 October 2026: 'No regulator involved' was written without a source saying so; reworded to what the record shows, and the maintainer's own account on issue #844 (21 April 2026) added next to it (runbook rule 16)" }, { "date": "2026-10-20", "field": "fields.Recovery accountability.source_ids", "old": "[\"INV\"]", "new": "[\"INV\", \"GH-844\"]", "reason": "Found in the editor's source re-check of 19-20 October 2026: issue #844 carries the maintainer's account" }, { "date": "2026-10-20", "field": "controls.C-E3", "old": "Approval prompts (bypassed by always-allow habits)", "new": "Per-call approval prompts were present (Claude Desktop confirms tool calls by default; the reproduction shows a 'Continue' button with a 'See More' preview) and did not stop the public pull request; the researchers say many users choose Always Allow; neither run records which setting was in force", "reason": "Found in the editor's source re-check of 19-20 October 2026: the old note asserted the prompts were 'bypassed by always-allow habits'; Invariant Labs says only that many users opt for Always Allow, and issue #844 shows a Continue prompt; neither says which setting its run used. Bucket left as the editor's pending call" }, { "date": "2026-10-20", "field": "controls.C-E3.confidence", "old": "high", "new": "medium", "reason": "Found in the editor's source re-check of 19-20 October 2026: the counterfactual (whether a prompt reviewed before clicking would have stopped the leak) is not shown in the sources" }, { "date": "2026-10-20", "field": "controls.C-A1", "old": "Trust filtering on issue authors", "new": "The issue author's identity was not in doubt (any GitHub user may open an issue on a public repository); what was missing was a filter on whose content the agent reads, later shipped by GitHub as opt-in lockdown mode on 10 December 2025. Bucket left as the editor's pending call on whether this control fits", "reason": "Found in the editor's source re-check of 19-20 October 2026: Invariant Labs: 'By standard GitHub rules, an attacker can now create a malicious issue on the public repository'; GitHub changelog 10 December 2025 describes lockdown mode as surfacing only content from users with push access" }, { "date": "2026-10-20", "field": "inference.value", "old": "The injected text was the trigger, but the excess authority made the harm possible. With a token scoped to one repository, the same injection would have had nothing private to leak.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers say limiting the agent to the repositories it needs offers some protection and recommend a one-repository-per-session rule, but the posted reproduction reports that a token limited to public repositories still read private repositories, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "reason": "Found in the editor's source re-check of 19-20 October 2026: the counterfactual 'would have had nothing private to leak' was the Register's, not a source's; Invariant Labs says token-based permissions 'offer some protection', and issue #844 reports a public-only token still read private repositories. The interpretation was unsigned (signed_by null), so no signature is cleared" }, { "date": "2026-10-20", "field": "provenance_tier_text", "old": "Researcher disclosure with independent reproduction", "new": "Researcher disclosure with a reproduction posted on the server's issue tracker (independence not established)", "reason": "Found in the editor's source re-check of 19-20 October 2026: issue #844 is an anonymous user's report; nothing in the record establishes independence from the researchers" }, { "date": "2026-10-20", "field": "sources.GH-844.date", "old": null, "new": "2025-08-08", "reason": "Found in the editor's source re-check of 19-20 October 2026: the issue page's published time is 2025-08-08 (read through a reader proxy, r.jina.ai, because github.com blocked direct fetching from this session)" }, { "date": "2026-10-20", "field": "sources.GH-LOCKDOWN", "old": null, "new": "{\"title\": \"The GitHub MCP Server adds support for tool-specific configuration, and more\", \"type\": \"company\", \"url\": \"https://github.blog/changelog/2025-12-10-the-github-mcp-server-adds-support-for-tool-specific-configuration-and-more\", \"via_press\": false, \"date\": \"2025-12-10\", \"tier\": \"disclosure_corroborated\", \"interest\": \"vendor describing its own product\", \"primary\": true, \"checked\": \"2026-10-20\"}", "reason": "Found in the editor's source re-check of 19-20 October 2026: GitHub changelog of 10 December 2025 announcing lockdown mode, the shipped mitigation the Recovery field omitted" }, { "date": "2026-10-21", "field": "controls.C-E3", "old": "{\"bucket\": \"failed\", \"id\": \"C-E3\", \"note\": \"Per-call approval prompts were present (Claude Desktop confirms tool calls by default; the reproduction shows a 'Continue' button with a 'See More' preview) and did not stop the public pull request; the researchers say many users choose Always Allow; neither run records which setting was in force\", \"confidence\": \"medium\", \"basis\": \"curated\"}", "new": "{\"bucket\": \"absent\", \"id\": \"C-E5\", \"note\": \"No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts were present (Claude Desktop confirms tool calls by default; the reproduction shows a 'Continue' button with a 'See More' preview) and did not stop it; the researchers say many users choose Always Allow; neither run records which setting was in force\", \"confidence\": \"medium\", \"basis\": \"curated\"}", "reason": "Editor's classification call of 21 October 2026 (call 1, accepted from pull request #74): the approval prompts existed and did not stop the public pull request; the action was not irreversible destruction but data leaving for a public place, so the missing control is a limit on where data can go (containment and egress, C-E5), recorded as absent. The prompt facts are kept in the note." }, { "date": "2026-10-21", "field": "controls.C-A1", "old": "{\"bucket\": \"absent\", \"id\": \"C-A1\", \"note\": \"The issue author's identity was not in doubt (any GitHub user may open an issue on a public repository); what was missing was a filter on whose content the agent reads, later shipped by GitHub as opt-in lockdown mode on 10 December 2025. Bucket left as the editor's pending call on whether this control fits\", \"confidence\": \"medium\", \"basis\": \"curated\"}", "new": "{\"unmapped\": \"Content-source trust filter (not in the canonical set): The issue author's identity was not in doubt (any GitHub user may open an issue on a public repository); what was missing was a filter on whose content the agent reads, later shipped by GitHub as opt-in lockdown mode on 10 December 2025\"}", "reason": "Editor's classification call of 21 October 2026 (call 2, accepted from pull request #74): the issue author's identity was not in doubt, so actor identity verification does not fit; the gap was a filter on whose content the agent reads, which has no canonical control, so it is recorded as unmapped." }, { "date": "2026-10-21", "field": "inference.value", "old": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers say limiting the agent to the repositories it needs offers some protection and recommend a one-repository-per-session rule, but the posted reproduction reports that a token limited to public repositories still read private repositories, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: Invariant's post calls limiting access 'critical', says token-based permissions offer 'some protection', and gives the one-repository rule as an example policy for its own product (INV)." }, { "date": "2026-10-21", "field": "inference.value", "old": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: issue #844 says the public-only token could read private repositories 'but not write information from them' (GH-844)." }, { "date": "2026-10-21", "field": "inference.value", "old": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in either run, and shows no attack outside the demonstrations.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the posted reproduction shows a per-call 'Continue' prompt before the write that leaked the data), and shows no attack outside the demonstrations.", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: the reproduction posted in issue #844, run in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt on the file-write call that carried the leaked data, and its author writes 'Technically, there is human-in-the-loop verification' (GH-844)." }, { "date": "2026-10-21", "field": "context.autonomy_level_text", "old": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; neither run records which setting was in force)", "new": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt before the write that leaked the data)", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: the posted reproduction does show the setting in force (a per-call prompt), and it ran in GitHub Copilot in Visual Studio Code, not Claude Desktop (GH-844)." }, { "date": "2026-10-21", "field": "controls.C-E5", "old": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts were present (Claude Desktop confirms tool calls by default; the reproduction shows a 'Continue' button with a 'See More' preview) and did not stop it; the researchers say many users choose Always Allow; neither run records which setting was in force", "new": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow and do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt with a 'See More' preview before the write that leaked the data", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: the note mixed the two runs: the posted reproduction ran in GitHub Copilot in Visual Studio Code and shows the per-call prompt in force (GH-844); the researchers' run used Claude Desktop and does not record the setting (INV)." }, { "date": "2026-10-21", "field": "inference.signed_by", "old": "Saurabh Bhatnagar", "new": null, "reason": "The interpretation's wording changed after the editor signed it (second, independent check of 21 October 2026); the signature is cleared so the editor signs the corrected wording." }, { "date": "2026-10-21", "field": "controls.C-E5", "old": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow and do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt with a 'See More' preview before the write that leaked the data", "new": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt with a 'See More' preview before the write that leaked the data", "reason": "Found in the editor's second, independent check of the interpretations, 21 October 2026: third check: clarity; the second verb belongs to the researchers, not the users." }, { "date": "2026-10-22", "field": "context.autonomy_level_text", "old": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt before the write that leaked the data)", "new": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the reproduction posted in issue #844 shows a per-call 'Continue' prompt)", "reason": "Found in the independent re-read of 22 October 2026: the phrases 'in GitHub Copilot in Visual Studio Code' and 'before the write that leaked the data' rest on screenshots in issue #844 that the earlier check read through a proxy of a site the fetch tool declines (rule 21), and the reader of 22 October could not open them by permitted means; the claim is narrowed to what the issue's text shows (GH-844)." }, { "date": "2026-10-22", "field": "controls.C-E5", "old": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the reproduction posted in issue #844, in GitHub Copilot in Visual Studio Code, shows a per-call 'Continue' prompt with a 'See More' preview before the write that leaked the data", "new": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the reproduction posted in issue #844 shows a per-call 'Continue' prompt with a 'See More' preview", "reason": "Found in the independent re-read of 22 October 2026: the phrases 'in GitHub Copilot in Visual Studio Code' and 'before the write that leaked the data' rest on screenshots in issue #844 that the earlier check read through a proxy of a site the fetch tool declines (rule 21), and the reader of 22 October could not open them by permitted means; the claim is narrowed to what the issue's text shows (GH-844)." }, { "date": "2026-10-22", "field": "inference.value", "old": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the posted reproduction shows a per-call 'Continue' prompt before the write that leaked the data), and shows no attack outside the demonstrations.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the posted reproduction shows a per-call 'Continue' prompt), and shows no attack outside the demonstrations.", "reason": "Found in the independent re-read of 22 October 2026: the phrases 'in GitHub Copilot in Visual Studio Code' and 'before the write that leaked the data' rest on screenshots in issue #844 that the earlier check read through a proxy of a site the fetch tool declines (rule 21), and the reader of 22 October could not open them by permitted means; the claim is narrowed to what the issue's text shows (GH-844)." }, { "date": "2026-10-22", "field": "inference.signed_by", "old": "Saurabh Bhatnagar", "new": null, "reason": "The interpretation's wording changed after the editor signed it (re-read of 22 October 2026); the signature is cleared so the editor signs the corrected wording." }, { "date": "2026-10-22", "field": "context.autonomy_level_text", "old": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the reproduction posted in issue #844 shows a per-call 'Continue' prompt)", "new": "Machine acts, human supervises (Claude Desktop asks the user to confirm each tool call by default; the researchers say many users choose Always Allow; the researchers do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do)", "reason": "Found in the second independent re-read of 22 October 2026: the issue's readable text says there is human-in-the-loop verification, a 'Continue' button and a 'See More' preview; that the prompt appears per tool call rested on the screenshots, which cannot be read by permitted means (rule 21), so the claim is narrowed to the author's words (GH-844)." }, { "date": "2026-10-22", "field": "controls.C-E5", "old": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the reproduction posted in issue #844 shows a per-call 'Continue' prompt with a 'See More' preview", "new": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do", "reason": "Found in the second independent re-read of 22 October 2026: the issue's readable text says there is human-in-the-loop verification, a 'Continue' button and a 'See More' preview; that the prompt appears per tool call rested on the screenshots, which cannot be read by permitted means (rule 21), so the claim is narrowed to the author's words (GH-844)." }, { "date": "2026-10-22", "field": "inference.value", "old": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the posted reproduction shows a per-call 'Continue' prompt), and shows no attack outside the demonstrations.", "new": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the author of the posted reproduction writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do), and shows no attack outside the demonstrations.", "reason": "Found in the second independent re-read of 22 October 2026: the issue's readable text says there is human-in-the-loop verification, a 'Continue' button and a 'See More' preview; that the prompt appears per tool call rested on the screenshots, which cannot be read by permitted means (rule 21), so the claim is narrowed to the author's words (GH-844)." }, { "date": "2026-10-22", "field": "controls.C-E5", "old": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. Per-call approval prompts did not stop it: Claude Desktop, used in the researchers' run, confirms tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do", "new": "No limit on where the agent could send what it read: it was connected with permission for the private repositories as well as the public one, and it wrote private-repository data into a public pull request. No approval prompt is recorded stopping it: Claude Desktop, used in the researchers' run, confirms individual tool calls by default, though the researchers say many users choose Always Allow, and they do not say which setting their run used; the author of the reproduction posted in issue #844 writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do", "reason": "Found in the third independent re-read of 22 October 2026: the lead-in asserted that per-call prompts were in force and failed, but the researchers never state their run's setting (INV gives only Claude Desktop's default) and issue #844's text says nothing per call; the note itself goes on to say the setting is not recorded. Narrowed to what the sources show (INV, GH-844)." }, { "date": "2026-10-28", "field": "named_parties[GitHub].right_of_reply", "old": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}]}", "new": "{\"offered\": \"2026-10-14\", \"response\": null, \"assessed_through\": \"2026-10-22\", \"assessments\": [{\"through\": \"2026-10-22\", \"date\": \"2026-10-22\", \"by\": \"editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering\", \"triggered\": [], \"note\": \"no correction since the offer adds or worsens a claim about this party in words that are not its own\"}], \"no_response_as_of\": \"2026-10-28\"}", "reason": "right of reply recorded by a human" } ], "created": "2026-10-05", "last_reviewed": "2026-10-28", "actor_status": "confirmed", "provenance_tier_text": "Researcher disclosure with a reproduction posted on the server's issue tracker (independence not established)", "status_text": "Confirmed (demonstrated, not an attack in the wild)", "outcome": { "state": "averted_by_disclosure", "severity": "none (demonstration)", "affected_parties": [], "cost": "none", "regime_consequence": "none", "as_of": "2025", "derived_by": "backfill-curated" }, "inference": { "value": "The injected issue text was the trigger; the agent's access to the user's private repositories as well as the public one is what gave the injection something to leak. The researchers call it critical to limit the agent to the repositories it needs, say traditional token-based permissions offer some protection, and give a one-repository-per-session rule as an example policy for their own Guardrails product, but the posted reproduction reports that a token limited to public repositories still read private repositories, though it did not write their contents out, so the record does not settle how far token scoping alone would have prevented the leak. The record also does not show which approval setting was in force in the researchers' run (the author of the posted reproduction writes that there is human-in-the-loop verification, a 'Continue' button with a 'See More' preview of what the click will do), and shows no attack outside the demonstrations.", "source_ids": [ "INV", "GH-844" ], "confidence": "high", "signed_by": "Saurabh Bhatnagar", "signed_on": "2026-10-22" }, "named_parties": [ { "name": "GitHub", "right_of_reply": { "offered": "2026-10-14", "response": null, "assessed_through": "2026-10-22", "assessments": [ { "through": "2026-10-22", "date": "2026-10-22", "by": "editor's call of 22 October 2026 on the rule 19 review by four independent agents (reports rule19_1 to rule19_4); GitHub (REG-0005) judged borderline and not triggering", "triggered": [], "note": "no correction since the offer adds or worsens a claim about this party in words that are not its own" } ], "no_response_as_of": "2026-10-28" } } ], "sources": { "DEVCLASS": { "title": "Researchers warn of prompt injection vulnerability in GitHub MCP with no obvious fix (DevClass, Tim Anderson)", "type": "press_pointer", "url": "https://devclass.com/2025/05/27/researchers-warn-of-prompt-injection-vulnerability-in-github-mcp-with-no-obvious-fix/", "via_press": true, "date": "2025-05-27", "tier": "disclosure_corroborated", "interest": null, "primary": false, "checked": "2026-10-20" }, "GH-844": { "title": "github/github-mcp-server issue #844: 'Exfiltrate information from private repositories'", "type": "reproduction", "url": "https://github.com/github/github-mcp-server/issues/844", "via_press": false, "date": "2025-08-08", "tier": "disclosure_corroborated", "interest": null, "primary": true, "checked": "2026-10-20" }, "INV": { "title": "GitHub MCP Exploited: Accessing private repositories via MCP (Invariant Labs blog, Marco Milanta and Luca Beurer-Kellner)", "type": "researcher", "url": "https://invariantlabs.ai/blog/mcp-github-vulnerability", "via_press": false, "date": "2025-05-26", "tier": "disclosure_corroborated", "interest": null, "primary": true, "checked": "2026-10-20" }, "GH-LOCKDOWN": { "title": "The GitHub MCP Server adds support for tool-specific configuration, and more", "type": "company", "url": "https://github.blog/changelog/2025-12-10-the-github-mcp-server-adds-support-for-tool-specific-configuration-and-more", "via_press": false, "date": "2025-12-10", "tier": "disclosure_corroborated", "interest": "vendor describing its own product", "primary": true, "checked": "2026-10-20" } }, "derived_by": "backfill-curated", "reviewed_by": "Saurabh Bhatnagar (editor)", "dec_group": "direct", "ctl_names": [ "Least-privilege credential scoped to task", "Containment and isolation", "Retrieved content as data" ] }