# CVE-2021-32638: CodeQL runner: Command-line options that make GitHub access tokens visible to other processes are now deprecated

> Passing GitHub tokens via command-line arguments exposes them to other processes, allowing attackers to steal credentials if process lists are logged.

- **Severity:** Medium 4.4 (`CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N`)
- **Exploited in the wild:** Not known
- **Login needed:** An administrator
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** No
- **Published:** 25 May 2021
- **Updated:** 3 Aug 2024
- **Also known as:** GHSA-g36v-2xff-pv5m

## What is CVE-2021-32638?

CVE-2021-32638 is a medium-severity vulnerability in github codeql-action, published on 25 May 2021. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

Github's CodeQL action is provided to run CodeQL-based code scanning on non-GitHub CI/CD systems and requires a GitHub access token to connect to a GitHub repository. The runner and its documentation previously suggested passing the GitHub token as a command-line parameter to the process instead of reading it from a file, standard input, or an environment variable. This approach made the token visible to other processes on the same machine, for example in the output of the `ps` command. If the CI system publicly exposes the output of `ps`, for example by logging the output, then the GitHub access token can be exposed beyond the scope intended. Users of the CodeQL runner on 3rd-party systems, who are passing a GitHub token via the `--github-auth` flag, are affected. This applies to both GitHub.com and GitHub Enterprise users. Users of the CodeQL Action on GitHub Actions are not affected. The `--github-auth` flag is now considered insecure and deprecated. The undocumented `--external-repository-token` flag has been removed. To securely provide a GitHub access token to the CodeQL runner, users should **do one of the following instead**: Use the `--github-auth-stdin` flag and pass the token on the command line via standard input OR set the `GITHUB_TOKEN` environment variable to contain the token, then call the command without passing in the token. The old flag remains present for backwards compatibility with existing workflows. If the user tries to specify an access token using the `--github-auth` flag, there is a deprecation warning printed to the terminal that directs the user to one of the above options. All CodeQL runner releases codeql-bundle-20210304 onwards contain the patches. We recommend updating to a recent version of the CodeQL runner, storing a token in your CI system's secret storage mechanism, and passing the token to the CodeQL runner using `--github-auth-stdin` or the `GITHUB_TOKEN` environment variable. If still using the old flag, ensure that process output, such as from `ps`, is not persisted in CI logs.

Weakness: CWE-214 (Invocation of Process Using Visible Sensitive Information), CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor)

## Which versions are affected by CVE-2021-32638?

It affects 1 product.


Products: Github Codeql Action.

## How do I fix CVE-2021-32638?

No fix has been published for CVE-2021-32638 yet. Limit exposure of the affected software until one is available.

## Is CVE-2021-32638 being exploited?

There is no known exploitation of CVE-2021-32638 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for CVE-2021-32638 and fix it if it is affected.

What it is: CVE-2021-32638 is a medium-severity vulnerability in github codeql-action, published on 25 May 2021. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of CVE-2021-32638 in the wild and no public exploit code.

Affected product: github codeql-action. No package-level version data is available, so check the vendor advisory linked from the reference page.

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/CVE-2021-32638/ (Markdown: https://insights.sbomify.com/CVE-2021-32638/index.md)
```

## Sources

- CVE record: https://www.cve.org/CVERecord?id=CVE-2021-32638
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2021-32638
- OSV: https://osv.dev/vulnerability/CVE-2021-32638

---
From sbomify Insights: https://insights.sbomify.com/CVE-2021-32638/
Summaries are generated and may contain mistakes; the official description above is the record.
