Packagist Urges Immediate Composer Update After GitHub Actions Token Leak

HomeCyber Security News Packagist Urges Immediate Composer Update After GitHub Actions Token Leak By Tushar Subhra Dutta May 14, 2026 Packagist is sounding the alarm for PHP developers everywhere. A flaw in Composer, the widely used PHP dependency manager, briefly caused GitHub authentication tokens to leak into publicly visible CI logs, raising urgent concerns about credential exposure across thousands of active software projects around the world. 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. Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google. Tags cyber security cyber security news Copy URL Linkedin Twitter ReddIt Telegram Tushar Subhra Dutta Tushar is a senior cybersecurity and breach reporter. He specializes in covering cybersecurity news, trends, and emerging threats, data breaches, and malware attacks. With years of experience, he brings clarity and depth to complex security topics. Trending News Top 10 Best Data Loss Prevention Software in 2026 New Infostealer Campaign Uses GitHub Releases for Payload Hosting and Evasion 84 TanStack npm Packages Hacked in Ongoing Supply-Chain Attack Targeting CI Credentials Hackers Using Fake Claude AI Installer Pages to Trick Users Into Running Malware on Their Systems Windows DNS Client Vulnerability Enables Remote Code Execution Attacks Latest News Press Release Lyrie.ai Launches the Global Identity Standard for the AI Agent Age & Anthropic’s Cyber Verification Program Cyber Security News OpenAI Hit with Class-Action Privacy Lawsuit for Sharing ChatGPT Data with Google and Meta Cyber Security News Langflow CVE-2026-33017 Exploited to Steal AWS Keys and Deploy NATS Worker Cyber Security News Seedworm APT Abuses Signed Fortemedia and SentinelOne Binaries for DLL Sideloading Cyber Security News Windows DNS Client Vulnerability Enables Remote Code Execution Attacks