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!
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.
It's got nothing to do with DLLs or libraries or anything like that. This is a bug in their domain code. This is a simple, and bloody stupid, multi-tenant bug in a SaaS where they're not checking the tenant id before serving tenant content. Coupled with exploiting same domain cookies. Both of these have been problems that we have dealt with, and been vigilant against in SaaS apps. We had a lot of these type of attacks in the 00s when people first started deploying SaaSes and for a while we were all vigilant. The common vector for cookies back then was you'd have your main app "acmeforce.com" and you'd host customers under sub-domains like "arasaka.acmeforce.com" and cookie shenanigans would allow all sorts of attack vectors against the root site (I think github had one at one point, might be wrong!).
It's more that browser changes have allowed us to forget cookie problems, in a good way. And software developers seem to have a memory of a goldfish. The browsers have tried to build in all sort of protections against these attacks, but they only work against different domains, so we hit all the same problems as soon as some inexperienced developers starts making a multi-tenant app without proper testing.
That's "San Francisco Bay Area" for anyone else wondering
Is this synonymous with AI-assisted coding now??
The person above implies as much. Doesn't mean anyone else thinks it
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”
Sometimes titles are inaccurate
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.
I do occasionally wonder how different things would be if JavaScript had come with a very robust standard library from early on.
The crazy thing is that today the JavaScript standard library is very robust, and yet the culture of pulling in a ton of dependencies persists. It's so much easier to develop code against a stable and secure platform, yet it seems the choice is often to pull in hundreds of bits of code maintained by many different parties (instead of doing a little more in-house).
I also wonder about it recently. Also in regards to Rust which is hailed as the great savior but has the same, minimal, approach to standard library and needs loads of dependencies.
No, I wish people would let this meme die.
Rust doesn't have a very broad stdlib, but it has an extremely deep stdlib. Rust's stdlib is huge for the things it provides. Classical JS's stdlib was neither deep nor broad.
Furthermore, tons of those "loads of dependencies" that people point to are crates provided by the Rust project itself. Crates like serde, regex, etc aren't third-party dependencies, they're first-party dependencies just like the stdlib.
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
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.
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
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.
And you open another can of worms which is phishing. If you run your marketing campaigns from yourcompany-deals-2025.com don't be surprised when people click yourcompany-login.com links
I'm not sure I understand.
edit: That is, your phishing approach would work regardless, in my opinion. If your main site is `mycompany.com` then don't be surprised to see phishers sending `my-company.com` etc.
Also, you can host our content on a separate domain while still having users visit the same domain.
Trust doesn’t though - discord.com/docs looks legit, as does docs.discord.com - discord-docs.com immediately sets off red flags
You can use a sandboxed iframe without an origin.
You can still have discord.com/docs with content hosted on discord-docs.com
But then you have to be able to trust that the other domain is actually operated by Discord and isn't some social engineering front.
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:
Search indexing, etc.
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?
It would be better if they were sanitized by design and could not contain scripts and CSS. For interactive pictures, one could simply use HTML with inline SVG and scripts.
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.
Yes. Much better to handle all untrusted data safely rather than try to transform untrusted data into trusted data.
I found this page a helpful summary of ways to prevent SVG XSS: https://digi.ninja/blog/svg_xss.php
Notably, the sanitization option is risky because one sanitizer's definition of "safe" might not actually be "safe" for all clients and usages.
Plus as soon as you start sanitizing data entered by users, you risk accidentally sanitizing out legitimate customer data (Say you are making a DropBox-like fileshare and a customer's workflow relies on embedding scripts in an SVG file to e.g. make interactive self-contained graphics. Maybe not a great idea, but that is for the customer to decide, and a sanitization script would lose user data. Consider for example that GitHub does not sanitize JavaScript out of HTML files in git repositories.)
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.
I should have clarified `svgo + removeScripts`
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.
It's no different from links to googlesyndication in offline html docs.
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.
How does it do I/O?
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.
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 ...
IIUC, an untrusted inline SVG is bad. An image tag pointing to an SVG is not.
<img src="untrusted.svg"> <!-- this is ok -->
<svg from untrusted src> <!-- this is not ok -->
Also remember that if the untrusted SVG file is served from the same origin and is missing a `Content-Disposition: attachment` header (or a CSP that disables scripts), an attacker could upload a malicious SVG and send the SVG URL to an unsuspecting user with pretty bad consequences.
That SVG can then do things like history.replaceState() and include <foreignObject> with HTML to change the URL shown to the user away from the SVG source and show any web UI it would like.
how is that special/different from an HTML URL?
Because displaying user-submitted images is pretty common and doesn't feel like a security footgun, but displaying user-submitted HTML is less common (and will raise more careful security scrutiny).
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?
It's definitely a possible solution if you control how the file are displayed. In my case I preferred the files to be safe regardless of the mechanism used to view them (less risk of misconfiguration).
Content-Security-Policy: default-src 'none'
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.
> But you can use an `img` tag (`<img src="evil.svg">`) and that'll basically Just Work
That doesn't help too much if evil.svg is hosted on the same domain (with default "Content-Type: image/svg+xml" header), because attacker can send a direct link to the file.
Reddit horribly breaks direct links to images and serves html instead.
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.
> It's a class of problem that raster image formats basically don't have.
That took way too long to be this way. Some old browsers couldn't even get the colors of PNGs correct, let alone the transparency.
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.
They are reasonably consistent because there is a de-facto reference implementation (Adobe Acrobat) which, if your implementation does not match exactly, users will think your implementation is broken.
There isn't such an implementation for SVG.
We live in a world where Adobe set the standard, and anything that didn't render like Adobe was considered "incorrect".
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.
Also text zoom.
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.
Even PDFs don't always render the same from one platform to another. I've mostly seen it due to missing fonts.
Most renderers don't implement the full spec.
Yeah, I spent a bit of time trying to figure out some masking issues with a file I created in Inkscape but which chrome would butcher. Turned out to be opacity on a mask layer or something.
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.
But how else would we revisit all the security bugs of Flash/Macromedia?
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.
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.
(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.
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.
what is missing was a replacement for the flash editor itself, not the format.
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 think it depends on whether you see Flash as competing with webvideo or with downloadable executables.
SVG without <script> would do just fine.
SVG also supports event attributes, so you should probably strip those too.
What we got was html for vector graphics and what we wanted was jpeg for vector graphics.
Wikipedia, which allows uploading media, deals with this by rendering svgs on the server side.
Yeah, it's still insane to me that the SVG can contain scripts. Wholly unnecessary; the DOM subtree it defines could be manipulated by external scripts just fine.
Anyway, I just set `svg.disabled` in Firefox. Scary world out there.
Update: this breaks quite a few things. It seems legitimate SVGs are used more often for UI icons than random diagrams and such. I suppose I shouldn't be surprised. I'll have to rethink this.
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.
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.
> This makes a no-brainer "don't run these ever" option in the browser seem appealing.
Firefox has this: svg.disabled in about:config. It doesn't seem to be properly documented, and might cause other problems for the developer (I found it accidentally, and a more deliberate search turns up mainly bug tracker entries.)
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?
User name checks out.
I believe the username is from the AI simulation of HN in 10 years.
> 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?
I agree, when animating SVGs I never put the js inside them so having the ability embed it is just dangerious I think
Wow, I learned one thing today!
Do other vector formats have the same vulnerabilities?
"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.
So if you're directly embedding the thing. This is a somewhat rare use case, should not be banned almost anywhere...
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.
Use the PDF to JPG online services, convenient and you still get your result without having to deal with any sandbox
Better a DJVU file generated at a high DPI.
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.
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!
Nobody is buying anything on "Zerodium".
Right, but Eva found an RCE and only got $5,000.
An RCE in what? Nobody's buying your Discord RCE.
>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.
Seems fair. XSS is a confused deputy attack, a type of vulnerability known since the 1980s. That we keep reinventing it in every new medium is frankly embarassing.
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.
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!)
I completely agree!
But hiring a pentest firm is completely different than giving $50k a year to a guy, no questions asked.
The pentest firm is generally providing the whole package, from doing the actual pentest, with tools and workers of various experience and skill sets, giving you extended reports on what they did and the outcome, to providing guidance on how to fix their findings, how to make the necessary cultural changes to harden your apps, and also how to communicate that you have passed their audit.
You won't have all of that if you give free roam to a guy to _do what they do_.
This idea is more similar to patronage, which, imho, is a great idea, no matter the domain (arts or tech), but I doubt that there any company here that is willing to go this way.
Even the company that supposedly do actual patronage today are going to look at their ROI and stop as soon as they don't see the figures they're expecting.
Don't get me wrong, I'm not saying it's dumb to think about retaining a talented teenager on a contract.
> 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!
Why bitter? Did they miss some?
Otherwise, isn't that the goal to begin with? Shouldn't you be proud instead?
Every pentest misses stuff. That's kind of the point I'm making. But yeah: as someone with a software security background, when you contract a test, you want them to find stuff!
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.
So now they found a vulnerability, the company should pay them $50k a year until they retire because they proved themselves competent?
Yes?
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.
I doubt it.
Just because he found one vulnerability at one vendor used by Discord doesn't mean he'll find all the vulnerabilities that exist at Discord or indeed any of them.
TFA:
>Discord is one of my favorite places to hunt for vulnerabilities since I'm very familiar with their API and platform. I'm at the top of their bug bounty leaderboard having reported nearly 100 vulnerabilities over the last few years. After you've gone through every feature at least 10 times, it gets boring.
That doesn't specify how many bugs there existed in the Discord codebase throughout the time where this person was active. Only once you know that, can you say whether they found a significant proportion relative to the effort they've spent and would spend as a part-time employee. That other people still find things also suggests that the statement above ("just hire him and you're secure") might have been a bit simplistic
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 feel like the "I'm a 16 year old high school senior" thing is some kind of social engineering- his knowledge seems a bit too broad.
But who knows.
There are plenty of competent 16 year olds.
I just read a story about a 13-year-old awarded a Ph. D at a prestigious university.
Human intelligence/aptitude has such extreme distributions it's almost unthinkable.
Who knows indeed.
It's easier than ever to pretend you know more than you do on the internet these days..
Not saying that's the case here, but that's the world we live in now.
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.
Apple hired George Hotz (geohot) after he wrote the old 2010s iOS jailbreaks.
It wouldn't surprise me if he's in this thread - curious what his thoughts would be.
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.
Its cheaper to pay bug bounties than to hire a security expert or legal costs
just wanted to disagree with anyone who thinks someone like this needs to go to school
no, he needs to make his own agency
[dead]
Their collaborator's report includes a more significant issue, an RCE on a mintlify server: https://kibty.town/blog/mintlify/
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".
A supply chain attack attacks the supply chain
This makes use of a vulnerability in a dependency. If they had recommended, suggested, or pushed this purposefully vulnerable code to the dependency, then waited for a downstream (such as Discord) to pull the update and run the vulnerable code, then they would have completed a supply chain attack
The whole title is bait. Nobody would have heard of the dependency, so they don't even mention it, just call it "a supply chain" and drop four big other names that you have heard of to make it sexy. One of them was actually involved that I can tell from the post, that one is somewhat defensible. They might as well have written in the title that they've hacked the pentagon, if someone in there uses X and X had this vulnerable dependency, without X or the pentagon ever being contacted or involved or attacked
It does attack the supply chain. It attacks the provider of documentation. It's an attack on the documentation supply chain.
It would be like if you could provide a Windows Update link that went to Windows Update, but you could specify Windows Update to retrieve files from some other share that the malicious actor had control of. It's the same thing, except rather than it being a binary rather it is documentation.
I think that's misuse of the term as well, but like you said they are only 16.
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
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.
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.
Yes, they were sloppy with GitHub credentials and their response was inadequate. Glad we migrated away from them.
where did you migrate away to?
Absolute self-promotion: https://github.com/hunvreus/reallysimpledocs
Astro’s starlight docs generator/template is quite nice as well: https://starlight.astro.build/
Interesting timing — we captured downstream exploitation of this exact attack surface.
38 days after @hackermondev's disclosure, our automated OSINT harvester pulled 121 IOCs from OpenPhish/OTX:
- 101 URLs for discord.flawing.top/blog/* (mimicking Discord's documentation structure)
- 20 URLs for openopenbox301.vercel.app (phishing hosted ON Vercel)
The attackers read the same disclosures we do. They just build infrastructure instead of writing reports.
Evidence (queryable):
curl "https://analytics.dugganusa.com/api/v1/search?q=discord.flawing.top"
Full writeup with IOCs: https://www.dugganusa.com/post/mintlify-xss-downstream-exploitation-captured
STIX feed (free): https://analytics.dugganusa.com/api/v1/stix-feedOk, 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
Alright, I chuckled.
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:
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.
It isn't, they have so much knowledge experience and foresight that has a significant gap in many ways.
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
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!
A lesson from this is that you shouldn't host third-party stuff in your own domain. Instead of placing it on docs.discord.com, place it on discord-docs.com.
$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.
Can you cite a source for that claim? The USG paying mid-5-figures for an XSS vulnerability? That's news to me.
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.
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.
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.
$11k for the three of them in total! That's just bad PR.
at this point I feel like it'd be useful for web server default configurations to include something like
if extension == .svg
set-header Content-Security-Policy: script-src 'none'
end
Not a bad idea!
>AI-powered documentation platform. You write your documentation as markdown and Mintlify turns it into a beautiful documentation platform
Why do you need AI for this? Aren't there tons of packages which do very similar things without AI?
For that matter, why do you need SaaS for this? Aren't there tons of simple locally runnable solutions, including SSGs?
Well if they don't do SOMETHING with AI for their documentation how are they going to put it on their resumes?
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
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.
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.
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.
At Distrust we do not comment on specific dependency CVEs unless they are likely exploitable, or there are a lot of them pointing at bigger problems in the overall approach to dependency management.
That said, a policy of blindly updating dependencies to patch irrelevant CVEs is itself, a very real security vulnerability, because pulling in millions of lines of code no one reviews from the internet regularly makes you an easy target for supply chain attacks.
We have pulled off supply chain attacks on our clients a few times who were not otherwise convinced they were a real threat.
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 set up a separate user that I ssh into for development. Not perfect but its something.
I really don't get the appeal to have everything om one top-level domain, especially completely separate or even external services. The scope of this would've been basically zero if they just put it on docs.discord.com.
Especially something like this, where they were reverse proxying a SaaS, seems extra stupid. It's more work to set up, adds an unnecessary dependency between services and you end up paying for all the internet traffic three times (even if not directly).
Sounds like you pwned Mintlify!
I critiqued the title elsewhere already so let me say here that the screenshot does show code running in Discord's browser context. They didn't send it to an employee and actually pwn the company, as one might understand from the title, but it doesn't strictly say that and I would count finding XSS as close enough. Saying they've pwned Discord, I think is fair enough
The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost
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 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.
Yes, it's generally a "full account takeover" for a given discord user.
But RCE usually means ability to run any code on the web server, and would generally get you access to _everything_ including full direct access to the database. All accounts and all data, not just a few accounts.
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.
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.
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
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
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 how language shifts. Supply chain attacks are broadly seen as a scary new thing, so like with any such term, people try to shoehorn things they find into its meaning. Those who fall for and repeat it shift the language. The same happened to the word 0day: it used to mean "a vulnerability that you specifically haven't had a chance to patch because it has been known to the world for 0 days". A scary thing. Now it's commonly used as synonym for the word vulnerability
I wonder if every vulnerability is soon called a supply chain attack:
- Microsoft releases a Windows security update -> Discord uses Windows -> supply chain attack on Discord
- User didn't install security updates for a while -> brought their phone to work -> phone with microphone sits in pocket in meeting room -> supply chain attack
Everything has dependencies that can be vulnerable, that doesn't mean "the supply chain" was attacked in a targeted effort by some attacker
that’s just a vulnerability in a dependency. a supply-chain attack is introducing malicious code in a dependency
Btw, apart from Discord, you really should stop using the other ones (X, Vercel, Cursor...). Do yourself and the planet a favour :)
Stop using Discord as well - their software is packed full of data mining, ads, and cosmetic upsells. For public community groups use a forum site (then it’s indexable as well!), and for private groups use something actually private like Signal
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!
It is clear that SVG should not support scripts and CSS in SVG files. Those who need them can simply create HTML with inline SVG tags and scripts. And SVG should contain only shapes, effects and transformations.
Or maybe we need a new image format, "SVG without scripts and CSS".
CSS and scripts are wildly different. It's like responding to the old MS Office attacks with "Word without macros or font selection"
The problem with CSS is that if you want to write an SVG viewer, you have to implement a whole CSS engine, which might be more complex than SVG renderer itself. And if you create an image in an editor, like Inkscape, you don't use CSS anyway. CSS is meant to be used when you write the code manually (instead of using an editor), for example, in a web app, and in this case you could use HTML as well.
So yes, CSS is not needed.
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._
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.
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.
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.
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.
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.
They have more security incidents than you'd expect for a documentation company. There was another one just last month.
The collected bounty on this should have been so much higher than $14K :/
Everything is Swiss cheese. Let's just go back to paper and pen and one time pads.
> If you didn't know, you can embed JavaScript into an SVG file.
Oh yikes. I did not know.
16 year olds rule the world.
Who ever invented the idea that you can embed Javasript to picture files?
this was very well-written and the moving parts were quite easy to understand.
simultaneously there are many opportunities throughout to harden one's app to avoid similar exploits.
Really nice finding for such a young folk - really liked reading into it.Also what i love most about it is what an actually simple vuln it is.
Tho what i find mostly funny bout it is how many people are complaining about the 4k$.
I mean sure the potential "damage" could have been alot higher, tho at the same time there was no contract in place or , at least as far as i understood, a clear bug bounty targeted. This was a, even if well done, random checking of XHR/Requests to see if anything vulnerable can be found - searching for kinda file exposure / xss / RFI/LFI. So everything paid (and especially since this is a mintlify bug not an actual discord bug) is just a nice net gain.
Also ill just drop here : ask yourself, are you searching for such vulns just for money or to make the net a safer place for everyone. Sure getting some bucks for the work is nice, but i personally just hope stuff gets fixed on report.
- enormously awesome
- that bug bounty was insufficient (Fidelity?!?!)
every commit in every open source project should now go through an AI to see if it can detect anything nefarious. I'm sure there are ways to fool it but it makes it a lot easier for bad actors to get caught.
Link here is to gist , but on lobste.rs some one posted link to Eva's blog. And it with links to friends blogs, feel so much like old internet. I dont even know what I enjoyed more, reading technical side or discovering this dark forest.
could `Sec-Fetch-Dest: image` mitigate this?
[dead]
[dead]
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.
In an ideal world, these bugs, especially low-hanging fruits, shouldn't be discoverable by some random kids. These billion dollar companies should have their own security researchers constantly monitoring their stack. But those costs are cut, because the law de facto doesn't hold them liable for getting hacked. It's a very good deal for companies to pay bug bounties, but they mostly cheap out on that, too.
It's like a finders reward elsewhere in life. If you lost your wallet, your immaterial and material loss is quite high, but apart from cash the contents are of way less value for a finder/thief. These type of rewards are meant to manipulate emotions and motivation. Twitter paid these kids each between $1 and $20. That's insulting. As I said elsewhere, bug bounties are PR. And it's bad PR in this case. Black market pricing is the absolute low end for valuation (it's basically the cash value in the wallet example).
Not sure what risk but for me it would be morals
I've rarely gotten bug bounty money and not even always a written thank-you but it doesn't cross my mind to somehow seek out a malicious actor that wants to make use of what I found. Leave the place better than you found it and all that
What "grey market" are you talking about? How specific can you be about it?
There absolutely is. I'm just not familiar with one that buys these vulnerabilities.
> Selling via grey markets is an option, but many white hats don't go that route due to risk.
I would think that such a sale makes one inherently not "white hat".
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.
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.
> That's 1-2% of an annual SE salary for someone with similar skillset.
So commensurate for approximately 2 days of work, a little high for two hours of work, and a little low for 8 days of 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.
market value is the same regardless, so this was pathetic
What do you expect? a16z-funded and they love to talk about how much they've raised, thought-leader style co-founders, etc.
JFC bug bounty money is pathetic now. This would have destroyed this company's reputation, downstream effects for customer reputations and data.
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).
Yep, httpOnly cookies just give the hacker a bit of extra work in some situations. TBH I don't even think httpOnly is worth the hassle it creates for platform developers given how little security it adds.
Wow did not realize a url could be set like that without promoting a page reload...
Even scarier to me than the vulnerability is that Fidelity (whom I personally think is a good bank and investment company) was using a third party that allowed injection that could potentially steal a whole lot of money, affect markets, ruin or terminate billions of lives, and affect the course of humanity. What the fuck.
If it weren't already in the same domain you wouldn't be able to read a non-HttpOnly cookie anyway, so that's moot.
Well that's how SPAs work (single page applications)
How do you modify the url exactly?
https://developer.mozilla.org/en-US/docs/Web/API/History/pus...
For Coinbase docs, this is a disaster particularly
No because Discord auth tokens dont expire soon enough. The only thing that kills them is changing your password. Idk why Discord doesnt invalidate them after some time, it is seriously amateur hour over there and has been for a while.
Probably because the end user hates login in, my friends always complain about the “remember me” button being useless for some services.
No, these are tokens that you get a new one per request, if you open up dev tools, and open the user settings panel, you will see that you get a new one every single time you open the user settings panel. They never expire, at least for years they were insanely long lasting.
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
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
Discord puts the authentication token in local storage
Is that a problem on its own? It's like, encrypted right? Maybe a time sensitive token?
Does anyone actually encrypt the contents of JWTs? I'd have thought that anyone who has concerns about the contents of the token being easily visible would be likely to avoid JWTs anyway and just use completely opaque tokens?
Depends on the token; JWTs usually have payloads that are only base64 encoded. As well, if there's a refresh token in there it can be used to generate more tokens until invalidated (assuming invalidation is built in).
You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
As a FE dev, I wouldn't be able to articulate what you just did in the way you did, but it is something I know in practice, just from experience. I don't think any of the FE courses I took tackled anything like that.
Token stealing hasn't been a real danger for a decade now. If you don't mark your token's as non-HTTP you're doing something explicitely wrong, because 99% of backends nowadays do this for you.
with http-only they can't _steal_ the cookie, but they can still _use_ the cookie. It reduces the impact but doesn't fully solve it.
Surely, if a script is in a position to sniff the cookie from local storage, they can also indirectly use the http-only cookie by making a request from the browser. So really not much of a difference as they will be taking over the account
The cookie storage and the local storage by all means is not the same! Cookies are not stored in the local storage and could be httpOnly, so they are not directly accessible by JavaScript. Nevertheless, as described above, with this XSS attack it is easy to bypass the token and just steal the user credentials by pretending a fresh login mask keeping the origin domain intact. That's why XSS attacks are dangerous since existence. Nothing new actually.
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.
>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.
I was once only given $1,000 for an exploit where I could put in npm usernames and get their email addresses. Big corps don't always pay what they should.
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.
>i quickly realised that this was the server-side serverless (lol) environment of their main documentation app, while this calls to a external api to do everything, we have the token it calls it with in the env.
>alongside, we can poison the nextjs cache for everyone for any site, allowing mass xss, defacing, etc on any docs site.
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.
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.
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.
Hey I was wrong about Apple downthread.
> - 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).
tokens are stored in localStorage, which is accessible by JS
Well, it used to be much more accessible before, now you have to do some hack to retrieve it, and by hack, I mean some "window.webpackChunkdiscord_app.push" kinda hack, no longer your usual retrieval. Basically you have to get the token from webpack. The localStorage one does not seem to work anymore. That is what I used, but now it does not work (or rather, not always). The webpack one seems to be reliably good.
So your code goes like:
and localStorage does fail often now. I knew the reason for that (something about them removing it at some point when you load the website?) so you need the webpack way, which is consistently reliable.I believe if you search for the snippet above, you can find the code for the webpack way.
Yeah, that is what I have observed, too.
You can retrieve it the webpack way though.