How Hidden GitHub Issue Comments Can Hijack Copilot Agents

Summary

BeyondTrust's Phantom Labs describes a proof-of-concept attack against GitHub Copilot's coding agent in research published October 21, 2026. An attacker-controlled issue comment can contain instructions invisible in the rendered discussion but still consumed by the agent. The critical activation step is manual assignment by a user with repository write access. The supplied evidence documents research and disclosure, not a confirmed malicious campaign or in-the-wild exploitation.^[0]

In the demonstrated chain, hidden instructions induced installation of a malicious dependency, which replaced the ls command and subsequently executed a credential-stealing payload. The researchers exfiltrated credentials through GitHub repositories, using GitHub's allowed status in the Copilot firewall. A stolen Copilot installation token could modify copilot/-prefixed branches and produce commits displayed as verified; separately, environment scraping exposed repository- and organization-scoped agent secrets available to the runtime.^[0]

The most extensive impact depended on repository configuration. Removing workflow-approval requirements enabled escalation through a planted workflow. Permissions granted in copilot-setup-steps.yml exposed an additional GitHub Actions token recoverable from runner memory: contents: write permitted modification of unprotected branches, while id-token: write enabled an OIDC escalation path when cloud trust policies accepted the resulting identity. The researchers demonstrated AWS role assumption and S3 bucket listing in their own environment, not universal access to connected cloud accounts.^[0]

BeyondTrust reports that the behavior remained unpatched as of October 15, 2026. According to its account, GitHub considered the findings informational because assigning Copilot required an authorized write-access user and therefore did not bypass an authorization control. This vendor position and the technical results are single-source reporting in the supplied evidence. The practical defensive priorities are raw-Markdown inspection before assignment, minimal runtime privileges and secrets, restrictive cloud trust, and human approval of workflows and Copilot-authored changes.^[0]

Attack chain

1. 1. Hidden issue-comment delivery and authorized assignment: The researchers placed prompt-injection instructions inside an HTML comment in an otherwise ordinary-looking issue comment. They report using Copilot-specific XML parsing behavior to keep the instructions invisible in the rendered view while making them available to the agent. A repository user with write access then assigned the issue to Copilot, activating the demonstrated path.^[0]
2. 2. Dependency installation induced through prompt injection: The hidden instructions directed Copilot to install a dependency and then run ls. The researchers selected the dependency-installation pretext after finding that requests to reproduce unknown compiled binaries were less reliable and more likely to attract the agent's scrutiny.^[0]
3. 3. Payload execution through command replacement: Installation of the malicious package replaced the ls command. When the agent subsequently used that command, the replacement retrieved the actual malware payload, substituted an executable, and ran it inside the Copilot environment.^[0]
4. 4. Credential collection and allowed-channel exfiltration: The payload sent credentials to a researcher-controlled GitHub repository using Git operations. GitHub was on the runtime firewall allow-list, so this channel did not require unrestricted external connectivity. The researchers also demonstrated scraping runtime environment variables to obtain configured repository and organizational agent secrets.^[0]
5. 5. Copilot-branch modification: The recovered Copilot installation token allowed creation of branches and content changes under the copilot/ prefix. The researchers demonstrated that these changes appeared as verified commits, establishing a path to poison Copilot branches and pull requests before human merge.^[0]
6. 6. Conditional escalation through workflow execution: Where the default requirement to approve workflow runs had been disabled, the token could push a workflow that executed with a more privileged GITHUB_TOKEN. The report identifies approval configuration as the condition separating a planted workflow from automatic execution.^[0]
7. 7. Conditional recovery of setup-granted Actions privileges: When copilot-setup-steps.yml granted additional permissions, the researchers scraped Runner.Worker process memory to recover an additional GitHub Actions token. With contents: write in their test configuration, they used it to push a file to an unprotected main branch.^[0]
8. 8. Conditional cloud federation escalation: With id-token: write enabled, the researchers requested a GitHub Actions identity token. Their AWS role trusted the GitHub organization and repository broadly enough to accept that identity; they exchanged it through AWS STS, assumed the role, and successfully listed S3 buckets. This was a configuration-dependent extension of the proof of concept.^[0]

Disclosure timeline

How it works

The initial trust-boundary problem is the difference between the rendered issue comment reviewed by a person and the source content processed by the agent. HTML comments conceal text from the normal rendered view. The researchers report that Copilot-specific XML elements inside that hidden content were nevertheless processed, allowing attacker-supplied instructions to influence agent behavior. The supplied extraction does not expose the concrete XML tag names.^[0]

The payload used an apparently development-related dependency request to obtain code execution. Rather than directly requesting execution of an unexplained binary, it induced package installation. The package replaced a routine command, ls, so the agent's subsequent use of that command triggered payload retrieval and execution. This connects a prompt-injection decision to execution inside the agent's privileged runtime.^[0]

The network control did not prevent exfiltration through an already permitted development platform. The researchers observed github.com on the firewall allow-list and used Git push operations to move stolen credentials into their own repository. A narrowly scoped personal access token embedded in the malware authorized those writes; the researchers report XOR-obfuscating it to avoid secret-scanning detection and recovering it at runtime.^[0]

