Skip to content

Back to the catalog

Socket: Packagist Urges Immediate Composer Update After GitHub Actions Token Leak
socket.devadvisory

Socket: Packagist Urges Immediate Composer Update After GitHub Actions Token Leak

Packagist disclosed that Composer versions prior to 2.9.8, 2.2.28 LTS, and 1.10.28 could leak full GitHub Actions GITHUB_TOKEN and GitHub App installation token values into CI logs when a token failed Composer's outdated validation regex, triggered by GitHub's since-rolled-back rollout of a new hyphenated token format. Common setups like shivammathur/setup-php that auto-register GITHUB_TOKEN into Composer's global auth.json are called out as at risk, and teams are urged to update Composer immediately and audit Actions logs for exposed credentials.

TL;DR A Composer validation bug leaked GitHub Actions tokens into CI logs during GitHub's token-format rollout; Packagist urges immediate upgrade to Composer 2.9.8/2.2.28/1.10.28.
Open original ↗
Document

What it is

Composer 2.9.8, 2.2.28 LTS, and 1.10.28 fix a token-leak flaw where Composer printed full GITHUB_TOKEN or GitHub App installation token values to stderr when a token failed its validation regex. The trigger was GitHub's new installation-token format (ghs_APPID_JWT, announced April 24, rollout from April 27) which includes a hyphen the old regex rejected. GitHub has since rolled the format change back (per Packagist co-founder Nils Adermann, update dated May 13, 2026).

Preconditions / Affected

Composer running inside GitHub Actions where a workflow or setup action (e.g. shivammathur/setup-php) registers GITHUB_TOKEN into Composer's global auth.json, and the job received one of the new-format tokens. Packagist.org is not affected — the public registry uses no GitHub App and never runs Composer against installation tokens. Private Packagist already applied the fix and audited its update logs, finding no exposure.

What to do

  • Update to Composer 2.9.8 or 2.2.28 LTS immediately. 1.10.28 carries the fix for legacy users, but Packagist recommends moving to 2.x where possible.
  • Review recent Actions logs for failed Composer runs that may have printed tokens; delete affected log contents where possible.
  • Check for unexpected activity tied to any exposed credentials.

The fix removes the rejected token value from the error message and relaxes the validation character set to accept the new format.

Caveats

  • The rollback reduces immediate risk of new leaks but does not remove the need to update — a new rollout of the format is expected within days, and GitHub is also improving secrets masking.
  • Exposure windows vary. GitHub-hosted runner tokens usually expire at job end or after at most 6 hours. On self-hosted runners, a leaked GITHUB_TOKEN may stay valid up to 24 hours after issuance. Tokens from GitHub Apps may carry different scopes and should be reviewed against the permissions requested.

The broader lesson the page draws: don't parse or validate access tokens against assumptions about length or character set — GitHub's own guidance is to treat tokens as opaque strings and avoid hardcoded patterns entirely.

Technologies named here

Techniques named here

  • Credential/token exposure via error logging
  • Validation against hardcoded token format assumptions

Related in DevSecOps