CVE-2026-45793

Composer leaks the full contents of tokens configured as GitHub OAuth tokens if they do not match Composer's expected format for such tokens to stderr. GitHub has introduced a new format for GitHub Actions GITHUB_TOKEN values. These tokens are validated in the same way by Composer on GitHub Actions. The new format including a - (hyphen) fails Composer's validation and leads to disclosure of the GITHUB_TOKEN in logs.

Many widely-used Actions (e.g. shivammathur/setup-php) auto-register GITHUB_TOKEN into composer's global auth.json, so the leak triggers without any unusual user configuration.

GitHub Actions tokens expire when the associated job finishes, and they are scoped to the respective repository only. So in most regular cases the Composer validation, which errors while leaking the token, also immediately ends the job, expiring the token immediately. Tokens expire at the very latest after 6 hours on GitHub-hosted runners. If you use self-hosted runner, expiration is at most 24 hours after creation. The new token format is being rolled out gradually, so not all repositories are affected yet, but will be soon.

Classic ghp_ PATs are not affected by the regex bug per se, but the same leak primitive applies to any future credential that fails validation for any reason.

Details

When a GitHub token fails regular expression validation of the character set, the rejected token is interpolated verbatim into the UnexpectedValueException message thrown by Composer\IO\BaseIO::loadConfiguration(), which Symfony Console then prints. Validation reliably fails for any token containing a - (hyphen), which includes the modern ghs_<id>_<base64url-JWT> GitHub App installation token format, the same format used by GitHub Actions' built-in GITHUB_TOKEN and by actions/create-github-app-token.

Severity: medium. Pre-conditions are common in real-world CI. Practical blast radius is bounded by the leaked credential's scope and TTL (short for a workflow GITHUB_TOKEN, longer for App-minted tokens or user-issued credentials that happen to contain -).

Vulnerable code, src/Composer/IO/BaseIO.php (line 139 on main, line 143 on 2.8.x), inside loadConfiguration():

// allowed chars for GH tokens are from https://github.blog/changelog/2021-03-04-authentication-token-format-updates/
// plus dots which were at some point used for GH app integration tokens
if (!Preg::isMatch('{^[.A-Za-z0-9_]+$}', $token)) {
    throw new \UnexpectedValueException(
        'Your github oauth token for '.$domain.' contains invalid characters: "'.$token.'"'
    );
}

Three issues combine to produce the leak:

1. The rejected token is interpolated into the exception message. The exception bubbles up to Symfony Console's default error renderer, which writes it to stderr. Any environment that captures stderr (CI logs, log shippers, monitoring, support transcripts) now has the raw token.

2. The validation regex ^[.A-Za-z0-9_]+$ does not permit -. GitHub's current ghs_<numeric-id>_<base64url-JWT> structured installation tokens routinely contain -, because base64url (RFC 4648 §5) uses - and _ as URL-safe replacements for + and /. The regex was chosen in 2021 on the understanding that GitHub tokens use only [A-Za-z0-9_] plus ..

3. Detection / mitigation in upstream platforms is unreliable. GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log.

CVE-2026-45793 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (2.9.8, 2.2.28, 1.10.28); upgrading removes the vulnerable code path.

Kodem intelligence

1. What is CVE-2026-45793? CVE-2026-45793 is a high-severity security vulnerability in composer/composer (composer), affecting versions >= 2.3.0, < 2.9.8. It is fixed in 2.9.8, 2.2.28, 1.10.28.
2. How severe is CVE-2026-45793? CVE-2026-45793 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of composer/composer are affected by CVE-2026-45793? composer/composer (composer) versions >= 2.3.0, < 2.9.8 is affected.
4. Is there a fix for CVE-2026-45793? Yes. CVE-2026-45793 is fixed in 2.9.8, 2.2.28, 1.10.28. Upgrade to this version or later.
5. Is CVE-2026-45793 exploitable, and should I be worried? Whether CVE-2026-45793 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-45793 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-45793?
   • Upgrade composer/composer to 2.9.8 or later
   • Upgrade composer/composer to 2.2.28 or later
   • Upgrade composer/composer to 1.10.28 or later