[foodevl]

> This is no good. Let me just try reverting to a version from a month ago. Nothing. Three months ago? Nothing. Still failing. A year ago? Zilch.

Reverting your own code, but still using a broken PostHog update from that same day? For me, the lesson is to make sure that I can revert everything, including dependencies.

[roywiggins]

It seems that PostHog just always loads the latest version of this piece of itself:

https://github.com/PostHog/posthog/issues/24471#issuecomment...

Though you can opt to bundle it yourself:

https://github.com/PostHog/posthog/issues/24471#issuecomment...

[phkahler]

>> It seems that PostHog just always loads the latest version of this piece of itself:

Now there's a supply chain attack vector...

[philsnow]

Years ago, IT at the company I was working at force-pushed a browser extension that did this same trick, but the extension vendor in question didn't even bother loading over https.

Edit: the extension's manifest gave it nearly every permission, on every web site, including internal ones

[slashdave]

> I definitely want to figure out in detail what happened here so I can add a test to prevent a similar change in future!

Whoa! Good idea!

Could have been worse. At least the change didn't expose a hidden exploit.

[ricardobeat]

Ouch. That just adds insult to injury.

[amsterdorn]

This is the key lesson. Your own deploys mean nothing if you link to another CDN for parts of your application.

You handled it well OP, the silver lining of incidents like this is the grab bag of valuable takeaways!