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.

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.

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.

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 -->

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...

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?

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.

But how else would we revisit all the security bugs of Flash/Macromedia?

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.

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.

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.)

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

is santizing SVGs hard, or just everyone forgets they can contain js?

Do other vector formats have the same vulnerabilities?

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">)."

There is: PDF. You may not like it or adobe, but its there and widely supported.

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, ...

> 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 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.

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

I'm curious what caching architecture a docs site needs, it can't be more complicated than a standard fare CDN?

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.

>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...

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.

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.

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.

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 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".

I think that's misuse of the term as well, but like you said they are only 16.

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.

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.

Open it with a browser running inside a jail.

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...

Yes, they were sloppy with GitHub credentials and their response was inadequate. Glad we migrated away from them.

Absolute self-promotion: https://github.com/hunvreus/reallysimpledocs

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

CSS and scripts are wildly different. It's like responding to the old MS Office attacks with "Word without macros or font selection"

You're much more charitable than I am. I would not call that forgivable.

Not a bad idea!

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

$11k for the three of them in total! That's just bad PR.

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.

> 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?

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

It kinda is no? Discord uses mintlyfly. Minitlifly was vulnerable. And because they got access to mintlifly, discord was now also attackable

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.

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.

Move fast and break _other people's things._

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.

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.

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.

What do you expect? a16z-funded and they love to talk about how much they've raised, thought-leader style co-founders, etc.

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 I guess.

Pathetic for a senior SE but pretty awesome for a 16 year old up and coming hacker.