Packagist: Urgent Composer Update After GitHub Token Leak

Packagist has issued an urgent alert to PHP developers. A critical flaw within Composer, the widely used PHP dependency manager, briefly exposed GitHub authentication tokens in publicly visible CI logs. This incident raises immediate concerns about credential exposure across thousands of active software projects worldwide.

The problem started when GitHub quietly began rolling out a new token format for its GitHub Actions service in late April 2026. The updated format included a hyphen in the token string, something that Composer’s internal validation code was never built to handle.

When Composer encountered one of these new-style tokens, it rejected the token outright and printed the full token value directly into the Actions log as part of a standard error message, where anyone with log access could potentially read it without any special technical effort.

Researchers at Socket.dev were among those who flagged the full scope and seriousness of this issue for the wider developer community. The finding made clear that this was not a minor edge case or a theoretical vulnerability, but a real-world risk capable of affecting any PHP project running Composer inside a GitHub Actions workflow.

The exposure stems from how many popular setup workflows operate in practice every day. When developers use a common GitHub Actions helper like shivammathur/setup-php, it automatically registers the GITHUB_TOKEN into Composer’s global authentication configuration.

If that token happened to match the new format during the rollout window, Composer would reject it and expose the full credential in the log without any warning or visible signal to the developer who originally set up that workflow.

Packagist Urges Immediate Composer Update

GitHub has since rolled back the new token format, which reduces the immediate chance of fresh leaks happening right now. However, Packagist co-founder Nils Adermann made it clear that the rollback does not undo what has already happened, and teams still need to update Composer and audit their recent logs thoroughly for any signs of credential exposure before GitHub attempts another rollout of the changed format in the coming weeks.

Three versions of Composer now contain the official patch for this issue. Developers running modern setups should update to Composer 2.9.8 or the long-term support release 2.2.28 LTS without delay.

Legacy users still on older branches can update to Composer 1.10.28, which also includes the same fix, though Packagist recommends moving to the Composer 2.x line wherever possible for stronger long-term security coverage.

The fix works by removing the rejected token value from Composer’s error output entirely and also relaxes the validation logic so that the tool no longer checks tokens against a hardcoded character pattern.

This makes Composer far more resilient to future token format changes from any platform. The broader takeaway is clear: tools should treat access tokens as opaque strings and never make assumptions about their length, structure, or character set, especially when platforms are actively evolving those formats.

What Teams Should Do Right Now

Packagist.org itself was not affected by this issue, since the public registry does not use GitHub App installation tokens or run Composer against them directly. Private Packagist has also applied the fix and fully audited its own update logs, finding no token exposure in any recorded activity.

But the risk remains real for any project running Composer inside GitHub Actions, especially where setup actions automatically register GITHUB_TOKEN into Composer’s authentication layer.

Teams should start by updating Composer to one of the three patched versions immediately. They should then go back through recent GitHub Actions logs for any failed Composer runs that may have accidentally printed a token value to the output. Where possible, those log entries should be deleted to prevent further exposure.

GitHub-hosted runner tokens typically expire when the job ends or after six hours, but tokens on self-hosted runners can stay valid for up to 24 hours, and any token believed to have been exposed should be treated as compromised and rotated straight away.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.