Live data from Hacker News

Composer leaks contents of tokens configured as GitHub OAuth tokens

github.com

21–29 of 29 posts

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#21

I was the reporter on this one. If you have Github Actions in your organization, disable them immediately if you're unsure which version of composer your Github Actions run.

Not immediately clear to me, is this limited to ghu_xxx type OAUTH tokens? And it's only relevant for PHP projects that use composer in GHA?

It's limited to ghs_ (server to server token's), that have the new format enabled: https://github.blog/changelog/2026-04-24-notice-about-upcomi... (and actions that use the vulnerable package)

This include's the GITHUB_TOKEN that is builtin within a actions jobs.

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#22

I was the reporter on this one. If you have Github Actions in your organization, disable them immediately if you're unsure which version of composer your Github Actions run.

Nice find. The tokens being leaked in actions log was not one of the security implications I thought of when they released the feature.

How many other actions/libraries do you think are vulnerable?

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#23

GHA have always been a PITA for any serious DevOps; it's quite clear they were designed to integrate in 7 lines of code and then tell everyone who complains that they're doing it wrong. This does not surprise me.

It is a PITA, but that can be significantly improved IMHO if you just write shell script wrappers for your tasks. Not only does it make it easier to run CI locally, but it also makes it so much easier to move platforms in the future. When the GH action YAML is just invoking shell scripts, I find it quite pleasant to use

That's mostly been my approach as well... I've also started relying on Deno for a lot of general shell scripting as you can use repository modules without an install step and shebang works outside Windows (or inside with bash).

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#24

Earlier quoted context omitted.

You've perfectly described how microsoft operates and how github actions is apparently based on AzureDevOps pipelines.

No. GHA has always been trash before MS got to it. A lot of GHA influenced ADO.

IMO the .yaml config for ADO was an improvement... though it carries similar issues to GHA. I mostly use it as a script runner.

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#25
post #4

The title suggests it is a Github issue but really it is https://github.com/composer/composer no? I would edit the title for clarity.

Yes, it's a Composer issue (which is a PHP dependencies manager) with the new format of GITHUB_TOKEN. It's not an issue in GHA itself, this time. But if you are a composer user in GH, you should definitely be warned (and worried).

You're using PHP... you aren't worried about anything... ;-)

/kidding

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#26

GHA have always been a PITA for any serious DevOps; it's quite clear they were designed to integrate in 7 lines of code and then tell everyone who complains that they're doing it wrong. This does not surprise me.

It is a PITA, but that can be significantly improved IMHO if you just write shell script wrappers for your tasks. Not only does it make it easier to run CI locally, but it also makes it so much easier to move platforms in the future. When the GH action YAML is just invoking shell scripts, I find it quite pleasant to use

Yeah this what I've always done too - already had to migrate from GitHub to GitLab once and a test.sh script saved me a lot of time.

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#28
This is also a good reminder to scan CI logs, not just source code.

Shameless plug: I work on Kingfisher, an Apache 2.0 OSS secret scanner and validator written in Rust, that can also map blast radius and revoke many creds:

https://github.com/mongodb/kingfisher>

It can scan repos, history, and artifacts and validate many findings against provider APIs, as well as revoke many exposed tokens directly from the CLI. Also generates a blast-radius/access-map view so you can see what a leaked credential could reach.

Install:

  brew install kingfisher
  # or
  uv tool install kingfisher-bin
Scan a local path:

  kingfisher scan /path/to/scan --access-map --view-report
Or scan a GitHub/GitLab repo directly:

  kingfisher scan https://github.com/path/to/repo.git --access-map --view-report

Re: Composer leaks contents of tokens configured as GitHub OAuth tokens

#29

I was the reporter on this one. If you have Github Actions in your organization, disable them immediately if you're unsure which version of composer your Github Actions run.

Nice find. The tokens being leaked in actions log was not one of the security implications I thought of when they released the feature. How many other actions/libraries do you think are vulnerable?

I don't have an exact count, but during my analysis, I found that ~40 of the top 100 starred repos in the PHP ecosystem were impacted. Primarily by jobs that run `on: schedule` or by a maintainer with an `on: push`
Post reply on HN