Maybe? I don't know enough about the vulnerability. Is it serverside? Then it isn't worth very much.
>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.
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.
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.
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.
A vulnerability like that (or even a slightly worse XSS that allowed serving js instead of only svg) could've let them register service workers to all visiting users giving future XSS ability at any time, even after the original RCE and XSS were patched.