Packagist Composer Update Fixes GitHub Actions Token Leak

Key Takeaways

• A critical vulnerability in Composer, the PHP dependency manager, led to the exposure of GitHub authentication tokens.
• The flaw occurred when Composer encountered a new GitHub token format, causing it to print the full token into publicly visible CI logs.
• Thousands of PHP projects using GitHub Actions were potentially affected, risking credential compromise.
• GitHub has temporarily rolled back the new token format, but developers must still update Composer and audit logs for past exposures.

Composer Flaw Exposed GitHub Tokens in CI Logs

Packagist has issued an urgent advisory to the PHP development community regarding a critical vulnerability within Composer, the widely adopted PHP dependency manager. This flaw inadvertently exposed GitHub authentication tokens in publicly accessible continuous integration (CI) logs, raising significant concerns about credential compromise across a multitude of active software projects globally.

The issue originated in late April 2026, when GitHub began a quiet rollout of an updated token format for its GitHub Actions service. This new format incorporated a hyphen within the token string, a character Composer’s internal validation logic was not designed to process.

Consequently, when Composer encountered one of these newly formatted tokens, it failed to validate it. Instead of handling the rejection discreetly, the tool printed the entire token value directly into the Actions log as part of a standard error message. This made the sensitive credential visible to anyone with access to the logs, requiring no advanced technical expertise to retrieve.

Researchers at Socket.dev were instrumental in highlighting the extensive scope and severity of this problem to the broader developer community. Their findings underscored that this was not an isolated incident or a theoretical risk, but a tangible threat capable of impacting any PHP project that integrates Composer within a GitHub Actions workflow.

The exposure was exacerbated by common operational practices. Many popular GitHub Actions setup workflows, such as those utilizing shivammathur/setup-php, automatically register the GITHUB_TOKEN into Composer’s global authentication configuration. If such a token matched the new, unsupported format during the rollout period, Composer’s rejection mechanism would inadvertently leak the full credential into the log without any explicit warning or visible indication to the developer managing the workflow.

Immediate Action Required: Update Composer

While GitHub has since reverted the new token format, thereby mitigating the immediate potential for fresh leaks, Packagist co-founder Nils Adermann emphasized that this rollback does not nullify previous exposures. Development teams are still strongly urged to update Composer and meticulously review their recent CI logs for any evidence of credential compromise before GitHub reattempts the rollout of the revised token format in the coming weeks.

Three distinct Composer versions now incorporate the official patch addressing this vulnerability. Developers operating modern environments should prioritize updating to Composer 2.9.8 or the long-term support release, Composer 2.2.28 LTS, without delay. For those still utilizing older branches, an update to Composer 1.10.28 is available, which also includes the fix. However, Packagist recommends transitioning to the Composer 2.x line whenever feasible for enhanced long-term security.

The implemented fix removes the rejected token value entirely from Composer’s error output and also relaxes the validation logic. This adjustment means the tool no longer relies on a hardcoded character pattern for token checks, significantly improving Composer’s resilience to future token format modifications from any platform. The overarching lesson is clear: access tokens should be treated as opaque strings, and assumptions about their length, structure, or character set should be avoided, especially as platforms continuously evolve these formats.

What You Should Do

• Update Composer Immediately: Ensure all installations are updated to Composer 2.9.8, 2.2.28 LTS, or 1.10.28.
• Audit GitHub Actions Logs: Review recent GitHub Actions logs for any failed Composer runs that might have inadvertently printed a token value.
• Delete Exposed Log Entries: Where token exposure is identified, delete the relevant log entries to prevent further access.
• Rotate Compromised Tokens: Treat any token suspected of exposure as compromised and rotate it immediately. GitHub-hosted runner tokens typically expire rapidly, but self-hosted runner tokens can remain valid for up to 24 hours.

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.