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 that without causing a page load).
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.
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
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.
What 'arcwhite said (sorry, I got dragged into a call).
1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.
2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.
3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).
4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.
There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.
Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.
For a reflected XSS? Tell me who is paying that much for such a relatively common bug...
To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc
No real way to use this to compromise a large amount of users without more complex means
Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.
It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.
Yes, but this is not a particularly high access level bug.
Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)
I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss
Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.
In addition this is widespread. It's golden for any attacker.
Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.
I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).
If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).
Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.
Besides XSS, phishing has its own opportunity.
Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.
Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).
Still, purely with executing things under the user sessions there are interesting things to do.
Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!
There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.
What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.
The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.
This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.
All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.
Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.
With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.
Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?
I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.
The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.
The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.
No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI).
But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.
IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.
I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?
You definitely don't understand PDFs, let alone SVGs.
PDFs can also contain scripts. Many applications have had issues rendering PDFs.
Don't get me wrong, the folks creating the SVG standard should've used their heads. This is like the 5th time (that I am aware of) this type of issue has happened, (and at least 3 of them were Adobe). Allowing executable code in an image/page format shouldn't be a thing.
SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.
More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Does it need to be as complicated as a new format? Or would it be enough to not allow any scripting in the provided SVGs (or stripping it out). I can't imagine there are that many SVGs out there which take advantage of the feature.
If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.
Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.
There is artistically no equivalent to Flash ever since it died. Nothing else has allowed someone with artistic skills but no programming skills to create animations and games to the same degree and with the same ease.
I'd say Roblox is absolutely filling that market need. And as mentioned elsewhere, the "animations and games" demographic has moved on in the intervening decades to social media, and tools like CapCut make creating online content easier than it ever has been.
Honestly I think a lot of the Flash mania is just middle aged nerds fondly remembering their youth. The actual tool was a flash in the pan, and part of a much more complicated history of online content production. And the world is doing just fine without it.
Sure, but that's because the media and forums change, not so much a point about tool capability. The equivalent of teenaged geeks hacking on flash games today is influencer wannabes editting trends in CapCut. If anything content production is far more accessible now than in the 90's.
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.
Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405
In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.
Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.
True, I just considered that once you handle a PDF with so much care like if it was poisoned, it's perhaps better to send this poison to someone else to handle.
It's wild how often we rediscover that executing untrusted code leads to decades of whack-a-mole security. Excel/Word plus macros, HTML plus JavaScript, SVG plus JavaScript, ...
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 like they were doing real engineering, when it turns out nobody there seems to know what they're doing, but they've managed to convince some big names to use them.
Man, it's like everything I hate about modern tech. Good job Eva for finding this one. Starting to think that every AI startup or company that is heavily using gen-ai for coding is probably extremely vulnerable to the simplest of attacks. Might be a way to make some extra spending money lol.
I don't think anybody in SFBA-style software development, both pre- and post-LLM, is really resilient against these kinds of attacks. The problem isn't vibe coding so much as it is multiparty DLL-hell dependency stacks, which is something I attribute more to Javascript culture than to any recent advance in technology.
I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.
You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs.
But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or something. Or maybe they vibe coded it and saw it worked and didn't bother to check. Perhaps it's a supply-chain attack on Discord et al to use Mintlify, if thats what you meant then I apologize.
I think you're right that I have an extreme aversion to SFBA-style software development, and partly because of how gen-ai is used there.
You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).
The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.
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
After reading this, I did some research and learned a lot. I never really considered that, by including many things under the same domain, that you're increasing your blast radius w.r.t security vulernabilites. Thanks for that
It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.
But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.
This is what it really comes down to. Browsers are built around origins as the major security boundary. When you use a separate origin, safety comes for free.
This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those.
The vulnerabilities that command real dollars all have half-lives, and can't be fixed with a single cluster of prod deploys by the victims.
If a $500 drone is coming for your $100M factory, the price limit for defense considerations isn't $500.
In the end, you are trying to encourage people not to fuck with your shit, instead of playing economic games. Especially with a bunch of teenagers who wouldn't even be fully criminally liable for doing something funny. $4K isn't much today, even for a teenager. Thanks to stupid AI shit like Mintlify, that's like worth 2GB of RAM or something.
It's not just compensation, it's a gesture. And really bad PR.
That's not how any of this works. A price for a vulnerability tracking the worst-case outcome of that vulnerability isn't a bounty or a market-clearing price; it's a shakedown fee. Meanwhile: the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
> the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
Could you elaborate on this? I don't fully understand the shorthand here.
I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!
> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive?
i know you're an expert in this field. i'm not doubting the assertions just trying to understand them better. if i understand you're argument correctly, you're not doubting that the vuln found here could be damaging, only doubting that it could make money for an adversary willing to exploit it?
I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.
But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.
The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.
I wonder what you think of this, re: the disparity between the economics you just laid out and the "companies are such fkn misers!" comments that always arise in these threads on bounty payouts...
I've seen first hand how companies devalue investment in security -- after all, it's an insurance policy whose main beneficiaries are their customers. Sure it's also reputational insurance in theory, but what is that compared with showing more profit this quarter, or using the money for growth if you're a startup, etc. Basically, the economic incentives are to foist the risks onto your customers and gamble that a huge incident won't sink you.
I wonder if that background calculus -- which is broadly accurate, imo -- is what rankles people about the low bounty rewards, especially from companies that could afford more?
The premise that "fucking companies are misers" operate on that I don't share is that vulnerabilities are finite and that, in the general case, there's an existential cost to not identifying and fixing them. From decades of vulnerability research work, including (over the past 5 years) as a buyer rather than a seller of that work: put 2 different teams on a project, get 2 different sets of vulnerabilities, with maybe 30-50% overlap. Keep doing that; you'll keep finding stuff.
Seen through that light, bug bounty programs are engineering services, not a security control. A thing generalist developers definitely don't get about high-end bug bounty programs is that they are more about focusing internal resources than they are about generating any particular set of bugs. They're a way of prioritizing triage and hardening work, driven by external incentives.
The idea that Discord is, like, eliminating their XSS risk by bidding for XSS vulnerabilities from bounty hunters; I mean, just, obviously no, right?
A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated)
That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it
An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)
Just because on average the intelligence agencies or ransom ware distributors wouldn't pay big bucks for XSS on Zerodium etc. doesn't mean that's setting the fair, or wise price for disclosure. Every bug bounty program is mostly PR mitigation. It's bad PR if you underpay for a disclosed vulnerability, which may have ended your business, considering the price of security audits/practices you cheaped out on. I mean, most bug bounty programs are actually paid by scope, not market price for technically comparable exploits. If you found an XSS vulnerability in an Apple service with this scope, I bet you would have been paid more than 4k.
I do not in fact think you would make a lot more than $4000, or even $4000 in the first place, for an Apple XSS bug, unless it was extraordinarily situationally powerful (for instance, a first-stage for a clean, direct RCE). Bounty prices have nothing at all to do with the worst-case damage a motivated actor could cause with a vulnerability.
Nice, I hadn't seen that. Well, there you go: the absolute most you're going to make for the absolute worst-case XSS bug at the largest software firm in the world.
XSS is not dead, and the web platforms mitigations (setHTML, Trusted Types) are not a panacea. CSP helps but is often configured poorly.
So, this kind of widespread XSS in a vulnerable third party component is indeed concerning.
For another example, there have been two reflected XSS vulns found in Anubis this year, putting any website that deploys it and doesn't patch at risk of JS execution on their origin.
Is it really fair to compare an open source project that desperately wants only $60k a year to hire a dev with companies that have collectively raised over billions of dollars in funding?
I think it’s very fair. Anubis generated a lot of buzz in tech communities like this one, and developers pushed it to production without taking a serious look at what it’s doing on their server. It’s a very flawed piece of software that doesn’t even do a good job at the task it’s meant for (don’t forget that it doesn’t touch any request without “Mozilla” in the UA). If some security criticism gets people to uninstall it, good.
I'd say it's probably worse in terms of scope. The audience for some AI-powered documentation platform will ultimately be fairly small (mostly corporations).
Anubis is promoting itself as a sort of Cloudflare-esque service to mitigate AI scraping. They also aren't just an open source project relying on gracious donations, there's a paid whitelabel version of the project.
If anything, Anubis probably should be held to a higher standard, given many more vulnerable people (as in, vulnerable against having XSS on their site cause significant issues with having to fish their site out of spam filters and/or bandwidth exhaustion hitting their wallet) are reliant on it compared to big corporations. Same reason that a bug in some random GitHub project somewhere probably has an impact of near zero, but a critical security bug in nginx means that there's shit on the fan. When you write software that has a massive audience, you're going to have to be held to higher standards (if not legally, at least socially).
Not that Anubis' handling of this seems to be bad or anything; both XSS attacks were mitigated, but "won't somebody think of the poor FOSS project" isn't really the right answer here.
I don't think it's fair to hold them to the same, or higher standard. at all this is literally a project being maintained by one individual. I'm sure if they were given $5 million in seed money they could probably provide 1000x value for the industry writ large if they could hire a dedicated team for the product like all those other companies with 100,000x the budget.
How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.
If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year?
What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them?
So you're putting pressure on a person who is a researcher, not a producer. Which is wrong.
And also there's the scale. Sure, here you have one guy who exploited a vulnerability. But how long it took them to get there?
There's probably dozens of vulnerabilities yet to be exploited, requiring skills that differ so much from the ones used by this person that they won't find them. Even if you pay them for a full-time position.
Whereas, if you set up a bug bounty program, you are basically crowdsourcing your vulnerabilities: not only you probably have thousands of people actively trying to exploit vulnerabilities in your system, but also, you only give money to the ones that do manage to exploit one.
You're only paying on result.
Obviously, if the reward is not big enough, they could be tempted to sell them to someone else or use them themselves. But the risk is here no matter how you decide to handle this topic.
They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them
I directionally agree with you but we could go another 20 comments deep on exactly what the purpose of an external pentest or red-team exercise is and how it might not match up perfectly with what an amateur web hacker is currently doing. But like: yeah, they could get into that business, at least until AI eats it.
Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)
There are a lot of ways to monetize a security researcher. Publishing research, even "we failed to perform a full exploit", is a huge recruitment tool and brand awareness tool.
It's not quite that simple. I don't think most bug bounty participants want a full-time job. But even more-so in my experience they are not security generalists. You can hire one person who is good at finding obscure XSS vulns, another that's good at exploiting cloud privilege escalation in IAM role definitions, another that's good at shell or archive exploits. If you look at profiles on H1 you'll see most good hackers specialize in specific types of findings.
Having been adjacent to this for years, it's because it's a cost center and not attached to the bonus of any product or program manager. Every now and then we'll get an advocate for security/integrity at a company but the effort lives and leaves with them.
Microsoft, after getting beat up over this for decades, is still horrible at it. In my area they're have been enforced regulations for years but they're written by the industry itself and infected with compliance managers and thus result in wastes of effort that makes compliance managers that came over from HR and legal happy with their eternal job security and minimal hard work.
Until some heavy handed top down regulation, written by people who understand the nature of ongoing security and software and embedded lifecycles, it's going to stay like this. Most existing supply chain regulation I've seen ends up saying "vet your vendors" and gives minimal practical guidance of how to actually do that. Likelihood of some really good law coming out of the current US administration and business climate is left as a comedy for the reader.
I wonder if this analogy could work: if some random visitor pointed out your storage room's key is nearly broken and anybody could come in now and steal your store's stock. You'd be thankful, but would you hire them to come from time to time to check if they have any other insight ? Probably not ?
If you really saw a recurring security risk you'd have many other better use of your money.
Nice discovery and writeup. Let alone for a 16 yo!.
I've never heard an XSS vulnerability described as a supply-chain attack before though, usually that one is reserved for package managers malicious scripts or companies putting backdoors in hardware.
I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows).
As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the trust model (the browser's origin model) seems to indicate all is fine (like the signing on the binary). But because earlier in the supply chain they made a mistake, you are now at risk. Its basically moving an XSS up a level into the "supply chain".
Given this (including the linked writeup on the mintlify RCE), after the React RCE, if think it should be pretty obvious that
1. content security policies should always be used to prevent such scripts (here they would prevent execution of scripts from the SVG)
2. The JavaScript ecosystem should be making ` --disallow-code-generation-from-strings` a default recommendation when running NodeJS on the server.
Vercel (and other nodejs as a service providers) should warn customers that don't use CSP and `--disallow-code-generation-from-strings` that their settings should be improved.
Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.discord.com or something?
This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.
We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them.
The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is.
I wish Mintlify the best here – it's stressful to let customers down like this.
What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).
I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.
This is a great example of why a Content-Security-Policy (CSP Header) should be considered mandatory for high risk sites. With it you can effectively tell the browser what JS is allowed to run, meaning that any JS injected via XSS won't work.
Damn, this is a good era to be in high school (or university) with a lot of free time. $4000 is a pretty good haul for a few hours of work poking at stuff.
I've been following the rise of SVG based attacks recently... It's not just hypothetical anymore... People are using SVG files to deliver full phishing pages and drive by downloads by hiding JavaScript in the markup
ALSO as someone who maintains a file upload pipeline I run every SVG through a sanitizer... Tools like DOMPurify remove scripts and enforce a safe subset of the spec... I even go as far as rasterizing user uploaded vectors to PNG when possible
HOWEVER the bigger issue is mental... Most folks treat SVG like a dumb image when browsers treat it like executable content... Until the platform changes that expectation there will always be an attack surface
Mintlify security is the worse I have even encountered in a modern SaaS company.
They will leak your data, code, assets, etc. They will know they did this. You will tell them, they will acknowledge that they knew it happened, and didn't tell you.
Your docs site will go down, and you will need to page their engineers to tell them its down. This will be a surprise to them.
Slightly related, as someone who doesn’t engage in this type of work, I’m curious about the potential risks associated with discovering, testing, and searching for security bugs. While it’s undoubtedly positive that this individual ultimately became a responsible person and disclosed the information, what if they hadn’t? Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good? Has there been cases where the risk involved wasn’t justified by the relatively low $4k reward? Or any specific companies you wouldn’t want to do this with because of a past incident with them?
If you engage in “white hat security research” on organisations who haven’t agreed to it (such as by offering roles of engagement on a site like hacker one) there is indeed a risk.
For example they might send the police to your door, who’ll tell you you’ve violated some 1980s computer security law.
I know 99.99% of cybercrime goes unpunished, but that’s because the attackers are hard to identify, and in distant foreign lands. As a white hat you’re identifiable and maybe in the same country, meaning it’s much easier to prosecute you.
> Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good?
Companies will create bug bounty programs where they set ground rules (like no social engineering), and have guides on how to identify yourself as an ethical hacker, for example:
Stupid, especially because he is a kid and young in his career.
His lifetime earnings and ability to score a better paying job is worth way more than an extra couple thousand dollars selling this kind of exploit to criminals. It's why NDA's for security vulnerabilities are harmful because it doesn't allow a kind of social credit accumulation
Back in the day the US government would give you $20k-60k cash in a nice briefcase for this type of exploit. Just another thing big tech has ruined I suppose.
Apple gave me $47k back when I was 16 and it definitely changed my life. Was subsequently able to get out of my 3rd world country and pay for university in the UK. While the quality of education is disappointing, having a graduate visa makes it so much easier to get a job or start a business there.
No not to individuals. There are absolutely contracts you can score for certain attack surfaces but that usually involves going through a company. If this person is from the united states, they will absolutely land themselves a good scholarship and a very well-paid job with a security clearance.
The book "This Is How They Tell Me the World Ends" by Nicole Perlroth, while it's about the history of cyberweapons it does a very good job detailing the late 90s to early 2010s exploit market.
I don't have it in front of me, but I'm talking about the "nobody but us" era of exploit markets:
Where the NSA seemingly was buying anything, even if not worthwhile, as a form of "munitions collection" to be used for the future attacks.
edit: this mostly ended in the US because other nations started paying more, add in more regulations (only a handful companies are allowed to sell these exploits internationally) and software companies starting to do basic security practices (along with ruling out their own bug bounties), it just mostly whimpered away.
Also relevant to the discussion, the book discusses how the public exploit markets are exploitive to the workers themselves (low payouts when state actors would pay more) and there are periods of times where there would be open revolts too (see 2009 "No More Free Bugs" movement, also discussed in the book).
Definitely worth it if you aren't aware of this history, I wasn't.
I haven't read her book, am myself somewhat read in to the background here, and if she's claiming NSA was stockpiling serverside web bugs, I do not believe her.
In reality, intelligence agencies today don't even really stockpile mobile platform RCE. The economics and logistics are counterintuitive. Most of the money is made on the "backend", in support/update costs, paid in tranches; CNE vendors have to work hard to keep up with the platforms even when their bugs aren't getting burned. We interviewed Mark Dowd about this last year for the SCW podcast.
Maybe there is a misunderstanding, I'm not saying that the NSA would be buying XSS scripts. I'm saying that if this was 35 years ago the NSA would be buying exploits with common user software. Back then the exploits were "lesser" but there still was a market and not every exploit that was bought was a wonder of software engineering. Nowadays the targeted market is the web and getting exploits on some of the most used sites would be worthy of buying.
Kid was simply born in the wrong era to cash out easy money.
I think you're wrong about this. 35 years ago was 1990. Nobody was selling vulnerabilities in 1990 at all. By 1995, I was belting out memory corruption RCEs (it was a lot easier then), and there was no market for them at all. And there has never been a market for web vulnerabilities like XSS.
Building reliable exploits is very difficult today, but the sums a reliable exploit on a mainstream mobile platform garner are also very high. Arguably, today is the best time to be doing that kind of work, if you have the talent.
I can't imagine intelligence agencies/DoD not doing this with their gargantuan black budgets, if it's relevant to a specific target. They already contract with private research centers to develop exploits, and it's not like they're gonna run short on cash
If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not.
The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used, which is not how e.g. a mobile browser drive-by works.
Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary
detected: WAF caught or detected the attack and raised an alert, post-exploitation
discovered: they audited or pentested themself and found out, preemptively
I just mean that Coinbase didn’t see anything happening and didn’t take action though the boy successfully exploited the vulnerability on their live system.
It’s clear to me now that I need to set up my home machine the way I set up BYOD when I was contracting last. I need a separate account for all of my development.
I have a friend who at one point had five monitors and 2 computers (actually it might be 3) on his desk and maybe he’s the one doing it right. He keeps his personal stuff and his programming/work stuff completely separate.
I have three OS installs. Windows install for games. Another Windows for development (I have to for windows dev). And a Ubuntu install for anything not games/work. The windows drives use bitlocker and they can't access each other's files. It's not perfect.
Although with the amount of crap I have to install for windows development I'm starting to wonder if a base VM image that is used as a start point for each project would be cleaner.
I run an infosec firm and we have done attacks like this on my clients over and over and over in audits. I always say any bored teen could do most of what we do because most companies are moving too fast feature farming to have any time for responsible security hardening, and now I have yet another great citation.
Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work. Finding bugs in the wild as this researcher did often gets wildly underpaid relative to the potential impact of the bug, if they pay or take it seriously at all.
These companies should be ashamed paying out so little for this, and it is only a matter of time before they insult the wrong researcher who decides to pursue paths to maximum profit, or maximum damage, with a vuln like this.
> Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work.
So, rough estimate, how much would you have made for this?
We normally find things like this in our usual 60 hour audit blocks. Rates change over time with demand, but today an audit of that length would be $27k.
Even that is quite cheap compared to letting a blackhat find this.
If I can ask on business model, as I have a friend with a similar predicament — what percent of the time do you find vulnerabilities in those audits? Do companies push back if you don't find vulnerabilities?
We have never issued a clean report in our ~5 years of operation.
Some firms have a reputation for issuing clean reports that look good to bosses and customers, but we prefer working with clients that want an honest assessment of attack surface and how motivated blackhats will end their business.
We also stick around on retainer for firms that want security engineering consulting after audits to close the gaps we find and re-architect as needed. Unused retainer hours go into producing a lot of open source software to accelerate fixing the problems we see most often. This really incentivizes us to produce comprehensive reports that take into account how the software is developed and used in the real world.
Under our published threat model few companies pass level one, and we have helped a couple get close to level 2 with post audit consulting.
Our industry has a very long way to go as current industry standard practices are wildly dangerous and make life easy for blackhats.
As someone in a related line of work: we find vulnerabilities so close to 100% of the time that it might as well be 100% of the time. Whether they're practically exploitable or surpass your risk appetite is the real question.
These companies almost always produce "vulnerabilities", but they're also almost always trash.
"Finding: This dependency is vulnerable to CVE-X, update it, severity S". And then of course that dependency is only used during development, the vulnerable code isn't called, and they didn't bother to dig into that.
"Finding: Server allows TLS version 1.1, while it's recommended to only support version 1.2+", yeah, sure, I'm sure that if someone has broken TLS 1.1, they're coming for me, not for the banks, google, governments, apple, etc, everyone else still using TLS 1.1
... So yeah, all the audits will have "findings", they'll mostly be total garbage, and they'll charge you for it. If you're competent, you aren't going to get an RCE or XSS out of a security audit since it simply will not be there.
Okay, seriously, can we just get one, just ONE document/image spec that doesn't let you embed scripts or remote content? What is with this constant need to put the same exactly vulnerability into EVERYTHING?! Just let me have a spec for completely static documents, jfc!
One of these days I'm gonna have to learn why cross-site scripting even matters, especially with modern browsers restricting a script's access to anything local
The "Hello world" examples always show using it to steal your cookies, which obviously doesn't work now when nearly every site uses the "httpOnly" flag which makes the cookie inaccessible to JavaScript, but really, stealing your session isn't necessary. They just have to make the XSS payload run the necessary JavaScript.
Once the JavaScript is running on the page, all bets are off. They can do ANYTHING that the page can do, because now they can make HTTP requests on your behalf. SOP no longer applies. CSRF no longer protects you. The attacker has full control of your account, and all the requests will appear to come from YOUR browser.
It's a good question and one mature orgs ask themselves all the time. As you can see from most of the replies here, XSS captures the fancy of the bug bounty crowd because there are tonnes of hypothetical impacts so everyone is free to let their imagination run wild when arguing with triagers. It's also the exploit nonpareil for nerdsnipers because sanitisation is always changing and people get to spend their days coming up with increasingly ridiculous payloads to bypass them. In reality, find me one active threat actor who has compromised a business lately with an XSS. It's not an irrelevant risk, but the attention it gets is wildly disproportionate to its real-world impact.
If I can run my own code but in your context, I can pull in malicious scripts.
With those (all these are "possible" but not always, as usual, it depends, and random off the top of my head):
- I can redirect you to sites I control where I may be able to capture your login credentials.
- May be able to prompt and get you to download malware or virus payloads and run them locally.
- Can deface the site you are on, either leading to reputational harm for that brand, or leading you to think you're doing one thing when you're actually doing another.
- I may be able to exfiltrate your cookies and auth tokens for that site and potentially act as you.
- I might be able to pivot to other connected sites that use that site's authentication.
- I can prompt, as the site, for escalated access, and you may grant it because you trust that site, thereby potentially gaining access to your machine (it's not that the browsers fully restrict local access, they just require permission).
- Other social engineering attacks, trying to trick you into doing something that grants me more access, information, etc.
Cool. Makes me want to get into that — checking out sites for vulnerabilities. Very impressive for a 16 year old. Should definitely have been paid more.
The linked site https://heartbreak.ing/ explains that Mintlify disabled CORS, so that 3rd party sites can run code in your Mintlify-using environment (X, Vercel, etc).
The OP site says that .svg files can only run scripts if they are directly opened, not via <img> tags.
My understanding, the SVGs were imported directly and embedded as code, not as a `src` for an img tag. This is very common, it's a subjectively better (albeit with good security practices) way to render SVGs as it provides the ability to adjust and style them via CSS as they are now just another element in the HTML DOM. It should only be done with "trusted" SVGs however!
As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.
You're pretty much on the money. Reflected XSS requires social engineering to really target anyone without other primitives. Unfortunately this report is not very clear about the tangible impacts or limitations of what they could do with this particular XSS either. Saying that every Mintlify customer was "vulnerable to account takeover with a single malicious link" strikes me as specious to say the least. Still, can't fault kids for getting excited about recognition and a payout.
imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script grabs their cookie and credentials and sends it to the attacker. they now have full access to the victim's account.
Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.
XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.
It is not as cool as the RPC exploit of React/Next.js where you could call any function on the server-side including “vm.sysexec” or whatever it was, but still not to be fully ignored
How is XSS not remote code execution? You can do anything, from send fetch requests to the server with full credentials to loggging keystrokes or even open a tunnel and eval payloads...
Anything the user can do, you can do via an XSS attack.
Show me where you can "open a tunnel" using the XSS in this post.
> Anything the user can do, you can do via an XSS attack.
I just explained why this isn't a reasonable assumption. You seem to have multiple fundamental misunderstandings about web application security so I don't think it's constructive for either of us to continue this conversation.
Go to Discord and paste that into your console. None of us will hold it against you if you come back and delete these comments once you learn about Content Security Policy.
the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.
You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).
> the auth token is stored in local storage
Has anyone reported this (rhetorical question)? What in the world could be the justification for this?
In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
It's hosted on the official domain. That means you have at least 2 options: a) chain in with another issue which allows to load that as a trusted resource, or b) scam people by directing them to an "official" post. Also you get discord cookies access.
You have control over what displays on a page with a discord.com domain, you could manipulate the dom to have a login or something else and have it pass the data to your servers. A user would just see a link from discord.com
You could send that link to an unsuspecting user and steal their cookies, make API requests to send messages on their behalf, etc
Apparently one of the other linked posts shows how you can also gain RCE, since the docs are statically pre-rendered and there’s no sandboxing to prevent you from evalling arbitrary JavaScript.
Also linked in his guide (which I missed) and [here in a separate HN post](https://news.ycombinator.com/item?id=46317546). I think this other author's post is a lot more detailed and arguably more useful to folks reading on HN.
if you click on the link because it has discord.com in the domain the script in the SVG can (maybe) get your session data. Not actually sure if that’s true though, I suppose it depends on how the cookies are scoped
I was going to ask. Isn't 4k from Discord pretty low for the work conducted here? I'm not familiar with bounty payouts. I'm hoping these companies aren't taking advantage of them.
4k is sadly discords highest bounty they give out (screenshot from their bugcrowd program: https://imgur.com/a/KNIdeXh) even more critical issues then this one get paid the same amount out
Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.
That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.
You are right, but that could (probably not) make them go for the bad route because they would get way more money that way. 4k for a bug that could take control of your customer account sounds disrespectful to me.
Yeah, my read is that the teenage hacker confronted with this ridiculous payslip sees two ways forward: accept the pay cut for the CV benefit of working with bug bounties, or get a bit better at hiding your ass and make them really pay.
If I were 16, I’d be thinking I just made an obscene amount of money ($4,000!) messing with computers for fun, and got to meet people at a famous company.
That’s a free car. Free computer. Uber eats for months.
And my status with my peers as a hacker would be cemented.
I get that bounty amounts are low vs SE salary, but that’s not at all how my 16yo self would see it.
I hope I'm not assuming too much but I'm really hope the up and coming hacker is smart enough to know that his work was worth more than $4,000. That's 1-2% of an annual SE salary for someone with similar skillset.
I mean, as a hiring manager, a fresh grad with multiple bug bounties tells me a lot about their drive and skill, so I'd agree. It's a great differentiator.
This is a pretty scary exploit, considering how easily it could be abused.
Imagine just one link in a tweet, support ticket, or email: https://discord.com/_mintlify/static/evil/exploit.svg. If you click it, JavaScript runs on the discord.com origin.
Here's what could happen:
- Your Discord session cookies and token could be stolen, leading to a complete account takeover.
- read/write your developer applications & webhooks, allowing them to add or modify bots, reset secrets, and push malicious updates to millions.
- access any Discord API endpoint as you, meaning they could join or delete servers, DM friends, or even buy Nitro with your saved payment info.
- maybe even harvest OAuth tokens from sites that use "Login with Disord."
Given the potential damage, the $4,000 bounty feels like a slap in the face.
edit: just noticed how HN just turned this into a clickable link - this makes it even scarier!
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 that without causing a page load).
Wow did not realize a url could be set like that without promoting a page reload...
Well that's how SPAs work (single page applications)
To be clear only the path and query parameters part of the url can change, the domain (or sub domain) stays intact.
How do you modify the url exactly?
https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
`history.replaceState(null, "", "/login")`
For Coinbase docs, this is a disaster particularly
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.
Discord puts the authentication token in local storage
if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user
You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.
The fact that it is just so trivial and obvious that its scary. It didn't even require any real hacking chops, just patience: literally anyone with a cursory knowledge of site design could have stumbled on this if they were looking at it.
Terrifying.
> - Your Discord session cookies and token could be stolen, leading to a complete account takeover.
Discord uses HttpOnly cookies (except for the cookie consent banner).
>the $4,000 bounty feels like a slap in the face.
And serves a reminder crime does pay.
In the black market, it would have been worth a bit more.
yeah, but nothing pays as much as doing free work for (checks notes) mintlify feels
No it would not have been.
This specific XSS vulnerability may not have been, but the linked RCE vulnerability found by their friend https://kibty.town/blog/mintlify/ certainly would've been worth more than the $5,000 they were awarded.
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.
Maybe? I don't know enough about the vulnerability. Is it serverside? Then it isn't worth very much.
Could you elaborate on why not?
What 'arcwhite said (sorry, I got dragged into a call).
1. The exploits (not vulnerabilities; that's mostly not a thing) that command grey/black market value all have half-lives.
2. Those exploits all fit into existing business processes; if you're imagining a new business, one that isn't actively running right now as we speak (such as you'd have to do to fit any XSS in a specific service), you're not selling an exploit; you're planning a heist.
3. The high-dollar grey market services traffic exclusively in RCE (specifically: reliable RCE exploits, overwhelmingly in mainstream clientside platforms, with sharp dropoffs in valuation as you go from e.g. Chrome to the next most popular browser).
4. Most of the money made in high-ticket exploit sales apparently (according to people who actually do this work) comes on the backend, from tranched maintenance fees.
There's generally no grey market for XSS vulns. The people buying operationalized exploits generally want things that they can aim very specifically to achieve an outcome against a particular target, without that target knowing about it, and operationalized XSS vulns seldom have that nature.
Your other potential buyers are malware distributors and scammers, who usually want a vuln that has some staying power (e.g. years of exploitability). This one is pretty clearly time-limited once it becomes apparent.
It would have been. Ten times the amount at least.
For a reflected XSS? Tell me who is paying that much for such a relatively common bug...
To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc
No real way to use this to compromise a large amount of users without more complex means
Also the XSS exploit would have been dead in the water for any sites using CSP headers. Coinbase certainly uses CSP. With this in place an XSS vuln can't inject arbitrary JS.
It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.
Yes, but this is not a particularly high access level bug.
Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)
I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss
Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.
In addition this is widespread. It's golden for any attacker.
Because modern cookie directives and browser configs neuter a lot of the worst XSS outcomes/easiest exploit paths. I would expect all the big sites to be setting them, though I guess you never know.
I would not be that confident as you can see: on their first example, they show Discord and the XSS code is directly executed on Discord.com under the logged-in account (some people actually use web version of Discord to chat, or sign-in on the website for whatever reason).
If you have a high-value target, it is a great opportunity to use such exploits, even for single shots (it would likely not be detected anyway since it's a drop in the ocean of requests).
Spreading it on the whole internet is not a good strategy, but for 4000 USD, being able to target few users is a great value.
Besides XSS, phishing has its own opportunity.
Example: Coinbase is affected too though on the docs subdomain and there are 2-step, so you cannot do transactions directly but if you just replace the content with a "Sign-in to Coinbase / Follow this documentation procedure / Download update", this can get very very profitable.
Someone would pay 4000 USD to receive 500'000 USD back in stolen bitcoins).
Still, purely with executing things under the user sessions there are interesting things to do.
Again, here you have not so much sold a vulnerability as you have planned a heist. I agree, preemptively: you can get a lot of money from a well-executed heist!
Do you want to execute actions as logged-in user on high-value website XXX ?
If yes -> very useful
Nobody is disputing that a wide variety of vulnerabilities are "useful", only that there's no market for most of them. I'd still urgently fix an XSS.
There is a market outside Zerodium, it's Telegram. Finding a buyer takes time and trust, but it has definitively higher value than 4k USD because of its real-world impact, no matter if it is technically lower on the CVSS scores.
Really? Tell me a story about someone selling an XSS vulnerability on Telegram.
("The CVSS chart"?)
Moments later
Why do people keep bringing up "Zerodium" as if it's a thing?
I understand your perspective about the technical value of an exploit, but I disagree with the concept that technical value = market value.
There are unorganized buyers who may be interested if they see potential to weaponize it.
In reality, if you want to maximize revenue, yes, you need to organize your own heist (if that's what you meant)
How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.
What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.
I don't like tptacek, but it's insane to not back up this comment with any amount of evidence or at least explanation. The guy knows his shit.
Hey I was wrong about Apple downthread.
The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.
This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.
All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.
Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.
Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.
Is there SVG sanitization code which has been formally proven correct and itself free of security vulnerabilities?
GitLab has some code in their repo if you want to see how to do it.
This is what they actually use: https://github.com/flavorjones/loofah
Sanitisation is a tricky process, it can be real easy for something to slip through the cracks.
Yeah I’ve worked on a few pieces of software now that tried SVG sanitizing on uploads, got hacked, and banned the uploads.
I guess it is a matter of parsing svg. Trying to hack around with regex is asking for trouble indeed.
just run them through `svgo` and get the benefits of smaller filesizes as well
svgo is a minifier, not a sanitizer.
External entities in XML[1] were a similar issue back when everyone was using XML for everything, and parsers processed external-entities by default.
1: https://owasp.org/www-community/vulnerabilities/XML_External...
XXE should have never existed.
Whoever decided it should be enabled by default should be put into some sort of cybersecurity jail.
At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.
Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.
I once sent a Sierpinski's Triangle postscript program to a shared printer. It took 90 minutes, and pissed off everybody else trying to print.
One of the very first SVG documents I encountered was a port of the PS Tiger to SVG. It loaded a lot faster than the PostScript Tiger.
PostScript can emulate the ZMachine (Zork text adventures and all of infocom) with "zmachine.ps". Look it up at DDG/GG.
Sounds almost like a fun crypto mining opportunity.
With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.
calling Leonard Rosenthol ...
Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?
I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.
The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.
The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.
Shouldn't the ignoring of scripting be done at the user agent level? Maybe some kind of HTTP header to allow sites to disable scripts in SVG ala CORS?
No, svgs can do `onload` and `onerror` and also reference other svgs that can themselves contain those things (base64'd or behind a URI).
But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work, or use a CSP. I wouldn't rely on sanitizing, but I'd still sanitize.
IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.
I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?
They are like PDFs in that they do not render the same with different software or on different devices.
You definitely don't understand PDFs, let alone SVGs.
PDFs can also contain scripts. Many applications have had issues rendering PDFs.
Don't get me wrong, the folks creating the SVG standard should've used their heads. This is like the 5th time (that I am aware of) this type of issue has happened, (and at least 3 of them were Adobe). Allowing executable code in an image/page format shouldn't be a thing.
I would say PDFs are actually reasonably consistent though. Weird things happen on occasion, but I've certainly had more success than with SVGs.
We live in a world where Adobe set the standard, and anything that didn't render like Adobe was considered "incorrect".
SVG can for example contain text elements rendered with a font. If the font is not available it will render in a different one. The issue can be avoided by turning text elements into paths, but not all SVGs do that.
More like HTML and getting different browsers to render pixel perfectly identical result (which they don't) including text layout and shaping. Where different browser don't mean just Chrome, Firefox, Safari but also also IE6 and CLI based browsers like Lynx.
PDFs at least usually embed the used subset of fonts and contain explicit placement of each glyph. Which is also why editing or parsing text in PDFs is problematic. Although it also has many variations of Standard and countless Adobe exclusive extensions.
Even when you have exactly the same font text shaping is tricky. And with SVGs lack of ability to embed fonts, files which unintentionally reference system font or a generic font aren't uncommon. And when you don't have the same font, it's very likely that any carefully placed text on top of diagram will be more or less misplaced, badly wrap or even copletely disappear due to lack of space. Because there is 0 consistency between the metrics across different fonts.
The situation with specification is also not great. Just SVG 1.1 defines certain official subsets, but in practice many software pick whatever is more convenient for them.
SVG 2.0 specification has been in limbo for years although seems like recently the relevant working group has resumed discussions. Browser vendors are pushing towards synchronizing certain aspects of it with HTML adjacent standards which would make fully supporting it outside browsers even more problematic. It's not just polishing little details many major parts that were in earlier drafts are getting removed, reworked or put on backlog.
There are features which are impractical to implement or you don't want to implement outside major web browsers that have proper sandboxing system (and even that's not enough once uploads get involved) like CSS, Javascript, external resource access across different security contexts.
There are multiple different parties involved with different priorities and different threshold for what features are sane to include:
- SVG as scalable image format for icons and other UI elements in (non browser based) GUI frameworks -> anything more complicated than colored shapes/strokes can problematic
- SVG as document format for Desktop vector graphic editors (mostly Inkscape) -> the users expect feature parity with other software like Adobe Illustrator or Affinity designer
- SVG in Browsers -> get certain parts of SVG features for free by treating it like weird variation of HTML because they already have CSS and Javascript functionality
- SVG as 2d vector format for CAD and CNC use cases (including vinyl cutters, laser cutters, engravers ...) -> rarely support anything beyond shapes of basic paths
Beside the obviously problematic features like CSS, Javascript and animations, stuff like raster filter effects, clipping, text rendering, and certain resource references are also inconsistently supported.
From Inkscape unless you explicitly export as plain 1.1 compatible SVG you will likely get an SVG with some cherry picked SVG2 features and a bunch of Inkscape specific annotations. It tries to implement any extra features in standard compatible way so that in theory if you ignore all the inkscape namespaced properties you would loose some of editing functionality but you would still get the same result. In practice same of SVG renderers can't even do that and the specification for SVG2 not being finalized doesn't help. And if you export as 1.1 plain SVG some features either lack good backwards compatibility converters or they are implemented as JavaScript making files incompatible with anything except browsers including Inkscape itself.
Just recently Gnome announced working on new SVG render. But everything points that they are planning to implement only the things they need for the icons they draw themselves and official Adwaita theme and nothing more.
And that's not even considering the madness of full XML specification/feature set itself. Certain parts of it just asking for security problems. At least in recent years some XML parsers have started to have safer defaults disabling or not supporting that nonsense. But when you encounter an SVG with such XML whose fault is it? SVG renderer for intentionally not enabling insane XML features or the person who hand crafted the SVG using them.
Most renderers don't implement the full spec.
Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.
Does it need to be as complicated as a new format? Or would it be enough to not allow any scripting in the provided SVGs (or stripping it out). I can't imagine there are that many SVGs out there which take advantage of the feature.
But how else would we revisit all the security bugs of Flash/Macromedia?
Wikipedia, which allows uploading media, deals with this by rendering svgs on the server side.
Could there be a limited format that disables scripting? Like in Excel: xlsx files have no macros, but xlsm (and the old xls) can contain macros.
I agree, when animating SVGs I never put the js inside them so having the ability embed it is just dangerious I think
If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.
(Yes I'm still salty about Flash.)
> because we didn't want to bother maintaining it anymore
That wasn't the only reason. Flash was also proprietary, and opaque, and single-vendor, among many other problems with it.
SVG without <script> would do just fine.
Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.
The Flash revisionism I see around here occasionally is bizarre.
No, Flash was terrible and killing it was good.
There is artistically no equivalent to Flash ever since it died. Nothing else has allowed someone with artistic skills but no programming skills to create animations and games to the same degree and with the same ease.
I'd say Roblox is absolutely filling that market need. And as mentioned elsewhere, the "animations and games" demographic has moved on in the intervening decades to social media, and tools like CapCut make creating online content easier than it ever has been.
Honestly I think a lot of the Flash mania is just middle aged nerds fondly remembering their youth. The actual tool was a flash in the pan, and part of a much more complicated history of online content production. And the world is doing just fine without it.
what is missing was a replacement for the flash editor itself, not the format.
It was terrible from a security POV, but the tooling was superb.
I remember my teenage friends creating things with flash in a way that doesn't happen on the modern web.
Sure, but that's because the media and forums change, not so much a point about tool capability. The equivalent of teenaged geeks hacking on flash games today is influencer wannabes editting trends in CapCut. If anything content production is far more accessible now than in the 90's.
I think it depends on whether you see Flash as competing with webvideo or with downloadable executables.
Do other vector formats have the same vulnerabilities?
is santizing SVGs hard, or just everyone forgets they can contain js?
I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.
I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!
Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.
its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)
i wonder do people not do this with svgs?
Disabling script execution in svgs is very easy, it's just also easy to not realize you're about to embed an svg. `<img src="evil.svg">` will not execute scripts, a bit like your "noscripting" attribute except it's already around and works. Content Security Policy will prevent execution as well, you should be setting one for image endpoints that blocks scripts.
Sanitizing is hard to get right by comparison (svgs can reference other svgs) but it's still a good idea.
User name checks out.
Wow, I learned one thing today!
"The script doesn't run unless the file is directly opened (you can't run scripts from (<img src="/image.svg">)."
It will run if its in an <object> tag.
There is: PDF. You may not like it or adobe, but its there and widely supported.
PDF also has script support unfortunately.
That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.
Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405
Does that mean that opening arbitrary pdfs on your laptop is unsafe?
Let me put it this way...
In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.
Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.
Yes, opening random pdfs especially in random and old pdf viewers is not a good idea.
If you must open a possibly infected pdf, then do it in browser, pdf.js is considered mostly safe, and updated.
Use the PDF to JPG online services, convenient and you still get your result without having to deal with any sandbox
Except of course that you're sharing the contents of that PDF with a random online service.
True, I just considered that once you handle a PDF with so much care like if it was poisoned, it's perhaps better to send this poison to someone else to handle.
Better a DJVU file generated at a high DPI.
It's wild how often we rediscover that executing untrusted code leads to decades of whack-a-mole security. Excel/Word plus macros, HTML plus JavaScript, SVG plus JavaScript, ...
It’s wild how often specs are ok for 9 versions, and then at version 10, standard bodies decide to transform them into a trojan firehose.
It’s so regular like clockwork that it has to be a nation state doing this to us.
Any notable examples you can share?
PDF was purposely a non-Turing adaptation of PostScript. Then they added JavaScript support.
> On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand
Didn’t we do this already with Flash? Why would this lesson not have stuck?
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 like they were doing real engineering, when it turns out nobody there seems to know what they're doing, but they've managed to convince some big names to use them.
Man, it's like everything I hate about modern tech. Good job Eva for finding this one. Starting to think that every AI startup or company that is heavily using gen-ai for coding is probably extremely vulnerable to the simplest of attacks. Might be a way to make some extra spending money lol.
I don't think anybody in SFBA-style software development, both pre- and post-LLM, is really resilient against these kinds of attacks. The problem isn't vibe coding so much as it is multiparty DLL-hell dependency stacks, which is something I attribute more to Javascript culture than to any recent advance in technology.
I wonder what's worse, the SFBA-style software development, but also with SFBA-style 2 hour response window to serious bugs like Discord showed, or the old fashioned enterprise report your bug and within 2 months you'll receive an e-mail confirming your report if you're lucky and a letter from a lawyer if you're not.
You're right that it's a specific programming culture that is especially vulnerable to it. And for the same reasons they were vulnerable to the same thing to a lesser degree before the rise of LLMs.
But like, this case isn't really a dependency or supply chain attack. It's just allowing remote code execution because, idk, the dev who implemented it didn't read the manual and see that MDX can execute arbitrary code or something. Or maybe they vibe coded it and saw it worked and didn't bother to check. Perhaps it's a supply-chain attack on Discord et al to use Mintlify, if thats what you meant then I apologize.
I think you're right that I have an extreme aversion to SFBA-style software development, and partly because of how gen-ai is used there.
One might consider this a supply chain attack because the title of the post is “We pwned X, Vercel, Cursor, and Discord through a supply-chain attack”
I do occasionally wonder how different things would be if JavaScript had come with a very robust standard library from early on.
You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).
The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.
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
Thanks for this comment tick_tock :)
After reading this, I did some research and learned a lot. I never really considered that, by including many things under the same domain, that you're increasing your blast radius w.r.t security vulernabilites. Thanks for that
It's a bit surprising they did that, to be honest. I work at a similarly-sized, HN-popular tech company and our security team is very strict about less-trusted (third party!!) code running on another domain, or a subdomain at the very least, with strict CSP and similar.
But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.
This is what it really comes down to. Browsers are built around origins as the major security boundary. When you use a separate origin, safety comes for free.
I'm curious what caching architecture a docs site needs, it can't be more complicated than a standard fare CDN?
Here's the other post:
https://news.ycombinator.com/item?id=46276313
Search indexing, etc.
Seems like such a tiny amount of money for a bug that can be used to completely own your customers accounts. Also not much excuse for xss these days.
This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those.
The vulnerabilities that command real dollars all have half-lives, and can't be fixed with a single cluster of prod deploys by the victims.
If a $500 drone is coming for your $100M factory, the price limit for defense considerations isn't $500.
In the end, you are trying to encourage people not to fuck with your shit, instead of playing economic games. Especially with a bunch of teenagers who wouldn't even be fully criminally liable for doing something funny. $4K isn't much today, even for a teenager. Thanks to stupid AI shit like Mintlify, that's like worth 2GB of RAM or something.
It's not just compensation, it's a gesture. And really bad PR.
That's not how any of this works. A price for a vulnerability tracking the worst-case outcome of that vulnerability isn't a bounty or a market-clearing price; it's a shakedown fee. Meanwhile: the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
> the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
Could you elaborate on this? I don't fully understand the shorthand here.
I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!
> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.
what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive?
i know you're an expert in this field. i'm not doubting the assertions just trying to understand them better. if i understand you're argument correctly, you're not doubting that the vuln found here could be damaging, only doubting that it could make money for an adversary willing to exploit it?
I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.
But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.
The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.
Thank you, makes a lot of sense.
I wonder what you think of this, re: the disparity between the economics you just laid out and the "companies are such fkn misers!" comments that always arise in these threads on bounty payouts...
I've seen first hand how companies devalue investment in security -- after all, it's an insurance policy whose main beneficiaries are their customers. Sure it's also reputational insurance in theory, but what is that compared with showing more profit this quarter, or using the money for growth if you're a startup, etc. Basically, the economic incentives are to foist the risks onto your customers and gamble that a huge incident won't sink you.
I wonder if that background calculus -- which is broadly accurate, imo -- is what rankles people about the low bounty rewards, especially from companies that could afford more?
The premise that "fucking companies are misers" operate on that I don't share is that vulnerabilities are finite and that, in the general case, there's an existential cost to not identifying and fixing them. From decades of vulnerability research work, including (over the past 5 years) as a buyer rather than a seller of that work: put 2 different teams on a project, get 2 different sets of vulnerabilities, with maybe 30-50% overlap. Keep doing that; you'll keep finding stuff.
Seen through that light, bug bounty programs are engineering services, not a security control. A thing generalist developers definitely don't get about high-end bug bounty programs is that they are more about focusing internal resources than they are about generating any particular set of bugs. They're a way of prioritizing triage and hardening work, driven by external incentives.
The idea that Discord is, like, eliminating their XSS risk by bidding for XSS vulnerabilities from bounty hunters; I mean, just, obviously no, right?
A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated) That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it
An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)
> That's not how any of this works.
Yes, evidently not.
Just because on average the intelligence agencies or ransom ware distributors wouldn't pay big bucks for XSS on Zerodium etc. doesn't mean that's setting the fair, or wise price for disclosure. Every bug bounty program is mostly PR mitigation. It's bad PR if you underpay for a disclosed vulnerability, which may have ended your business, considering the price of security audits/practices you cheaped out on. I mean, most bug bounty programs are actually paid by scope, not market price for technically comparable exploits. If you found an XSS vulnerability in an Apple service with this scope, I bet you would have been paid more than 4k.
Nobody is buying anything on "Zerodium".
I wasn't aware they are gone. It's not my game, replace with whatever shady exploit trader/market out there.
I do not in fact think you would make a lot more than $4000, or even $4000 in the first place, for an Apple XSS bug, unless it was extraordinarily situationally powerful (for instance, a first-stage for a clean, direct RCE). Bounty prices have nothing at all to do with the worst-case damage a motivated actor could cause with a vulnerability.
https://security.apple.com/bounty/categories/
The lowest tier is $5k. XSS up to $40k. I think we're talking exfiltration of dev credentials...
Nice, I hadn't seen that. Well, there you go: the absolute most you're going to make for the absolute worst-case XSS bug at the largest software firm in the world.
>Also not much excuse for xss these days.
XSS is not dead, and the web platforms mitigations (setHTML, Trusted Types) are not a panacea. CSP helps but is often configured poorly.
So, this kind of widespread XSS in a vulnerable third party component is indeed concerning.
For another example, there have been two reflected XSS vulns found in Anubis this year, putting any website that deploys it and doesn't patch at risk of JS execution on their origin.
Audit your third-party dependencies!
https://github.com/TecharoHQ/anubis/security/advisories/GHSA...
https://github.com/TecharoHQ/anubis/security/advisories/GHSA...
Is it really fair to compare an open source project that desperately wants only $60k a year to hire a dev with companies that have collectively raised over billions of dollars in funding?
I think it’s very fair. Anubis generated a lot of buzz in tech communities like this one, and developers pushed it to production without taking a serious look at what it’s doing on their server. It’s a very flawed piece of software that doesn’t even do a good job at the task it’s meant for (don’t forget that it doesn’t touch any request without “Mozilla” in the UA). If some security criticism gets people to uninstall it, good.
I'd say it's probably worse in terms of scope. The audience for some AI-powered documentation platform will ultimately be fairly small (mostly corporations).
Anubis is promoting itself as a sort of Cloudflare-esque service to mitigate AI scraping. They also aren't just an open source project relying on gracious donations, there's a paid whitelabel version of the project.
If anything, Anubis probably should be held to a higher standard, given many more vulnerable people (as in, vulnerable against having XSS on their site cause significant issues with having to fish their site out of spam filters and/or bandwidth exhaustion hitting their wallet) are reliant on it compared to big corporations. Same reason that a bug in some random GitHub project somewhere probably has an impact of near zero, but a critical security bug in nginx means that there's shit on the fan. When you write software that has a massive audience, you're going to have to be held to higher standards (if not legally, at least socially).
Not that Anubis' handling of this seems to be bad or anything; both XSS attacks were mitigated, but "won't somebody think of the poor FOSS project" isn't really the right answer here.
I don't think it's fair to hold them to the same, or higher standard. at all this is literally a project being maintained by one individual. I'm sure if they were given $5 million in seed money they could probably provide 1000x value for the industry writ large if they could hire a dedicated team for the product like all those other companies with 100,000x the budget.
How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.
That's a bit simplistic.
If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year? What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them?
So you're putting pressure on a person who is a researcher, not a producer. Which is wrong.
And also there's the scale. Sure, here you have one guy who exploited a vulnerability. But how long it took them to get there? There's probably dozens of vulnerabilities yet to be exploited, requiring skills that differ so much from the ones used by this person that they won't find them. Even if you pay them for a full-time position.
Whereas, if you set up a bug bounty program, you are basically crowdsourcing your vulnerabilities: not only you probably have thousands of people actively trying to exploit vulnerabilities in your system, but also, you only give money to the ones that do manage to exploit one. You're only paying on result.
Obviously, if the reward is not big enough, they could be tempted to sell them to someone else or use them themselves. But the risk is here no matter how you decide to handle this topic.
They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them
I directionally agree with you but we could go another 20 comments deep on exactly what the purpose of an external pentest or red-team exercise is and how it might not match up perfectly with what an amateur web hacker is currently doing. But like: yeah, they could get into that business, at least until AI eats it.
Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)
There are a lot of ways to monetize a security researcher. Publishing research, even "we failed to perform a full exploit", is a huge recruitment tool and brand awareness tool.
It's not quite that simple. I don't think most bug bounty participants want a full-time job. But even more-so in my experience they are not security generalists. You can hire one person who is good at finding obscure XSS vulns, another that's good at exploiting cloud privilege escalation in IAM role definitions, another that's good at shell or archive exploits. If you look at profiles on H1 you'll see most good hackers specialize in specific types of findings.
Having been adjacent to this for years, it's because it's a cost center and not attached to the bonus of any product or program manager. Every now and then we'll get an advocate for security/integrity at a company but the effort lives and leaves with them.
Microsoft, after getting beat up over this for decades, is still horrible at it. In my area they're have been enforced regulations for years but they're written by the industry itself and infected with compliance managers and thus result in wastes of effort that makes compliance managers that came over from HR and legal happy with their eternal job security and minimal hard work.
Until some heavy handed top down regulation, written by people who understand the nature of ongoing security and software and embedded lifecycles, it's going to stay like this. Most existing supply chain regulation I've seen ends up saying "vet your vendors" and gives minimal practical guidance of how to actually do that. Likelihood of some really good law coming out of the current US administration and business climate is left as a comedy for the reader.
I wonder if this analogy could work: if some random visitor pointed out your storage room's key is nearly broken and anybody could come in now and steal your store's stock. You'd be thankful, but would you hire them to come from time to time to check if they have any other insight ? Probably not ?
If you really saw a recurring security risk you'd have many other better use of your money.
While I would love that for the kid I dont think these companies care about security at all.
I think that's unfair to say about a company that pays bug bounties at all.
A lot of other companies would have ignored the email for weeks or threatened legal action.
Nice discovery and writeup. Let alone for a 16 yo!.
I've never heard an XSS vulnerability described as a supply-chain attack before though, usually that one is reserved for package managers malicious scripts or companies putting backdoors in hardware.
I think that's misuse of the term as well, but like you said they are only 16.
I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows).
As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the trust model (the browser's origin model) seems to indicate all is fine (like the signing on the binary). But because earlier in the supply chain they made a mistake, you are now at risk. Its basically moving an XSS up a level into the "supply chain".
Given this (including the linked writeup on the mintlify RCE), after the React RCE, if think it should be pretty obvious that
1. content security policies should always be used to prevent such scripts (here they would prevent execution of scripts from the SVG)
2. The JavaScript ecosystem should be making ` --disallow-code-generation-from-strings` a default recommendation when running NodeJS on the server.
Vercel (and other nodejs as a service providers) should warn customers that don't use CSP and `--disallow-code-generation-from-strings` that their settings should be improved.
There are a bunch of other NodeJS flags that maybe you should look into too: https://sgued.fr/blog/react-rce/#node-js-mitigations
Their collaborator's report includes a more significant issue, an RCE on a mintlify server: https://kibty.town/blog/mintlify/
Proxying from the "hot" domain (with user credentials) to a third party service is always going to be an awful idea. Why not just CNAME Mintlify to dev-docs.discord.com or something?
This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.
I run a product similar to Mintlify.
We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them.
The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is.
I wish Mintlify the best here – it's stressful to let customers down like this.
What makes you say that Google claims it's not true? Google claims subdomains are completely two different domains and you'll lose all the linking/page rank stuff according to their own docs regarding SEO. Some SEO gurus claim it's not so black and white but no one knows for sure. The data does show having docs on subdomain is more harmful to your SEO if you get linked to then a lot.
Here's the argument for/against it: https://www.searchenginejournal.com/ranking-factors/subdomai...
I think the answer likely is quite nuanced, for what it's worth.
To my knowledge it's not as much hurting the parent domain as having two separate "worlds". Your docs which are likely to receive higher traffic will stop contributing any SEO juice to your main website.
Yep - this is the core issue that made the vulnerability so bad. And if you use a subdomain for a third-party service, make sure your main app auth cookies are scoped to host-only. Better yet, use a completely different domain like you would for user-generated content (e.g. discorddocs.com).
I think the reason companies do this for doc sites is so they can substitute your real credentials into code snippets with "YOUR_API_KEY". Seems like a poor tradeoff given the security downside.
This is a great example of why a Content-Security-Policy (CSP Header) should be considered mandatory for high risk sites. With it you can effectively tell the browser what JS is allowed to run, meaning that any JS injected via XSS won't work.
I suspect Coinbase and others already use CSP.
https://en.wikipedia.org/wiki/Content_Security_Policy
Everything is Swiss cheese. Let's just go back to paper and pen and one time pads.
Ok, I’m never opening an svg ever again.
Found by a 16 year old, what a legend.
Open it with a browser running inside a jail.
I tried that and they wouldn't let me bring my laptop in
Damn, this is a good era to be in high school (or university) with a lot of free time. $4000 is a pretty good haul for a few hours of work poking at stuff.
I've been following the rise of SVG based attacks recently... It's not just hypothetical anymore... People are using SVG files to deliver full phishing pages and drive by downloads by hiding JavaScript in the markup
ALSO as someone who maintains a file upload pipeline I run every SVG through a sanitizer... Tools like DOMPurify remove scripts and enforce a safe subset of the spec... I even go as far as rasterizing user uploaded vectors to PNG when possible
HOWEVER the bigger issue is mental... Most folks treat SVG like a dumb image when browsers treat it like executable content... Until the platform changes that expectation there will always be an attack surface
Mintlify does look pretty, but between that and all the React exploits, I'll stick with good ol' static sites.
Kinda why I built ReallySimpleDocs [1]. Add Pages CMS [2] to it and you're set.
[1]: https://reallysimpledocs.com/
[2]: https://pagescms.org
decided to make a new account to post:
Mintlify security is the worse I have even encountered in a modern SaaS company.
They will leak your data, code, assets, etc. They will know they did this. You will tell them, they will acknowledge that they knew it happened, and didn't tell you.
Your docs site will go down, and you will need to page their engineers to tell them its down. This will be a surprise to them.
Absolute self-promotion: https://github.com/hunvreus/reallysimpledocs
Yes, they were sloppy with GitHub credentials and their response was inadequate. Glad we migrated away from them.
Slightly related, as someone who doesn’t engage in this type of work, I’m curious about the potential risks associated with discovering, testing, and searching for security bugs. While it’s undoubtedly positive that this individual ultimately became a responsible person and disclosed the information, what if they hadn’t? Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good? Has there been cases where the risk involved wasn’t justified by the relatively low $4k reward? Or any specific companies you wouldn’t want to do this with because of a past incident with them?
If you engage in “white hat security research” on organisations who haven’t agreed to it (such as by offering roles of engagement on a site like hacker one) there is indeed a risk.
For example they might send the police to your door, who’ll tell you you’ve violated some 1980s computer security law.
I know 99.99% of cybercrime goes unpunished, but that’s because the attackers are hard to identify, and in distant foreign lands. As a white hat you’re identifiable and maybe in the same country, meaning it’s much easier to prosecute you.
> Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good?
Companies will create bug bounty programs where they set ground rules (like no social engineering), and have guides on how to identify yourself as an ethical hacker, for example:
https://discord.com/security
There are laws governing these scenarios. It's different everywhere. Portugal just updated theirs in favor of security researchers: https://www.bleepingcomputer.com/news/security/portugal-upda...
Not shocked given the following statement from Mintlify to a recruiter a few months ago:
"I'd rather hire a junior dev who knows the latest version of NextJS than a senior dev who is experienced with an earlier version."
This would be a forgivable remark, except the recruiter was aware of the shortsightedness, and likely attempted to coach the hiring manager...
You're much more charitable than I am. I would not call that forgivable.
$11k in bounties. Might have got more from the onion.
Stupid, especially because he is a kid and young in his career. His lifetime earnings and ability to score a better paying job is worth way more than an extra couple thousand dollars selling this kind of exploit to criminals. It's why NDA's for security vulnerabilities are harmful because it doesn't allow a kind of social credit accumulation
Back in the day the US government would give you $20k-60k cash in a nice briefcase for this type of exploit. Just another thing big tech has ruined I suppose.
Apple gave me $47k back when I was 16 and it definitely changed my life. Was subsequently able to get out of my 3rd world country and pay for university in the UK. While the quality of education is disappointing, having a graduate visa makes it so much easier to get a job or start a business there.
No not to individuals. There are absolutely contracts you can score for certain attack surfaces but that usually involves going through a company. If this person is from the united states, they will absolutely land themselves a good scholarship and a very well-paid job with a security clearance.
Can you cite a source for that claim? The USG paying mid-5-figures for an XSS vulnerability? That's news to me.
The book "This Is How They Tell Me the World Ends" by Nicole Perlroth, while it's about the history of cyberweapons it does a very good job detailing the late 90s to early 2010s exploit market.
I don't have it in front of me, but I'm talking about the "nobody but us" era of exploit markets:
https://en.wikipedia.org/wiki/NOBUS
Where the NSA seemingly was buying anything, even if not worthwhile, as a form of "munitions collection" to be used for the future attacks.
edit: this mostly ended in the US because other nations started paying more, add in more regulations (only a handful companies are allowed to sell these exploits internationally) and software companies starting to do basic security practices (along with ruling out their own bug bounties), it just mostly whimpered away.
Also relevant to the discussion, the book discusses how the public exploit markets are exploitive to the workers themselves (low payouts when state actors would pay more) and there are periods of times where there would be open revolts too (see 2009 "No More Free Bugs" movement, also discussed in the book).
Definitely worth it if you aren't aware of this history, I wasn't.
I haven't read her book, am myself somewhat read in to the background here, and if she's claiming NSA was stockpiling serverside web bugs, I do not believe her.
In reality, intelligence agencies today don't even really stockpile mobile platform RCE. The economics and logistics are counterintuitive. Most of the money is made on the "backend", in support/update costs, paid in tranches; CNE vendors have to work hard to keep up with the platforms even when their bugs aren't getting burned. We interviewed Mark Dowd about this last year for the SCW podcast.
Maybe there is a misunderstanding, I'm not saying that the NSA would be buying XSS scripts. I'm saying that if this was 35 years ago the NSA would be buying exploits with common user software. Back then the exploits were "lesser" but there still was a market and not every exploit that was bought was a wonder of software engineering. Nowadays the targeted market is the web and getting exploits on some of the most used sites would be worthy of buying.
Kid was simply born in the wrong era to cash out easy money.
I think you're wrong about this. 35 years ago was 1990. Nobody was selling vulnerabilities in 1990 at all. By 1995, I was belting out memory corruption RCEs (it was a lot easier then), and there was no market for them at all. And there has never been a market for web vulnerabilities like XSS.
Building reliable exploits is very difficult today, but the sums a reliable exploit on a mainstream mobile platform garner are also very high. Arguably, today is the best time to be doing that kind of work, if you have the talent.
I can't imagine intelligence agencies/DoD not doing this with their gargantuan black budgets, if it's relevant to a specific target. They already contract with private research centers to develop exploits, and it's not like they're gonna run short on cash
If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not.
The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used, which is not how e.g. a mobile browser drive-by works.
Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary
Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?
Seems like none of these major websites detected anything, and they are supposed to be top-notch in the world.
It's only because the researcher contacted them.
Also because nobody actively exploited them! You're using the word "detected" to mean "discovered", which nobody working in the field would ever do.
detected: WAF caught or detected the attack and raised an alert, post-exploitation
discovered: they audited or pentested themself and found out, preemptively
I just mean that Coinbase didn’t see anything happening and didn’t take action though the boy successfully exploited the vulnerability on their live system.
$11k for the three of them in total! That's just bad PR.
It’s clear to me now that I need to set up my home machine the way I set up BYOD when I was contracting last. I need a separate account for all of my development.
I have a friend who at one point had five monitors and 2 computers (actually it might be 3) on his desk and maybe he’s the one doing it right. He keeps his personal stuff and his programming/work stuff completely separate.
I have three OS installs. Windows install for games. Another Windows for development (I have to for windows dev). And a Ubuntu install for anything not games/work. The windows drives use bitlocker and they can't access each other's files. It's not perfect.
Although with the amount of crap I have to install for windows development I'm starting to wonder if a base VM image that is used as a start point for each project would be cleaner.
16 year olds rule the world.
I run an infosec firm and we have done attacks like this on my clients over and over and over in audits. I always say any bored teen could do most of what we do because most companies are moving too fast feature farming to have any time for responsible security hardening, and now I have yet another great citation.
Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work. Finding bugs in the wild as this researcher did often gets wildly underpaid relative to the potential impact of the bug, if they pay or take it seriously at all.
These companies should be ashamed paying out so little for this, and it is only a matter of time before they insult the wrong researcher who decides to pursue paths to maximum profit, or maximum damage, with a vuln like this.
> Unfortunately a competitive rate agreed to in advance with a company before we do any pentesting is the only way we have ever been able to get paid fairly for this sort of work.
So, rough estimate, how much would you have made for this?
We normally find things like this in our usual 60 hour audit blocks. Rates change over time with demand, but today an audit of that length would be $27k.
Even that is quite cheap compared to letting a blackhat find this.
If I can ask on business model, as I have a friend with a similar predicament — what percent of the time do you find vulnerabilities in those audits? Do companies push back if you don't find vulnerabilities?
We have never issued a clean report in our ~5 years of operation.
Some firms have a reputation for issuing clean reports that look good to bosses and customers, but we prefer working with clients that want an honest assessment of attack surface and how motivated blackhats will end their business.
We also stick around on retainer for firms that want security engineering consulting after audits to close the gaps we find and re-architect as needed. Unused retainer hours go into producing a lot of open source software to accelerate fixing the problems we see most often. This really incentivizes us to produce comprehensive reports that take into account how the software is developed and used in the real world.
Under our published threat model few companies pass level one, and we have helped a couple get close to level 2 with post audit consulting.
Our industry has a very long way to go as current industry standard practices are wildly dangerous and make life easy for blackhats.
https://distrust.co/threatmodel.html
As someone in a related line of work: we find vulnerabilities so close to 100% of the time that it might as well be 100% of the time. Whether they're practically exploitable or surpass your risk appetite is the real question.
These companies almost always produce "vulnerabilities", but they're also almost always trash.
"Finding: This dependency is vulnerable to CVE-X, update it, severity S". And then of course that dependency is only used during development, the vulnerable code isn't called, and they didn't bother to dig into that.
"Finding: Server allows TLS version 1.1, while it's recommended to only support version 1.2+", yeah, sure, I'm sure that if someone has broken TLS 1.1, they're coming for me, not for the banks, google, governments, apple, etc, everyone else still using TLS 1.1
... So yeah, all the audits will have "findings", they'll mostly be total garbage, and they'll charge you for it. If you're competent, you aren't going to get an RCE or XSS out of a security audit since it simply will not be there.
at this point I feel like it'd be useful for web server default configurations to include something like
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.Sounds like you pwned Mintlify!
Okay, seriously, can we just get one, just ONE document/image spec that doesn't let you embed scripts or remote content? What is with this constant need to put the same exactly vulnerability into EVERYTHING?! Just let me have a spec for completely static documents, jfc!
One of these days I'm gonna have to learn why cross-site scripting even matters, especially with modern browsers restricting a script's access to anything local
The attacker can do anything using your session.
The "Hello world" examples always show using it to steal your cookies, which obviously doesn't work now when nearly every site uses the "httpOnly" flag which makes the cookie inaccessible to JavaScript, but really, stealing your session isn't necessary. They just have to make the XSS payload run the necessary JavaScript.
Once the JavaScript is running on the page, all bets are off. They can do ANYTHING that the page can do, because now they can make HTTP requests on your behalf. SOP no longer applies. CSRF no longer protects you. The attacker has full control of your account, and all the requests will appear to come from YOUR browser.
It's a good question and one mature orgs ask themselves all the time. As you can see from most of the replies here, XSS captures the fancy of the bug bounty crowd because there are tonnes of hypothetical impacts so everyone is free to let their imagination run wild when arguing with triagers. It's also the exploit nonpareil for nerdsnipers because sanitisation is always changing and people get to spend their days coming up with increasingly ridiculous payloads to bypass them. In reality, find me one active threat actor who has compromised a business lately with an XSS. It's not an irrelevant risk, but the attention it gets is wildly disproportionate to its real-world impact.
If I can run my own code but in your context, I can pull in malicious scripts.
With those (all these are "possible" but not always, as usual, it depends, and random off the top of my head):
- I can redirect you to sites I control where I may be able to capture your login credentials.
- May be able to prompt and get you to download malware or virus payloads and run them locally.
- Can deface the site you are on, either leading to reputational harm for that brand, or leading you to think you're doing one thing when you're actually doing another.
- I may be able to exfiltrate your cookies and auth tokens for that site and potentially act as you.
- I might be able to pivot to other connected sites that use that site's authentication.
- I can prompt, as the site, for escalated access, and you may grant it because you trust that site, thereby potentially gaining access to your machine (it's not that the browsers fully restrict local access, they just require permission).
- Other social engineering attacks, trying to trick you into doing something that grants me more access, information, etc.
You log in to goodsite.com
goodsite.com loads a script from user-generated-content-size.com/evil.js
evil.js reads and writes all your goodsite.com account data.
could `Sec-Fetch-Dest: image` mitigate this?
Cool. Makes me want to get into that — checking out sites for vulnerabilities. Very impressive for a 16 year old. Should definitely have been paid more.
fascinating! but this is not a supply-chain attack unless i'm misunderstanding
It kinda is no? Discord uses mintlyfly. Minitlifly was vulnerable. And because they got access to mintlifly, discord was now also attackable
that’s just a vulnerability in a dependency. a supply-chain attack is introducing malicious code in a dependency
The linked site https://heartbreak.ing/ explains that Mintlify disabled CORS, so that 3rd party sites can run code in your Mintlify-using environment (X, Vercel, etc).
The OP site says that .svg files can only run scripts if they are directly opened, not via <img> tags.
So how does the attack work?
My understanding, the SVGs were imported directly and embedded as code, not as a `src` for an img tag. This is very common, it's a subjectively better (albeit with good security practices) way to render SVGs as it provides the ability to adjust and style them via CSS as they are now just another element in the HTML DOM. It should only be done with "trusted" SVGs however!
As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.
Thanks, that makes sense. Strange that the writeup skipped the most important step in the vulnerability!
Move fast and break things?
I have this feeling with almost all web tools I am required to use nowadays.
No trust.
Move fast and break _other people's things._
JFC bug bounty money is pathetic now. This would have destroyed this company's reputation, downstream effects for customer reputations and data.
I struggle to understand the issue .. could someone help me out ?
Ok, you got "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma..." to send a controlled payload
But regular users will never hit "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma...", so they will never execute your script
I fail to understand how this can be exploited, by whom and in what conditions
You're pretty much on the money. Reflected XSS requires social engineering to really target anyone without other primitives. Unfortunately this report is not very clear about the tangible impacts or limitations of what they could do with this particular XSS either. Saying that every Mintlify customer was "vulnerable to account takeover with a single malicious link" strikes me as specious to say the least. Still, can't fault kids for getting excited about recognition and a payout.
imo, the impact is pretty clear here. an unsuspecting user clicks (or is redirected) to one of these malicious links on the platform (ex. vercel); the script grabs their cookie and credentials and sends it to the attacker. they now have full access to the victim's account.
Nice! So the Cookie is accessible by JavaScript on all of those sites? That would be pretty surprising given the prevalence of HttpOnly, so that doesn't seem clear to me at all. And they're all using Cookie-based auth, you think? You're a bug bounty hunter so I'll defer to your wisdom, but doesn't it seem more likely that an account takeover would be possible via a state-changing request from the user's existing session? Let's say they can abuse it to reset the user's password. Nice, that's an account takeover... for every user not using MFA. But then there are anti-CSRF mitigations. Okay, not insurmountable with an XSS, but implemented differently everywhere. And what if the auth domains are separate to the domain on which the XSS is triggered? Man this seems to get less clear by the minute. Please clear this up for me.
XSS is a RCE exploit. It allows you to run any action as if you were the owner of the account. How is that not a full account takeover?
XSS is categorically not an RCE and my point is that mitigations exist which make "It allows you to run any action as if you were the owner of the account" an unwarranted assumption. The writeup shows that it's possible to pop an alert box. That doesn't tell you anything about what's actually possible. Obviously Discord got enough information to take it seriously, but extrapolating that to suggest every third-party using Mintlify is vulnerable to account takeover is highly dubious based on what's presented.
Well, llmslave2 is right. If discord.com executes javascript to conduct user actions, and you can execute javascript on discord.com, you are acting on the account as if you were discord.com
Except discord.com doesn't execute JavaScript, the user's browser does. These are meaningful distinctions that delineate the impact. You aren't "discord.com" if you target someone with an XSS exploit, you've only run a script in a user's session. Whether you can actually do anything with that script or not decides whether you can take over the account or not.
Yes, I agree, it’s a cool discovery though
Everybody knows that XSS is a client side exploit, you're acting naive by pretending like we're claiming it gives access to a server and ignoring the fact that having control of the client gives you de facto control of whatever account is logged into the client.
It is not as cool as the RPC exploit of React/Next.js where you could call any function on the server-side including “vm.sysexec” or whatever it was, but still not to be fully ignored
How is XSS not remote code execution? You can do anything, from send fetch requests to the server with full credentials to loggging keystrokes or even open a tunnel and eval payloads...
Anything the user can do, you can do via an XSS attack.
Show me where you can "open a tunnel" using the XSS in this post.
> Anything the user can do, you can do via an XSS attack.
I just explained why this isn't a reasonable assumption. You seem to have multiple fundamental misunderstandings about web application security so I don't think it's constructive for either of us to continue this conversation.
> Show me where you can "open a tunnel" using the XSS in this post.
> You seem to have multiple fundamental misunderstandings about web application securityLol yeah sure buddy
Go to Discord and paste that into your console. None of us will hold it against you if you come back and delete these comments once you learn about Content Security Policy.
the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.
Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.
You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).
> the auth token is stored in local storage
Has anyone reported this (rhetorical question)? What in the world could be the justification for this?
In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.
And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.
It's hosted on the official domain. That means you have at least 2 options: a) chain in with another issue which allows to load that as a trusted resource, or b) scam people by directing them to an "official" post. Also you get discord cookies access.
You have control over what displays on a page with a discord.com domain, you could manipulate the dom to have a login or something else and have it pass the data to your servers. A user would just see a link from discord.com
Yeah, this one must be socially engineered-- but a (fake) login page when accessing a docs site would fool most people.
Thankfully the browser prevents sending the cookies cross origin or else this is just a single click exploit.
Edit: I gave too much credit to Discord here. They aren't protecting their tokens correctly.
You can also just be logged-in on Discord web, so everything is accessible too
You could send that link to an unsuspecting user and steal their cookies, make API requests to send messages on their behalf, etc
Apparently one of the other linked posts shows how you can also gain RCE, since the docs are statically pre-rendered and there’s no sandboxing to prevent you from evalling arbitrary JavaScript.
> Apparently one of the other linked posts shows how you can also gain RCE
Yep, here it is: https://kibty.town/blog/mintlify/
Also linked in his guide (which I missed) and [here in a separate HN post](https://news.ycombinator.com/item?id=46317546). I think this other author's post is a lot more detailed and arguably more useful to folks reading on HN.
if you click on the link because it has discord.com in the domain the script in the SVG can (maybe) get your session data. Not actually sure if that’s true though, I suppose it depends on how the cookies are scoped
Cool bug. Bug bounty money is pathetic.
I was going to ask. Isn't 4k from Discord pretty low for the work conducted here? I'm not familiar with bounty payouts. I'm hoping these companies aren't taking advantage of them.
4k is sadly discords highest bounty they give out (screenshot from their bugcrowd program: https://imgur.com/a/KNIdeXh) even more critical issues then this one get paid the same amount out
What is the reason for the low values? I would understand if it was a small company, but we are talking about Discord here.
Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.
That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.
What "grey market" are you talking about? How specific can you be about it?
I know you love asking people this question, so sorry to spoil your fun, but you know just as well as I do that there isn't really a "grey market".
There absolutely is. I'm just not familiar with one that buys these vulnerabilities.
Supply and demand I guess.
Pathetic for a senior SE but pretty awesome for a 16 year old up and coming hacker.
You are right, but that could (probably not) make them go for the bad route because they would get way more money that way. 4k for a bug that could take control of your customer account sounds disrespectful to me.
Yeah, my read is that the teenage hacker confronted with this ridiculous payslip sees two ways forward: accept the pay cut for the CV benefit of working with bug bounties, or get a bit better at hiding your ass and make them really pay.
If I were 16, I’d be thinking I just made an obscene amount of money ($4,000!) messing with computers for fun, and got to meet people at a famous company.
That’s a free car. Free computer. Uber eats for months.
And my status with my peers as a hacker would be cemented.
I get that bounty amounts are low vs SE salary, but that’s not at all how my 16yo self would see it.
When I was sixteen I was already familiar with the concept of leverage. I’m not sure if I’d have had the cajones to use it though.
Playing devils advocate but 4k is probably more money than most kids that age have seen in their life
I hope I'm not assuming too much but I'm really hope the up and coming hacker is smart enough to know that his work was worth more than $4,000. That's 1-2% of an annual SE salary for someone with similar skillset.
> That's 1-2% of an annual SE salary for someone with similar skillset.
I agree $4,000 is way too low, but a $400k salary is really high, especially for security work.
And this will help them land that six figure job
I mean, as a hiring manager, a fresh grad with multiple bug bounties tells me a lot about their drive and skill, so I'd agree. It's a great differentiator.