3 ms·

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

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.

semi-extrinsic 5mo ago
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?
- jacobrussell 5mo ago
  That's my understanding. This seems to only effect PHP projects that use Composer in GitHub actions. Examples being usage of shivammathur/setup-php and or php-actions/composer.
- securesaml 5mo ago
  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-upcoming-new-format-for-github-app-installation-tokens/ 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.
ammar2 5mo ago
Could you elaborate on this bit on why Github's secret masking doesn't work here: > GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log. What does this log rendering look like such that the token from that code snippet becomes interleaved enough to not be a substring match? I'm not familiar with composer/Symfony but I would expect something like: Line 34: Foo bar Line 34: <red>Foo bar</red>
- jacobrussell 5mo ago
  From what I can tell Symfony wraps these errors in a styled error block so it messes with GitHub's masking. For example, newlines breaking up the token are apparently enough to trick the masker since it's not a substring anymore. For your example: Line 34: <red>ghs_fdsafdsarewqfdsa...</red> Is probably long enough in most cases to break to a new line. Also, those blocks get "interleaved" like this: <red>ghs_fdsafdsarewqfdsafdsa</red> <red>fdsardsardsafdsafs......</red> So there are now </red>'s within the token, also breaking the substring matching. This is kind of eye-opening for me -- I have never thought about how styled output like this could cause logging leakages.
  - ammar2 5mo ago
    Aah, the newlines were the thing I was missing. That makes sense then.
  - deleted 5mo ago
    [deleted]
securesaml 5mo ago
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?
- damienwebdev 5mo ago
  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`

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.

semi-extrinsic 5mo ago

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?

jacobrussell 5mo ago
That's my understanding. This seems to only effect PHP projects that use Composer in GitHub actions. Examples being usage of shivammathur/setup-php and or php-actions/composer.
securesaml 5mo ago
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-upcoming-new-format-for-github-app-installation-tokens/ 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.

ammar2 5mo ago

Could you elaborate on this bit on why Github's secret masking doesn't work here: > GitHub Actions' built-in secret masker matches registered values as exact substrings. When the exception message is rendered by Symfony Console it may wrap, embed in In BaseIO.php line N: framing, or interleave with ANSI control sequences. So the masker does not redact, and the plaintext token reaches the log. What does this log rendering look like such that the token from that code snippet becomes interleaved enough to not be a substring match? I'm not familiar with composer/Symfony but I would expect something like: Line 34: Foo bar Line 34: <red>Foo bar</red>

jacobrussell 5mo ago
From what I can tell Symfony wraps these errors in a styled error block so it messes with GitHub's masking. For example, newlines breaking up the token are apparently enough to trick the masker since it's not a substring anymore. For your example: Line 34: <red>ghs_fdsafdsarewqfdsa...</red> Is probably long enough in most cases to break to a new line. Also, those blocks get "interleaved" like this: <red>ghs_fdsafdsarewqfdsafdsa</red> <red>fdsardsardsafdsafs......</red> So there are now </red>'s within the token, also breaking the substring matching. This is kind of eye-opening for me -- I have never thought about how styled output like this could cause logging leakages.
- ammar2 5mo ago
  Aah, the newlines were the thing I was missing. That makes sense then.
- deleted 5mo ago
  [deleted]

securesaml 5mo ago

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?

damienwebdev 5mo ago
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`