GitHub Codespaces turns repository trust into remote code execution

At a glance

What this is: This is an analysis of how GitHub Codespaces can turn repository-defined settings into automatic execution paths that expose tokens, secrets, and downstream access.

Why it matters: It matters because IAM and security teams must treat developer environments as identity-bearing execution surfaces, where NHI, delegated access, and human workflows intersect.

👉 Read Orca Security's analysis of GitHub Codespaces remote code execution paths

Context

GitHub Codespaces is a cloud developer environment, but the trust model is broader than many teams assume. When repository content can drive terminal settings, tasks, and devcontainer hooks, the environment stops behaving like a passive workspace and starts acting like an execution surface tied to identity and secrets.

For IAM and security programmes, the issue is not only code execution. It is that repository-supplied configuration can access GitHub tokens, exposed secrets, and internal knowledge sources through the same session that a developer uses to review code, which makes zero trust for developer context a governance problem, not just an AppSec problem.

Key questions

Q: What breaks when repository-defined settings are allowed to run automatically in Codespaces?

A: The main failure is that a workspace review becomes an execution event. Commands in settings, tasks, or devcontainer hooks can run before the user has a chance to validate the repository, which turns code review into a token and secret exposure path. That is why developer environment trust needs the same scrutiny as production access.

Q: Why do Codespaces-style developer environments increase NHI risk?

A: They increase NHI risk because the active credential is often a runtime token or secret, not the human user alone. If that token can reach repositories, secrets, or downstream APIs, the compromise domain expands beyond the person opening the workspace. Identity teams should govern those tokens as first-class non-human identities.

Q: How do security teams reduce the blast radius of malicious pull requests in cloud dev environments?

A: They should block automatic execution paths on untrusted repositories, require additional approval for forks and external pull requests, and separate review environments from repositories that can touch sensitive secrets. The goal is to keep repository content from becoming an execution authority.

Q: What should teams do when a developer environment can call hidden or undocumented APIs?

A: They should add those paths to access governance, secrets risk reviews, and incident response playbooks. If a stolen token can exchange into another bearer token or trigger AI service usage, the real control boundary is the API path, not the visible account screen.

Technical breakdown

How repository-defined configuration becomes execution in Codespaces

Codespaces inherits VS Code and devcontainer behaviour that can execute repository-controlled settings when a folder, task, or container starts. Files such as .vscode/tasks.json, .vscode/settings.json, and .devcontainer/devcontainer.json are designed to improve developer experience, but they also create automatic command paths. If a malicious repository injects commands into those files, the environment can run them as soon as the user opens the workspace or accepts default behaviour. The important point is that the execution comes from trusted workflow mechanics, not from an exploit in the traditional sense.

Practical implication: review which repository files can trigger code execution before allowing Codespaces use on sensitive repositories.

Why GitHub tokens and secrets are exposed in the Codespaces session

The research shows that once code execution is achieved, the attacker can reach environment variables, Codespaces secrets, and shell history. In a cloud dev environment, the GitHub token is often present in cleartext runtime context, which is a very different risk profile from a locally protected keychain. That means compromise of the workspace can become compromise of the identity used inside the workspace. This is a classic NHI problem because the token, not the human account, becomes the immediate bearer of access.

Practical implication: classify Codespaces tokens and secrets as high-risk NHIs and scope them for the smallest possible repository and session boundary.

How hidden GitHub APIs extend the blast radius

Orca Security also showed that exfiltrated GitHub tokens can be used against undocumented Copilot-related endpoints to obtain additional bearer tokens and issue prompts on behalf of the victim. That turns one compromised workspace into a path for broader account misuse, including access to premium model features and potentially internal knowledge bases in enterprise settings. The governance issue is not only secret theft. It is delegated identity abuse through APIs that are not usually part of normal access review or entitlement inventory.

Practical implication: inventory undocumented and indirect APIs in your identity threat model, not only the documented developer-facing ones.

Threat narrative

Attacker objective: The attacker wants to convert a single malicious repository interaction into maintainer-level access, secret theft, and downstream supply-chain or data exposure.

1. Entry occurs when a maintainer opens a malicious repository or pull request inside Codespaces and repository-supplied configuration is allowed to run automatically.
2. Credential access follows when injected commands exfiltrate GitHub tokens, Codespaces secrets, shell history, and other runtime environment data.
3. Impact occurs when the stolen token is used for maintainer impersonation, supply-chain abuse, hidden API access, and possible exposure of enterprise knowledge data.

Breaches seen in the wild

• Emerald Whale breach — exposed Git config files led to 15K secrets stolen and 10K repo compromises.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Repository-defined execution is now an identity problem, not only an application problem. Codespaces shows that a workspace can inherit enough trust from repository content to execute attacker-controlled commands before many teams realise a boundary has been crossed. That collapses the old assumption that a developer environment is merely a place where code is reviewed. Practitioners should treat repo-driven execution paths as part of identity governance, not just secure development tooling.

