Imagine my surprise that the company that posts "Collaboration sucks" and endorses a YOLO approach to decision making then has a security breach based on misconceptions of a GitHub action that was caught by security tools and could have been proven out via collaboration or a metered approach to decision making.
I didn’t know what Posthog was before this event but the website is so unusable on Safari on MacOS or iOS for me i’m surprised I stuck through to discover the product.
Curious, I pressed "X" on the blog post. It went away, leaving me with the fake desktop view at "posthog.com". Ok, fine. How do I get back?
I pressed the back button on my browser. The URL updated to be the blog post's URL. A good start. But the UI did not change, leaving me at the desktop view.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
a) ok whippersnapper, b) new community members have the most energy. I’m not actually sure there’s much need for volunteer mods on HN tbh, but the best volunteers are often the newest folks around.
Without JavaScript, all I get is a background image and a top "navigation bar" where the only thing that's actually operable at all is a signup link. Which then goes to a completely blank page.
I still don't know what Posthog is, but I'm now committed to never using it if I can at all help it.
We are taking about a company’s JavaScript libraries (the npm attack). Knowing that, I’m pretty sure that people who browse without JavaScript enabled aren’t their target market.
I’m apparently also not in their market so, the best I ca say from the website is (hand wavy) “website analytics”.
Other than the silly design, the website's cookie banner is actively malicious. It proclaims to be legally required and directly blames the President of the European Commission. If Posthog is being truthful about its cookie usage, the cookie banner is in fact not legally required. Consent banners are only required if you're trying to do individual user tracking or collecting personally identifying data; technical cookies like session storage do not require a banner. That they then chose to include a cookie banner anyways, with explicit blame, is an act of propaganda clearly intended to cause unnecessary consent banner fatigue and weaken support for the GDPR.
I don't have a cookie banner on _my_ website for exactly this reason, but I have to admit some people have asked my if it isn't suspicious that I don't. Perhaps that's what they're trying to avoid here? (that would be the positive reading)
I think that's what Posthog might be trying but as per the above there may be a fine line between funny and annoying and/or between useful and useless.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
Long story short: they messed up the assign-reviewers.yml workflow, allowing external contributors to merge PRs without proper reviews. From this point on, you're fully open to all kinds of bad stuff.
> 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.
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.
“ 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.”
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
This is a great writeup, kudos for the PostHog folks.
Curious: would you be able to make your original exploitable workflow available for analysis? You note that a static analysis tool flagged it as potentially exploitable, but that the finding was suppressed under the belief that it was a false positive. I'm curious if there are additional indicators the tool could have detected that would have reduced the likelihood of premature suppression here.
(I tried to search for it, but couldn't immediately find it. I might be looking in the wrong repository, though.)
I pressed the back button on my browser. The URL updated to be the blog post's URL. A good start. But the UI did not change, leaving me at the desktop view.
Many moments like these if you use Posthog
https://news.ycombinator.com/newsguidelines.html
I still don't know what Posthog is, but I'm now committed to never using it if I can at all help it.
I’m apparently also not in their market so, the best I ca say from the website is (hand wavy) “website analytics”.
or maybe I just missed your sarcasm
https://news.ycombinator.com/newsguidelines.html
Pre-coffee, apparently.
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.
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/
“ 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.”
https://news.ycombinator.com/newsguidelines.html
Curious: would you be able to make your original exploitable workflow available for analysis? You note that a static analysis tool flagged it as potentially exploitable, but that the finding was suppressed under the belief that it was a false positive. I'm curious if there are additional indicators the tool could have detected that would have reduced the likelihood of premature suppression here.
(I tried to search for it, but couldn't immediately find it. I might be looking in the wrong repository, though.)