The sharpest software security story of the week is not a remote code execution bug or a nation-state breach. It is a reminder that modern supply chains are full of hidden assumptions, and one of them just cracked in public.

On May 13, the Composer team shipped versions 2.9.8 and 2.2.28 to fix a vulnerability that could leak GitHub Actions credentials straight into workflow logs. The trigger was almost absurdly small. GitHub began rolling out a new structured format for GitHub App installation tokens. Composer still validated tokens against an older character set assumption, rejected the new format, then echoed the full rejected token back in an error message on stderr. In CI, stderr is not private. It becomes log history.

That chain matters because it is exactly how a lot of real failures happen now. Nobody needed a zero-day exploit primitive. Nobody needed to break cryptography. A token format changed, an old validation rule stayed in place, and a developer tool helpfully printed the secret it did not like.

The Vulnerability Was More Operational Than Exotic

Packagist's advisory is blunt: if you run Composer in GitHub Actions, treat this as urgent. The bug, now tracked as CVE-2026-45793 and GHSA-f9f8-rm49-7jv2, affected workflows that fed GitHub Actions-issued GITHUB_TOKEN values or GitHub App installation tokens into Composer authentication. Once Composer hit the validation path, the secret could land in logs in plaintext.

The mechanics are worth understanding because they reveal the real lesson. GitHub's newer installation token shape includes a hyphen as part of a structured format. Composer's validator did not allow that character. Instead of failing safely, it constructed an exception message containing the complete token. Symfony Console rendered that message to stderr. GitHub Actions logging then preserved it. Even built-in masking could miss the value once formatting, framing, or escape sequences changed the exact string layout in the output.

That is not a one-off edge case. It is the kind of cross-tool failure that shows up when software supply chains become long enough that every component assumes somebody else handled the dangerous part correctly.

Why Self-Hosted Runners Deserve Extra Attention

The obvious instinct is to shrug because GitHub Actions tokens are short-lived. That is only partly reassuring.

GitHub's own documentation says the workflow GITHUB_TOKEN on GitHub-hosted runners expires when the job finishes or after a maximum of six hours. On self-hosted runners, the token is still an installation access token and can be refreshed for up to 24 hours. Packagist also notes that installation tokens created through GitHub Apps are valid for up to one hour by default and may carry broader permissions than the workflow's own declared permissions block.

That means the exposure window is not imaginary, especially for shops that centralize automation on self-hosted infrastructure or reuse GitHub App tokens across repository operations. A leaked token in a failed job log is not merely embarrassing telemetry. For some teams it is a live credential with enough time and scope to matter.

This Is What Brittle Automation Looks Like

The deeper story is not about PHP. It is about the fragility of automated trust chains.

Developer tooling has grown comfortable assuming that validation failures are harmless and that logs are a safe place for detailed diagnostics. That mindset does not survive contact with CI, where logs are durable artifacts, frequently shared across teams, exported to third-party systems, and sometimes copied into tickets, chat threads, or support bundles. The moment a secret touches that path, the incident is no longer local.

Composer's fix was sensible: stop including the rejected token value in the exception message and relax validation to match GitHub's current token format. But the bigger takeaway is that secure tooling needs to fail closed in every layer. Validation code, console rendering, log capture, and secret masking all have to be designed with the assumption that one upstream format change can turn normal error handling into disclosure.

What Teams Should Actually Do

If your CI uses Composer anywhere in GitHub Actions, update it now. That is the first move, not the last one.

Then review whether any jobs may have printed affected tokens before the patched version landed. Treat self-hosted runner leaks as potentially valid for up to 24 hours, GitHub-hosted leaks as potentially valid for up to six hours, and rotate any GitHub App installation tokens that might have appeared in logs. If your workflows pin Composer explicitly, do not assume upstream actions already saved you. Check the pinned version. Packagist specifically called out shivammathur/setup-php as already updated unless you forced an older Composer release yourself.

There is also a governance lesson here. Teams should be testing their automation stack against malformed or evolving credentials the same way they test application code against weird inputs. Secret handling is not just a vault problem. It is an error-reporting problem, a logging problem, and a dependency-maintenance problem.

The Takeaway

Composer did not get hacked in the cinematic sense. It inherited a new token format, rejected it using an old rule, and turned that mismatch into a secret leak. That is exactly why modern software security is increasingly about interfaces and failure modes rather than dramatic exploits.

The teams that come out ahead are the ones that treat CI tooling as production attack surface. Your package manager, your workflow runner, your auth helpers, and your logs are all part of the same security boundary now. A single misplaced error string is enough to prove it.

Sources: Packagist's May 13, 2026 advisory, GitHub Docs on GITHUB_TOKEN lifetime and behavior, and Composer's release notes for the fixed versions.