Credential lifetime and branch permissions were examined separately during reconnaissance. The researchers observed three tokens associated with a cleanup request and found that the tokens were unusable after cleanup but remained functional when they blocked the request. They then established that the Copilot installation token had branch-specific capabilities not apparent from the initially observed response headers: it could create and modify copilot/-prefixed branches, and resulting commits appeared verified. The report does not establish an unconditional token lifetime across deployments.^[0]

Agent secrets and the additional Actions token occupied different locations. Configured repository and organizational agent secrets were recovered from process environment variables. By contrast, the additional GITHUB_TOKEN associated with setup-file permissions was recovered from Runner.Worker process memory rather than ordinary environment scraping. The demonstrated secret exposure concerns credentials made available to the compromised runtime, not every unrelated organizational secret.^[0]

Two distinct configuration-dependent routes expanded repository impact. First, if workflow approval was disabled, a Copilot-pushed workflow could execute and obtain a more privileged GITHUB_TOKEN. Second, permissions granted directly through copilot-setup-steps.yml were available through the recovered Actions token. In the contents: write test, that token could change branches without branch protection, including the researchers' main branch.^[0]

Cloud escalation required both the ability to request an identity token and an accepting federation policy. The researchers enabled id-token: write, obtained a JWT, and used an AWS role whose trust was scoped to the organization and repository rather than excluding the Copilot identity. Successful AWS role assumption and S3 listing demonstrated that case. The article discusses analogous exposure for Azure and GCP, but the supplied evidence demonstrates AWS rather than completed takeovers across all three providers.^[0]

Affected versions and patch status

Key takeaways

• Human authorization of an agent task does not mean the human reviewed every instruction the agent receives. This proof of concept exploits the gap between rendered issue content and hidden source text processed by Copilot.^[0]
• Impact must be separated by credential and configuration: the Copilot token affected copilot/ branches, available agent secrets exposed their protected resources, and setup-granted Actions or OIDC permissions enabled broader conditional escalation.^[0]
• An allow-listed development platform can also serve as an exfiltration destination. In this research, permitting GitHub connectivity allowed credential transfer through repositories without opening unrestricted outbound access.^[0]
• Treat the publication as a single-source research disclosure, not evidence of an active campaign or inevitable cloud takeover. The demonstrated AWS result depended on explicit permissions and an accepting trust policy; the reported unpatched status and GitHub response are attributed to BeyondTrust.^[0]

Defensive actions

• Inspect the raw Markdown of issue comments before assigning them to Copilot.: The entry-point instructions are hidden in the rendered comment. The report recommends using the edit view or copying Markdown and inspecting the pasted source to reveal concealed instructions before the authorized assignment step.^[0]
• Restrict Copilot enablement to selected private or internal repositories where practical.: The report recommends disabling Copilot on public repositories to reduce exposure to attacker-supplied issue content and limit the blast radius of this delivery path.^[0]
• Add organizational instructions discouraging dependency downloads from unknown or unpopular repositories.: The proof of concept uses a malicious dependency installation as the bridge from hidden instructions to payload execution. BeyondTrust recommends this guardrail as a defensive measure, not as a demonstrated complete fix.^[0]
• Minimize agent secrets, keep high-value credentials out of organization-wide agent scope, and rotate secrets after suspicious Copilot runs.: The researchers recovered configured agent secrets through environment scraping. The report recommends repository-scoped, short-lived secrets so that runtime compromise exposes fewer credentials and stolen values remain useful for less time.^[0]
• Treat copilot-setup-steps.yml as a privileged configuration and remove unnecessary permissions, especially contents: write and id-token: write.: The researchers recovered an additional Actions token carrying setup-granted permissions. These two permissions enabled the demonstrated unprotected-branch modification and conditional cloud-federation paths.^[0]
• Constrain cloud OIDC trust to intended branches or environments rather than broadly trusting an organization or repository.: The cloud proof of concept depended on a role accepting the Copilot-generated identity. The report recommends pinning the subject claim, avoiding wildcard subject conditions, keeping role sessions short, and limiting role permissions to required resources.^[0]
• Retain and verify the requirement to approve workflow runs in every Copilot-enabled repository.: Approval is enabled by default according to the report. Removing it allowed a workflow planted through a Copilot branch to execute automatically and obtain an escalated GITHUB_TOKEN.^[0]
• Require an additional human reviewer for Copilot-authored pull requests.: The stolen Copilot token could modify copilot/-prefixed branches and produce verified-looking commits. The report recommends GitHub's additional-reviewer ruleset option to add a manual decision before poisoned changes are merged.^[0]
• Monitor Copilot activity through GitHub audit logs and investigate suspicious agent runs.: The report identifies audit logs as a place to monitor Copilot activity and warns that the agent may remain unaware of compromise. Monitoring complements, but does not replace, source-comment inspection and privilege reduction.^[0]