@zachleat@fediverse.zachleat.com
Post #2739570
2026-05-12 00:05 UTC
Replies (5)
-
@zachleat@fediverse.zachleat.com 2026-05-12 14:17
A follow up here on action items (assuming you’re already using trusted publishers OIDC to scope releases to a single GitHub Action workflow): 1. Look for any `pull_request_target` GitHub Actions workflows! (this allows external forks/code to run your actions with write access ☠️☠️☠️☠️☠️) 2. Look for use of `cache` in your GitHub Actions release workflow (cache was poisoned/compromised by `pull_request_target` trigger) Learn more about `pull_request_target`: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
-
@jeromechoo@masto.ai 2026-05-12 00:14
@zachleat@fediverse.zachleat.com I'm not sure I would agree. This entire article reads like they dumped all their logs to Claude Code and asked it to generate a post mortem.
-
@fox@front-end.social 2026-05-12 00:26
@zachleat@fediverse.zachleat.com oh wow, that’s incredibly thorough! 👏🏻
-
@jokeyrhyme@aus.social 2026-05-12 00:29
@zachleat@fediverse.zachleat.com npm needs to make prepare/postinstall hooks opt-in and allow-listed instead of on by default for the whole universe and a declarative/sandboxed solution for packages that have to download and compile as an escape hatch (something like flathub's manifest where the framework does the downloading for you and rejects anything that doesn't match the expected hashes) absurd that even crates.io has the same problem and no solution in sight :S
-
@jgarber@social.lol 2026-05-12 01:27
@zachleat@fediverse.zachleat.com pull_request_target strikes again!