VS Code config files abused to launch RCEs via GitHub Codespaces

Multiple attack vectors were observed in the GitHub Codespaces developer environment that lets attackers run a remote code execution (RCE) by opening a malicious repository or pull request.

In a Feb. 4 blog, Orca researchers found that by abusing VS Code config files automatically respected by Codespaces, attackers can execute arbitrary commands, exfiltrate GitHub tokens and secrets, and abuse hidden APIs to access premium Copilot models.

According to the researchers, Codespaces lets developers review pull requests, test code, or spin up services without configuring local machines. However, this convenience means repository-defined configs such as .vscode/ and .devcontainer/ files are automatically executed within Codespaces, creating an open attack surface.

"It makes sense to think about developer environments as a key part of any supply chain attack, as devs typically keep many secrets locally, outside of encrypted secret management systems,” said Dwayne McDaniel, developer advocate at GitGuardian. “Getting one developer to install a malicious extension can lead to dozens, or hundreds, of secrets leaked that can be weaponized within hours of discovery."

McDaniel added that developers work at the beginning of the supply chain, creating the code itself that eventually will be built and distributed, so it only makes sense that attackers would targeted them.

Related reading:

"Developers have always been targets, attacks like S1ngularity and Shai-Hulud show their local environments are increasingly the favored attack surface,” said McDaniel. "The only true protection is to eliminate long-lived, hard-coded, plain-text secrets from the dev environment, including ENV variables and local configs. There are lots of solutions, including open-source approaches like Mozilla SOPS and KeePass, and projects like fnox, that make this achievable, but adoption is not at the same level as we see for browser-based password managers."

Jonathan Stross, SAP Security Analyst at Pathlock, called this recent case a “plain and simple” governance failure. Stross said companies are handing out access through automation and developer tools without fully understanding what they're enabling.

More organizations are moving to cloud dev environments like Codespaces — especially those connected to ERP systems and critical business apps, said Stross. When a VS Code configuration file can execute code automatically, we’ve essentially created a backdoor that looks completely legitimate, said Stross.

“An attacker doesn’t need to break in — they just need to submit or influence a pull request containing malicious workspace configuration,” explained Stross. “When a developer opens that repository or pull request, the code executes automatically, and the attacker is suddenly operating inside the environment with the same permissions the developer has.”

For organizations, Stross said it creates risks in three dimensions:

Supply chain risk: One bad pull request can compromise the organization’s entire development pipeline and everything connected to it.
Credential exposure: Developers typically have elevated access to ERPs, databases, and internal systems. A compromised Codespace inherits all of this.
Network access: Once attackers are in a trusted developer environment, they can move laterally to other internal resources that assume the session is legitimate.

Stross added that teams should take these four steps to protect against these risks:

Turn off automatic execution of workspace configs: It's important that only developers can explicitly approve them.
Stop giving dev environments full production credentials: Use temporary, limited tokens instead.
Conduct more precise reviews: Start reviewing .vscode files and similar configs the same way the team would review actual code.
Keep Codespaces segmented: Isolate Codespaces from production networks and sensitive systems.