Packagist Warns PHP Developers to Update Composer After GitHub Token Leak

Packagist is urging PHP developers to update Composer after a vulnerability exposed some GitHub Actions tokens in CI logs. The issue is tracked as CVE-2026-45793 and GHSA-f9f8-rm49-7jv2.

The flaw affects Composer when it handles GitHub tokens that do not match its expected token format. In affected cases, Composer rejected the token and printed the full value to stderr, which GitHub Actions then stored in job logs.

The risk matters because many PHP projects run Composer inside GitHub Actions. If a workflow used the new GitHub token format during the rollout window, the token may have appeared in logs without developers noticing immediately.

What caused the Composer token leak

The problem started after GitHub began rolling out a new format for GitHub App installation tokens. GitHub said the updated format would use longer, variable-length tokens and include a JWT-based structure.

Composer’s validation logic expected GitHub tokens to use a narrower character set. The new format can include a hyphen, which Composer did not allow in its validation pattern.

When Composer saw one of those tokens, it threw an error. The error message included the rejected token value in full, which created the credential leak.

Item	Details
Vulnerability	CVE-2026-45793
Advisory	GHSA-f9f8-rm49-7jv2
Product	Composer
Issue	GitHub token disclosure in CI logs
Patched versions	Composer 2.9.8, 2.2.28 LTS, and 1.10.28

Which Composer versions are affected

The GitHub advisory lists three affected version ranges. Composer 2.3.0 through versions before 2.9.8 are affected. Composer 2.0.0 through versions before 2.2.28 are also affected.

Composer 1.x users are affected when running versions before 1.10.28. Packagist still recommends moving to Composer 2.x where possible, since Composer 1.x remains a legacy branch.

The patched releases remove the rejected token value from Composer’s error output. They also relax the validation logic so Composer does not fail on the new GitHub token format.

Why GitHub Actions workflows are exposed

The issue becomes more serious because several widely used GitHub Actions can automatically register the workflow GITHUB_TOKEN in Composer’s global auth.json file.

Packagist specifically named shivammathur/setup-php as one example. The action has already been updated to use fixed Composer versions, but workflows may still be exposed if they pin Composer or the action to an older version.

Developers did not need to create an unusual setup to hit the bug. A standard PHP workflow could trigger it if GitHub issued a new-format token and Composer ran with an affected version.

• Projects using Composer in GitHub Actions should update Composer immediately.
• Teams should check failed GitHub Actions runs for Composer token validation errors.
• Exposed logs should be deleted where possible.
• Any token found in plaintext logs should be treated as compromised.
• Workflows that pin old Composer versions need special attention.

How long leaked tokens may stay valid

GitHub creates a unique GITHUB_TOKEN at the start of each workflow job. The token is scoped to the repository, but its impact depends on the permissions assigned to the workflow.

On GitHub-hosted runners, the GITHUB_TOKEN expires when the job ends or after a maximum of six hours. In many cases, the Composer error also fails the job, which shortens the exposure window.

Self-hosted runners create a larger concern. GitHub says a GITHUB_TOKEN on self-hosted runners can only be refreshed for up to 24 hours, which gives defenders a longer window to review logs and activity.

Environment	Token exposure window	Why it matters
GitHub-hosted runner	Until the job ends or up to 6 hours	Shorter window, but logs may still expose the token
Self-hosted runner	Up to 24 hours	Longer window for misuse after exposure
GitHub App token	Depends on token type and permissions	May carry broader access than a default workflow token

What developers should do now

The safest response is to update Composer first, then audit workflow logs. Packagist says teams should update to Composer 2.9.8, Composer 2.2.28 LTS, or Composer 1.10.28.

Teams should then search recent GitHub Actions logs for failed Composer runs, especially logs showing invalid GitHub OAuth token errors. If a token appears in plaintext, delete the log where possible and check for unusual repository activity.

Developers should also review workflow permissions. A leaked token with write access creates more risk than a token limited to read-only operations.

1. Run Composer self-update in CI environments.
2. Confirm workflows use Composer 2.9.8, 2.2.28 LTS, or 1.10.28.
3. Check whether setup actions pin Composer to an older release.
4. Review recent failed GitHub Actions logs.
5. Delete logs that contain plaintext tokens.
6. Rotate or revoke any exposed GitHub App tokens or custom credentials.
7. Review repository activity for unexpected pushes, releases, package updates, or workflow changes.
8. Limit GITHUB_TOKEN permissions to the minimum required by each workflow.

Why this bug matters for the PHP supply chain

Composer sits at the center of the PHP ecosystem. Many projects use it for dependency installation, package publishing, CI checks, and release automation.

A leaked token from a build workflow can create supply chain risk if that token has write permissions. In the wrong workflow, an attacker could potentially push code, change releases, or interfere with package automation before the token expires.

The incident also shows why access tokens should be treated as opaque strings. GitHub had already warned developers not to rely on fixed token lengths or hardcoded regex patterns, because token formats can change over time.

Packagist says its own registry was not affected

Packagist said Packagist.org was not affected because it does not use a GitHub App and does not run Composer against GitHub App installation tokens.

Private Packagist also applied the Composer fix and audited update logs. Packagist said it found no token exposure in those logs.

Even so, the main risk remains with individual PHP projects that run Composer in GitHub Actions. Any team using Composer in CI should update first and investigate logs second.

FAQ

M