We pwned X, Vercel, Cursor, and Discord through a supply-chain attack

Post by [deleted] » Fri, Dec 19, 2025, 7:53 AM UTC

tick_tock_tick wrote: post #185

llmslave2 wrote: post #22

This feels so emblematic of our current era. VC funded vibe coded AI documentation startup somehow gets big name customers who don't properly vet the security of the platform, ship a massive vulnerability that could pwn millions of users and the person who reports the vulnerability gets...$5k. If I recall last week Mintlify wrote a blog post showcasing their impressive(ly complicated) caching architecture. Pretending…

The issue is everyone loves to have everything fronted by a single domain. Most of xss is because of this basic flaw. All of this could have been avoided if discord didn't run their API docs through discord.com

Post by Maxion » Fri, Dec 19, 2025, 7:59 AM UTC

brianxq3 wrote: post #283

notnullorvoid wrote: post #255

Earlier quoted context omitted.

By they looks of it their docs are under a subdomain, and no part of the domain can be changed when setting the url this way. So it would still look a little out of place at least.

I mean, you're not wrong, but this is going to trick a non-zero number of people and that's not okay. We should expect more out of companies like Coinbase and hold them to a high standard. This is unacceptable and the amount offered in general is low. It feels like we can agree on this.

Post by socketcluster » Fri, Dec 19, 2025, 8:26 AM UTC

notnullorvoid wrote: post #196

jdsleppy wrote: post #178

Earlier quoted context omitted.

Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess? I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack. I interviewed frontend devs last year and was shocked how few knew about this stuff.

In general if a script can run, users sessions and more importantly passwords are at risk. It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify th…

Post by gatestone » Fri, Dec 19, 2025, 8:29 AM UTC

Post by vpShane » Fri, Dec 19, 2025, 8:32 AM UTC

skrebbel wrote: post #92

at this point I feel like it'd be useful for web server default configurations to include something like if extension == .svg set-header Content-Security-Policy: script-src 'none' end wouldn't that stop a browser from running scripts, even if the svg file is opened directly? having this be widespread would solve it wholesale.