So it wasn't phishing attack? Wonder how those bot access tokens got stolen.

jameskilton 2 hours ago | parent | next [-]

> The PR was opened, the workflow run, and the PR closed within the space of 1 minute (screenshots include timestamps in UTC+2, the author's timezone):

It's an unfortunately common problem with GitHub Actions, it's easy to set things up to where any PR that's opened against your repo runs the workflows as defined in the branch. So you fork, make a malicious change to an existing workflow, and open a PR, and your code gets executed automatically.

Frankly at this point PRs from non-contributors should never run workflows, but I don't think that's the default yet.

	▲	LtWorf an hour ago \| parent [-]
		Problem is that you might want to have the tests run before even looking at it. I think the mistake was to put secrets in there and allow publishing directly from github's CI. Hilariously the people at pypi advise to use trusted publishers (publishing on pypi from github rather than local upload) as a way to avoid this issue. https://blog.pypi.org/posts/2025-11-26-pypi-and-shai-hulud/

▲

neoecos 2 hours ago | parent | prev | next [-]

They do explain all the details how the got the tokens stolen.

▲

animex 2 hours ago | parent | prev | next [-]

It explains in the article under "Why did it happen?".

▲

moi2388 2 hours ago | parent | prev [-]

They explain how.

“ At 5:40PM on November 18th, now-deleted user brwjbowkevj opened a pull request against our posthog repository, including this commit. This PR changed the code of a script executed by a workflow we were running against external contributions, modifying it to send the secrets available during that script's execution to a webhook controlled by the attacker. These secrets included the Github Personal Access Token of one of our bots, which had broad repo write permissions across our organization.”

▲

AndrewDucker 2 hours ago | parent | next [-]

Which shows the danger of keeping build scripts in your repos and letting users update them themselves.

	▲	larusso 19 minutes ago \| parent [-]
		Paired with a long lived GitHub access token that had more access than needed for this operation. GitHub Actions has some features for short lived tokens that are not stored in static action secrets. I’m not quite sure why a bot user was actually needed here. Then there is the simple fact that lots of developers over provision their environments. Every sessions hosts hundreds of env variables for all kinds of things. From docker to GitHub tokens etc. we started to oidc all the things in Jenkins and GitHub actions to guard secrets to be accessible only by certain repos and branches inside them. But the more you shut that down the more flexibility you loose. Or you need even more automation to help with access management.

▲

mrdosija 2 hours ago | parent | prev [-]

Oh. I mist be blind. Well, that's a warning for all.