Packagist Urges Immediate Composer Update After GitHub Actions Token Leak

Packagist is urgently warning PHP projects to update Composer after a GitHub token format change caused some GitHub Actions tokens to be exposed in CI logs.

Composer 2.9.8, 2.2.28 LTS, and 1.10.28 fix a vulnerability where Composer could print the full contents of GitHub Actions-issued GITHUB_TOKEN values or GitHub App installation tokens to stderr when the token failed Composer’s validation check. The issue was triggered by GitHub’s rollout of a new token format that includes a hyphen, which Composer’s previous validation regex did not allow.

GitHub announced the token format change on April 24, saying newly issued GitHub App installation tokens would move to a longer, variable-length format using ghs_APPID_JWT, with rollout beginning April 27 and continuing over the following weeks. GitHub specifically advised developers to treat tokens as opaque strings and avoid validating them against hardcoded patterns.

The concern is that if a PHP project runs Composer in GitHub Actions and the workflow uses one of the new token formats, Composer may reject the token and print it into the Actions log. Packagist says the issue can occur through common GitHub Actions setups, including workflows where actions such as shivammathur/setup-php automatically register GITHUB_TOKEN in Composer’s global auth.json.

GitHub has since rolled back the token format change, according to Packagist co-founder Nils Adermann. That reduces the immediate risk of new leaks from this specific rollout, but it does not remove the need to update Composer.

The exposure window is limited in many cases, but teams should still treat this as urgent. Packagist notes that GitHub-hosted runner tokens usually expire when the job ends, or after a maximum of 6 hours. For self-hosted runners, a leaked GITHUB_TOKEN may remain valid for up to 24 hours after issuance. Tokens created through GitHub Apps may have different scopes and should be reviewed based on the permissions requested.

Packagist.org itself is not affected, as the public registry does not use a GitHub App and does not run Composer against GitHub App installation tokens. Private Packagist has already applied the Composer fix and audited update logs, with no token exposure found. The main risk is for projects running Composer in GitHub Actions, especially where workflows or setup actions register GITHUB_TOKEN into Composer authentication.

Update Composer Immediately#

Teams running Composer in GitHub Actions should update to Composer 2.9.8 or 2.2.28 LTS immediately. Composer 1.10.28 also includes the fix for legacy users, though Packagist recommends users upgrade to Composer 2.x where possible.

Packagist has also updated its guidance after GitHub rolled back the token format change:

UPDATE May 13, 2026 2:30 PM UTC: GitHub has rolled back their change to GitHub Actions tokens. It is no longer necessary to immediately disable GitHub Actions. We now have a few days to get the entire PHP ecosystem updated to safe Composer versions, before a new rollout of the new token format is attempted. GitHub is also looking into improving their secrets masking. Ideally a new rollout will not lead to any leaked credentials, even if they are accidentally exposed in logs.

Teams should still review recent Actions logs for failed Composer runs that may have printed tokens, delete affected log contents where possible, and check for unexpected activity tied to any exposed credentials.

The fix removes the rejected token value from Composer’s error message and relaxes the validation character set to accept the new GitHub token format. More broadly, this incident is a reminder that access tokens should not be parsed or validated against assumptions about length or character set, especially when platforms are actively changing token formats. GitHub’s own guidance is to avoid hardcoded token patterns entirely.