| ▲ | Post-mortem of Shai-Hulud attack on November 24th, 2025(posthog.com) |
| 52 points by makepanic 3 days ago | 38 comments |
| |
|
| ▲ | healsdata 27 minutes ago | parent | next [-] |
| 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. |
|
| ▲ | erikpukinskis 9 minutes ago | parent | prev | next [-] |
| Does anyone have experience putting their production branches in a separate repo from their development branches? GitHub makes it very easy to make a pull request from one repo into another. This would seem to have a lot of benefits: you can have different branch protection rules in the different repos, different secrets. Would it be a pain in the ass? For an open source project you could have an open contribution model, but then only allow core maintainers to have write access in the production repo to trigger a release. Or maybe even make it completely private. |
|
| ▲ | hhh 2 hours ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | flunhat 2 hours ago | parent | next [-] | | 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. Many moments like these if you use Posthog | |
| ▲ | amitav1 an hour ago | parent | prev | next [-] | | 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. https://news.ycombinator.com/newsguidelines.html | | |
| ▲ | loeg an hour ago | parent [-] | | In this case, I think GP is suggesting this rises above the level of a tangential annoyance. | | |
| ▲ | metabagel 33 minutes ago | parent | next [-] | | It’s tangential, because it’s not about the information posted. | |
| ▲ | MonkeyClub 34 minutes ago | parent | prev [-] | | Also HN doesn't need 11 month old volunteer mods. | | |
| ▲ | ksenzee 27 minutes ago | parent [-] | | 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. |
|
|
| |
| ▲ | khannn an hour ago | parent | prev | next [-] | | The site caused my browser to freeze and it reminded me of the 56k modem days. | |
| ▲ | zahlman 2 hours ago | parent | prev [-] | | 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. | | |
| ▲ | mbreese 30 minutes ago | parent [-] | | 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”. |
|
|
|
| ▲ | flunhat 2 hours ago | parent | prev | next [-] |
| Posthog's website design feels like a joke that went a bit too far |
| |
| ▲ | anonymous908213 2 hours ago | parent | next [-] | | 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. | | |
| ▲ | vanschelven an hour ago | parent | next [-] | | 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) | | |
| ▲ | lotyrin 40 minutes ago | parent [-] | | Maybe you need a "why I don't have a banner" banner. | | |
| ▲ | vanschelven 35 minutes ago | parent [-] | | 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. or maybe I just missed your sarcasm |
|
| |
| ▲ | dkdcio an hour ago | parent | prev [-] | | I agree it’s stupid but wouldn’t ascribe intent without more information |
| |
| ▲ | jwpapi an hour ago | parent | prev | next [-] | | They made a post how they reinvented ux | |
| ▲ | amitav1 an hour ago | parent | prev [-] | | 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. https://news.ycombinator.com/newsguidelines.html | | |
|
|
| ▲ | themly an hour ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | vanschelven an hour ago | parent [-] | | more so in case you actually do the "secrets on github with the right to do meaningful things" |
|
|
| ▲ | dangoodmanUT 6 minutes ago | parent | prev | next [-] |
| The slight side scrolling on mobile, and overriding the link alt-click behavior… why |
|
| ▲ | __d 20 minutes ago | parent | prev | next [-] |
| So I saw the headline and for a moment I was very confused: aren’t sand worms fictional? Pre-coffee, apparently. |
|
| ▲ | mrdosija 2 hours ago | parent | prev | next [-] |
| 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 an hour ago | parent | next [-] | | Which shows the danger of keeping build scripts in your repos and letting users update them themselves. | |
| ▲ | mrdosija 2 hours ago | parent | prev [-] | | Oh. I mist be blind.
Well, that's a warning for all. |
|
|
|
| ▲ | KomoD 2 hours ago | parent | prev | next [-] |
| Wow, I hate this website to be honest. So much of the space is taken up by all these "bars" on my already small screen. |
| |
|
| ▲ | woodruffw 2 hours ago | parent | prev [-] |
| 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.) |
| |
