[jrflowers]

>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.

>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.

[tptacek]

So it's a serverside bug that basically creates a more-severe stored DOM corruption vulnerability? Yeah, that's not worth anything to any buyer of vulnerabilities that I know exists. Maybe you know ones that I don't know.

[jrflowers]

I can’t speak to the value of the vulnerability as I lack the universal Rolodex of Every Exploit Buyer that is apparently available (nor am I interested in debating this with somebody that admitted they didn’t know anything about the vulnerability, declared it worthless anyway, and then moved the goalposts after a core assumption about it was trivially shown to be wrong. I’m fairly certain at this point these kids could recreate the end of the movie Antitrust and there’d be a thread somewhere with tptacek posting “This isn’t that big of a deal because”).

I just saw that you asked if the article about the server-side exploit was about a server-side exploit. It is. It’s right there in the post.

[tptacek]

Can I ask which exploit buyers you are aware of? None of us know all of them! It'll be easier to discuss this with a specific buyer in mind.