Ephemeral developer sessions still produce durable NHI exposure when tokens live in the runtime. The GitHub token inside Codespaces is the operational identity that matters once the session starts. If that token can read secrets, interact with repositories, or trigger downstream APIs, then one workspace compromise becomes a wider non-human identity issue. The implication is that teams need to govern runtime credentials as first-class identities, not as incidental environment variables.

Implicit trust in repository-supplied settings is a standing-privilege assumption disguised as convenience. Those settings were designed for a controlled developer workflow, but the article shows they can be weaponised by a malicious pull request or fork. That assumption fails when the actor controlling the repository content is not the actor controlling the execution. The implication is that least privilege must extend to the configuration channel itself, not only to the code being reviewed.

Hidden API use expands the identity surface beyond what most governance programmes inventory. The ability to exchange a stolen token for additional bearer access through undocumented endpoints means entitlement review alone is incomplete. A team can certify the visible account and still miss the paths that actually enable misuse. Practitioners should widen their identity model to include indirect token exchange and model-access pathways.

Identity blast radius: Codespaces can turn a single pull request into a multi-step compromise path that crosses repository access, runtime secrets, maintainers' privileges, and downstream AI service usage. That makes blast radius the more useful control lens than any single hardening measure. The field should stop treating developer-environment execution as isolated convenience and start treating it as a governed identity corridor.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The State of Secrets Sprawl 2025.
• GitGuardian also found that 38% of secrets incidents in collaboration and project management tools like Slack, Jira, and Confluence are classified as highly critical or urgent.
• For a broader control lens, read The 52 NHI breaches Report for repeated patterns of secret exposure and credential abuse across real incidents.

What this signals

Repository execution is becoming part of the identity perimeter. Teams that already govern service accounts, tokens, and secrets need to extend that discipline into developer environments where repository content can trigger code. A useful signal here is whether your controls separate trusted code from trusted configuration, because Codespaces-style workflows blur that boundary immediately.

The practical planning question is no longer whether developers can use cloud workspaces, but whether those workspaces are allowed to inherit execution authority from untrusted repositories. That makes pull-request hygiene, secret inventory, and token scoping converge into one programme decision.

The relevant standard lens is OWASP Non-Human Identity Top 10, because the problem is runtime credential exposure and abuse rather than ordinary application access. If your programme does not model developer workspace tokens as NHIs, it is missing the control surface that matters most.

For practitioners

• Restrict automatic execution in Codespaces Disable or tightly gate repository files that can run commands on folder open, container start, or task load for sensitive repos. Review .vscode and .devcontainer paths as execution channels, not only as configuration.
• Treat workspace tokens as high-risk identities Scope GitHub and Codespaces tokens to the smallest viable permissions and shorten their useful lifetime where the platform allows. Assume any token present in runtime context can be exfiltrated and reused.
• Add pull-request controls for developer environments Require extra review for forks and external pull requests that target repositories permitted for Codespaces use. Block automatic workspace creation on untrusted contributions until configuration files are checked.
• Inventory indirect API paths and model access Map undocumented, bearer-token-exchange, and AI-service endpoints into your access review process. Include identity-to-API paths that are not visible in ordinary repository permission reporting.

Key takeaways

• GitHub Codespaces can convert repository configuration into automatic command execution, which turns code review into a security boundary.
• The immediate risk is not just remote code execution but the theft and reuse of GitHub tokens, secrets, and downstream API access.
• The control answer is to govern developer workspaces, runtime tokens, and untrusted pull requests as part of the identity programme, not as isolated engineering exceptions.

Key terms

• Codespaces execution surface: The set of repository files, workspace settings, and container hooks that can cause commands to run inside a cloud developer environment. In practice, it is an identity-sensitive execution boundary because it can turn untrusted repository content into runtime action and credential exposure.
• Runtime token: A credential present in a live session that authorises actions on behalf of a user or service while the environment is active. In developer tooling, runtime tokens often function like non-human identities because they can be reused, exchanged, or abused without the human being directly involved.
• Identity blast radius: The total downstream access that can be reached once a credential, token, or delegated session is compromised. In a Codespaces scenario, blast radius includes repositories, secrets, APIs, and any indirect services reachable from the stolen identity, not just the initial workspace.

Deepen your knowledge

Repository-supplied execution paths and token exposure are covered in the NHI Foundation Level course, the industry's only accredited NHI security programme. If you are extending identity governance into developer environments, the course helps connect workspace risk to broader NHI controls.

This post draws on content published by Orca Security: GitHub Codespaces remote code execution and secret exposure analysis. Read the original.