hckrnws

This is a pretty scary exploit, considering how easily it could be abused.

Imagine just one link in a tweet, support ticket, or email: https://discord.com/_mintlify/static/evil/exploit.svg. If you click it, JavaScript runs on the discord.com origin.

Here's what could happen:

- Your Discord session cookies and token could be stolen, leading to a complete account takeover.

- read/write your developer applications & webhooks, allowing them to add or modify bots, reset secrets, and push malicious updates to millions.

- access any Discord API endpoint as you, meaning they could join or delete servers, DM friends, or even buy Nitro with your saved payment info.

- maybe even harvest OAuth tokens from sites that use "Login with Disord."

Given the potential damage, the $4,000 bounty feels like a slap in the face.

edit: just noticed how HN just turned this into a clickable link - this makes it even scarier!

Doesn't stealing the cookies/token require a non-HTTP-only session cookie or a token in localstorage? Do you know that Discord puts their secrets in one of those insecure places, or was it just a guess?

I believe if you always keep session cookies in secure, HTTP-only cookies, then you are more resilient to this attack.

I interviewed frontend devs last year and was shocked how few knew about this stuff.

In general if a script can run, users sessions and more importantly passwords are at risk.

It's true that an HTTP-only session cookie couldn't be directly taken, but it's trivial to present the user with a login screen and collect their password (and OTP), at which point you can easily get a session remotely. It can look entirely like the regular login page right down to the url path (because the script can modify that without causing a page load).

Wow did not realize a url could be set like that without promoting a page reload...

Discord puts the authentication token in local storage

You may be thinking of CSRF mitigations. XSS exploits are more dangerous and can do more than steal sessions.

if you set the cookier header right (definitely not always the case), this is true, but the javascript can still send requests that will have that cookie included, effectively still letting the hacker use the session as the logged in user

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

No it would not have been.

Could you elaborate on why not?

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.

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.

It would have been. Ten times the amount at least.

For a reflected XSS? Tell me who is paying that much for such a relatively common bug...

To elaborate, to exploit this you have to convince your target to open a specially crafted link which would look very suspect. The most realistic way to exploit would be to send a shortened link and hope they click on it, that they are logged into discord.com when they do (most people use the app), that there are no other security measures (httponly cookies) etc

No real way to use this to compromise a large amount of users without more complex means

It isn't about the commonality of the bug, but the level of access it gets you on the type or massive scale of the target. This bug you your blog? Who cares. This bug on Discord or AWS? Much more attractive and lucrative.

Yes, but this is not a particularly high access level bug.

Depending on the target, it's possible that the most damage you could do with this bug is a phishing attack where the user is presented a fake sign-in form (on a sketchy url)

I think $4k is a fair amount, I've done hackerone bounties too and we got less than that years ago for a twitter reflected xss

Why would that be the maximum damage ? This XSS is particularly dangerous because you are running your script on the same domain where the user is logged-in so you can pretty much do anything you want under his session.

In addition this is widespread. It's golden for any attacker.

How would you make money from this? Most likely via phishing. Not exactly a zero-click RCE.

What happens in all these discussions is that we stealthily transition from "selling a vulnerability" to "planning a heist", and you can tell yourself any kind of story about planning a heist.

I don't like tptacek, but it's insane to not back up this comment with any amount of evidence or at least explanation. The guy knows his shit.

Hey I was wrong about Apple downthread.

The fact that SVG files can contain scripts was a bit of a mistake. On one hand, the animations and entire interactive demos and even games in a single SVG are cool. But on the other hand, it opens up a serious can of worms of security vulnerabilities. As a result, SVG files are often banned from various image upload tools, they do not unfurl previews, and so on. If you upload an SVG to discord, it just shows the raw code; and don't even think about sharing an SVG image via Facebook Messenger, Wechat, Google Hangouts, or whatever. In 2025, raster formats remain way more accessible and easily shared than SVGs.

This is very sad because SVGs often have way smaller file size, and obviously look much better at various scales. If only there was a widely used vector format that does not have any script support and can be easily shared.

All SVGs should be properly sanitized going into a backend and out of it and when rendered on a page.

Do you allow SVGs to be uploaded anywhere on your site? This is a PSA that you're probably at risk unless you can find the few hundred lines of code doing the sanitization.

Note to Ruby on Rails developers, your active storage uploaded SVGs are not sanitized by default.

Is there SVG sanitization code which has been formally proven correct and itself free of security vulnerabilities?

GitLab has some code in their repo if you want to see how to do it.

Sanitisation is a tricky process, it can be real easy for something to slip through the cracks.

Yeah I’ve worked on a few pieces of software now that tried SVG sanitizing on uploads, got hacked, and banned the uploads.

I guess it is a matter of parsing svg. Trying to hack around with regex is asking for trouble indeed.

just run them through `svgo` and get the benefits of smaller filesizes as well

svgo is a minifier, not a sanitizer.

External entities in XML[1] were a similar issue back when everyone was using XML for everything, and parsers processed external-entities by default.

1: https://owasp.org/www-community/vulnerabilities/XML_External...

XXE should have never existed.

Whoever decided it should be enabled by default should be put into some sort of cybersecurity jail.

At least with external entities you could deny the parser an internet connection and force it to only load external documents from a cache you prepopulated and vetted. Turing completeness is a bullshit idea in document formats.

Postscript is pretty neat IMHO and it’s Turing complete. I really appreciated my raytraced page finally coming out of that poor HP laser after an hour or so.

I once sent a Sierpinski's Triangle postscript program to a shared printer. It took 90 minutes, and pissed off everybody else trying to print.

One of the very first SVG documents I encountered was a port of the PS Tiger to SVG. It loaded a lot faster than the PostScript Tiger.

PostScript can emulate the ZMachine (Zork text adventures and all of infocom) with "zmachine.ps". Look it up at DDG/GG.

Sounds almost like a fun crypto mining opportunity.

With SVGs you can serve them from a different domain. IIUC the issue from TFA was that the SVGs were served from the primary domain; had they been on a different domain, they would have not been allowed to do as much.

calling Leonard Rosenthol ...

Would it be possible for messenger apps to simply ignore <script> tags (and accept that this will break a small fraction of SVGs)? Or is that not a sufficient defense?

I looked into it for work at some point as we wanted to support SVG uploads. Stripping <script> is not enough to have an inert file. Scripts can also be attached as attributes. If you want to prevent external resources it gets more complex.

The only reliable solution would be an allowlist of safe elements and attributes, but it would quickly cause compat issues unless you spend time curating the rules. I did not find an existing lib doing it at the time, and it was too much effort to maintain it ourselves.

The solution I ended up implementing was having a sandboxed Chromium instance and communicating with it through the dev tools to load the SVG and rasterize it. This allowed uploading SVG files, but it was then served as rasterized PNGs to other users.

Shouldn't the ignoring of scripting be done at the user agent level? Maybe some kind of HTTP header to allow sites to disable scripts in SVG ala CORS?

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

IMO, the bigger problem with SVGs as an image format is that different software often renders them (very) differently! It's a class of problem that raster image formats basically don't have.

I would have expected SVGs to be like PDFs and render the same across devices. Is the issue that some renderers don’t implement the full spec, or that some implement parts incorrectly?

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.

They are like PDFs in that they do not render the same with different software or on different devices.

I would say PDFs are actually reasonably consistent though. Weird things happen on occasion, but I've certainly had more success them compared to SVGs.

We live in a world where Adobe set the standard, and anything that didn't render like Adobe was considered "incorrect".

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.

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.

Wikipedia, which allows uploading media, deals with this by rendering svgs on the server side.

I agree, when animating SVGs I never put the js inside them so having the ability embed it is just dangerious I think

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.

Do other vector formats have the same vulnerabilities?

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

I gather from the HN discussion that it's not simple to disable scripting in an SVG, in retrospect a tragically missing feature.

I guess the next step is to propose a simple "noscripting" attribute, which if present in the root of the SVG doc inhibits all scripting by conforming renderers. Then the renderer layer at runtime could also take a noscripting option, so the rendering context could force it if appropriate. Surely someone at HN is on this committee, so see what you can do!

Edit: thinking about it a little more - maybe it's best to just require noscripting as a parameter to the rendering function. Then the browsers can have a corresponding checkbox to control SVG scripting and that's it.

its common to santize html string to parse it and remove/error on script tags (and other possible vulnerabilities)

i wonder do people not do this with svgs?

User name checks out.

Wow, I learned one thing today!

"The script doesn't run unless the file is directly opened (you can't run scripts from (<img src="/image.svg">)."

It will run if its in an <object> tag.

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

PDF also has script support unfortunately.

That's apparently how 4chan got hacked a while back. They were letting users upload PDFs and were using ghostscript to generate thumbnails. From what I understand, the hackers uploaded a PDF which contained PostScript which exploited a ghostscript bug.

Yes but the primary issue was that 4chan was using over a decade old version of the library that contained a vulnerability first disclosed in 2012: https://nvd.nist.gov/vuln/detail/CVE-2012-4405

Does that mean that opening arbitrary pdfs on your laptop is unsafe?

Let me put it this way...

In one of my penetration testing training classes, in one of the lessons, we generated a malicious PDF file that would give us a shell when the victim opened it in Adobe.

Granted, it relied on a specific bug in the JavaScript engine of Adobe Reader, so unless they're using a version that's 15 years old, it wouldn't work today, but you can't be too cautious. 0-days can always exist.

Yes, opening random pdfs especially in random and old pdf viewers is not a good idea.

If you must open a possibly infected pdf, then do it in browser, pdf.js is considered mostly safe, and updated.

Use the PDF to JPG online services, convenient and you still get your result without having to deal with any sandbox

Better a DJVU file generated at a high DPI.

If only there was a widely used vector format that had script support and also decades of work on maintaining a battle-tested security layer around it with regular updates on a faster release cycle than your browser. That'd be crazy. Sure would suck if we killed it because we didn't want to bother maintaining it anymore.

(Yes I'm still salty about Flash.)

> because we didn't want to bother maintaining it anymore

That wasn't the only reason. Flash was also proprietary, and opaque, and single-vendor, among many other problems with it.

SVG without <script> would do just fine.

Uh... Flash was a genuine firehose of security flaws. I mean, yeah, they patched them. So "battle tested security layer" isn't wrong in a technical sense. But, yikes, no.

The Flash revisionism I see around here occasionally is bizarre.

No, Flash was terrible and killing it was good.

I think it depends on whether you see Flash as competing with webvideo or with downloadable executables.

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

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.

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.

I do occasionally wonder how different things would be if JavaScript had come with a very robust standard library from early on.

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”

You're preaching to the choir about the fragility of the the "dig the dependency stack all the way down to hell" paradigm. But I don't think it applies in this particular case (neither does attributing it to vibe coding, IMHO).

The component which ultimately executed the payload in the SVG was the browser, and the backend dependency stack just served it verbatim as specified by the user. This is a 1990's style XSS fuckup, not anything subtle.

The issue is everyone loves to have everything fronted by a single domain. Most of xss is because of this basic flaw. All of this could have been avoided if discord didn't run their API docs through discord.com

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.

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

Here's the other post:

https://news.ycombinator.com/item?id=46276313

Search indexing, etc.

Seems like such a tiny amount of money for a bug that can be used to completely own your customers accounts. Also not much excuse for xss these days.

This comes up on every story about bug bounties. There is in general no market at all for XSS vulnerabilities. That might be different for Twitter, Facebook, Instagram, and TikTok, because of the possibility of monetizing a single strike across a whole huge social network, and there's maybe a bank-shot argument for Discord, but you really have to do a lot of work to generate the monetization story for any of those.

The vulnerabilities that command real dollars all have half-lives, and can't be fixed with a single cluster of prod deploys by the victims.

If a $500 drone is coming for your $100M factory, the price limit for defense considerations isn't $500.

In the end, you are trying to encourage people not to fuck with your shit, instead of playing economic games. Especially with a bunch of teenagers who wouldn't even be fully criminally liable for doing something funny. $4K isn't much today, even for a teenager. Thanks to stupid AI shit like Mintlify, that's like worth 2GB of RAM or something.

It's not just compensation, it's a gesture. And really bad PR.

That's not how any of this works. A price for a vulnerability tracking the worst-case outcome of that vulnerability isn't a bounty or a market-clearing price; it's a shakedown fee. Meanwhile: the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.

> the actual market-clearing price of an XSS vulnerability is very low (in most cases, it doesn't exist at all) because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.

Could you elaborate on this? I don't fully understand the shorthand here.

I'm happy to answer questions but the only thing I could think to respond with here is just a restatement of what I said. I was terse; which part do you want me to expand on? Sorry about that!

> because there aren't existing business processes those vulnerabilities drop seamlessly into; they're all situational and time-sensitive.

what's an example of an existing business process that would make them valuable, just in theory? why do they not exist for xss vulns? why, and in what sense, are they only situational and time-sensitive?

i know you're an expert in this field. i'm not doubting the assertions just trying to understand them better. if i understand you're argument correctly, you're not doubting that the vuln found here could be damaging, only doubting that it could make money for an adversary willing to exploit it?

I can't think of a business process that accepts and monetizes pin-compatible XSS vulnerabilities.

But for RCE, there's lots of them! RCE vulnerabilities slot into CNE implants, botnets, ransomware rigs, and organized identity theft.

The key thing here is that these businesses already exist. There are already people in the market for the vulnerabilities. If you just imagine a new business driven by XSS vulnerabilities, that doesn't create customers, any more than imagining a new kind of cloud service instantly gets you funded for one.

Thank you, makes a lot of sense.

I wonder what you think of this, re: the disparity between the economics you just laid out and the "companies are such fkn misers!" comments that always arise in these threads on bounty payouts...

I've seen first hand how companies devalue investment in security -- after all, it's an insurance policy whose main beneficiaries are their customers. Sure it's also reputational insurance in theory, but what is that compared with showing more profit this quarter, or using the money for growth if you're a startup, etc. Basically, the economic incentives are to foist the risks onto your customers and gamble that a huge incident won't sink you.

I wonder if that background calculus -- which is broadly accurate, imo -- is what rankles people about the low bounty rewards, especially from companies that could afford more?

The premise that "fucking companies are misers" operate on that I don't share is that vulnerabilities are finite and that, in the general case, there's an existential cost to not identifying and fixing them. From decades of vulnerability research work, including (over the past 5 years) as a buyer rather than a seller of that work: put 2 different teams on a project, get 2 different sets of vulnerabilities, with maybe 30-50% overlap. Keep doing that; you'll keep finding stuff.

Seen through that light, bug bounty programs are engineering services, not a security control. A thing generalist developers definitely don't get about high-end bug bounty programs is that they are more about focusing internal resources than they are about generating any particular set of bugs. They're a way of prioritizing triage and hardening work, driven by external incentives.

The idea that Discord is, like, eliminating their XSS risk by bidding for XSS vulnerabilities from bounty hunters; I mean, just, obviously no, right?

A remote code execution bug in ios is valuable - it may take a long time to detect exploitation (potentially years if used carefully), and even after being discovered there is a long tail of devices that take time to update (although less so than on android, or linux run on embedded devices that can’t be updated) That’s why it’s worth millions on the black market and apple will pay you $2 million dollars for it

An XSS is much harder to exploit quietly (the server can log everything), and can be closed immediately 100% with no long tail. At the push of an update the vulnerability is now worth zero. Someone paying to purchase an XSS is probably intending to use it once (with a large blast radius) and get as much as they can from it in the time until it is closed (hours? maybe days?)

> That's not how any of this works.

Yes, evidently not.

Just because on average the intelligence agencies or ransom ware distributors wouldn't pay big bucks for XSS on Zerodium etc. doesn't mean that's setting the fair, or wise price for disclosure. Every bug bounty program is mostly PR mitigation. It's bad PR if you underpay for a disclosed vulnerability, which may have ended your business, considering the price of security audits/practices you cheaped out on. I mean, most bug bounty programs are actually paid by scope, not market price for technically comparable exploits. If you found an XSS vulnerability in an Apple service with this scope, I bet you would have been paid more than 4k.

Nobody is buying anything on "Zerodium".

I wasn't aware they are gone. It's not my game, replace with whatever shady exploit trader/market out there.

I do not in fact think you would make a lot more than $4000, or even $4000 in the first place, for an Apple XSS bug, unless it was extraordinarily situationally powerful (for instance, a first-stage for a clean, direct RCE). Bounty prices have nothing at all to do with the worst-case damage a motivated actor could cause with a vulnerability.

https://security.apple.com/bounty/categories/

The lowest tier is $5k. XSS up to $40k. I think we're talking exfiltration of dev credentials...

Nice, I hadn't seen that. Well, there you go: the absolute most you're going to make for the absolute worst-case XSS bug at the largest software firm in the world.

>Also not much excuse for xss these days.

XSS is not dead, and the web platforms mitigations (setHTML, Trusted Types) are not a panacea. CSP helps but is often configured poorly.

So, this kind of widespread XSS in a vulnerable third party component is indeed concerning.

For another example, there have been two reflected XSS vulns found in Anubis this year, putting any website that deploys it and doesn't patch at risk of JS execution on their origin.

Audit your third-party dependencies!

https://github.com/TecharoHQ/anubis/security/advisories/GHSA...

https://github.com/TecharoHQ/anubis/security/advisories/GHSA...

Is it really fair to compare an open source project that desperately wants only $60k a year to hire a dev with companies that have collectively raised over billions of dollars in funding?

I think it’s very fair. Anubis generated a lot of buzz in tech communities like this one, and developers pushed it to production without taking a serious look at what it’s doing on their server. It’s a very flawed piece of software that doesn’t even do a good job at the task it’s meant for (don’t forget that it doesn’t touch any request without “Mozilla” in the UA). If some security criticism gets people to uninstall it, good.

I'd say it's probably worse in terms of scope. The audience for some AI-powered documentation platform will ultimately be fairly small (mostly corporations).

Anubis is promoting itself as a sort of Cloudflare-esque service to mitigate AI scraping. They also aren't just an open source project relying on gracious donations, there's a paid whitelabel version of the project.

If anything, Anubis probably should be held to a higher standard, given many more vulnerable people (as in, vulnerable against having XSS on their site cause significant issues with having to fish their site out of spam filters and/or bandwidth exhaustion hitting their wallet) are reliant on it compared to big corporations. Same reason that a bug in some random GitHub project somewhere probably has an impact of near zero, but a critical security bug in nginx means that there's shit on the fan. When you write software that has a massive audience, you're going to have to be held to higher standards (if not legally, at least socially).

Not that Anubis' handling of this seems to be bad or anything; both XSS attacks were mitigated, but "won't somebody think of the poor FOSS project" isn't really the right answer here.

I don't think it's fair to hold them to the same, or higher standard. at all this is literally a project being maintained by one individual. I'm sure if they were given $5 million in seed money they could probably provide 1000x value for the industry writ large if they could hire a dedicated team for the product like all those other companies with 100,000x the budget.

How these companies don't hire kids like Daniel for pennies on the dollar and have him attack their stacks on a loop baffles me. Pay the kid $50k/yr (part time, he still needs to go to school) to constantly probe your crappy stacks. Within a year or two you'll have the most goddamn secure company on the internet - and no public vulns to embarrass you.

That's a bit simplistic.

If you sign a contract with a "hacker", then you are expecting results. Otherwise how do you decide to renew the contract next year? How do you decide to raise it next year? What if, during this contract, a vulnerability that this individual didn't found is exploited? You get rid of them?

So you're putting pressure on a person who is a researcher, not a producer. Which is wrong.

And also there's the scale. Sure, here you have one guy who exploited a vulnerability. But how long it took them to get there? There's probably dozens of vulnerabilities yet to be exploited, requiring skills that differ so much from the ones used by this person that they won't find them. Even if you pay them for a full-time position.

Whereas, if you set up a bug bounty program, you are basically crowdsourcing your vulnerabilities: not only you probably have thousands of people actively trying to exploit vulnerabilities in your system, but also, you only give money to the ones that do manage to exploit one. You're only paying on result.

Obviously, if the reward is not big enough, they could be tempted to sell them to someone else or use them themselves. But the risk is here no matter how you decide to handle this topic.

They've already proved themselves as competent. $50k a year to a billion dollar company is nothing. Even if they find 0 vulnerabilities a year it's still worth it to them

I directionally agree with you but we could go another 20 comments deep on exactly what the purpose of an external pentest or red-team exercise is and how it might not match up perfectly with what an amateur web hacker is currently doing. But like: yeah, they could get into that business, at least until AI eats it.

Just going to say here that people routinely engage pentest firms, several times annually, for roughly that sum of money, hoping but not expecting game-over vulnerabilities (and, from bitter experience as a buyer rather than a seller of those services over the last 5 years --- "no game-over vulnerabilities" is a very common outcome!)

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 wonder if this analogy could work: if some random visitor pointed out your storage room's key is nearly broken and anybody could come in now and steal your store's stock. You'd be thankful, but would you hire them to come from time to time to check if they have any other insight ? Probably not ?

If you really saw a recurring security risk you'd have many other better use of your money.

While I would love that for the kid I dont think these companies care about security at all.

I think that's unfair to say about a company that pays bug bounties at all.

A lot of other companies would have ignored the email for weeks or threatened legal action.

Nice discovery and writeup. Let alone for a 16 yo!.

I've never heard an XSS vulnerability described as a supply-chain attack before though, usually that one is reserved for package managers malicious scripts or companies putting backdoors in hardware.

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

I think you can view it as supply chain as the supply chain is about attacking resources used to infiltrate downstream (or is it upstream? I get which direction I should think this flows).

As an end user you can't really mitigate this as the attack happens in the supply chain (Mintlify) and by the time it gets to you it is basically opaque. It's like getting a signed malicious binary. It looks good to you and the trust model (the browser's origin model) seems to indicate all is fine (like the signing on the binary). But because earlier in the supply chain they made a mistake, you are now at risk. Its basically moving an XSS up a level into the "supply chain".

Their collaborator's report includes a more significant issue, an RCE on a mintlify server: https://kibty.town/blog/mintlify/

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.

Ok, I’m never opening an svg ever again.

Found by a 16 year old, what a legend.

Open it with a browser running inside a jail.

I tried that and they wouldn't let me bring my laptop in

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

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.

Slightly related, as someone who doesn’t engage in this type of work, I’m curious about the potential risks associated with discovering, testing, and searching for security bugs. While it’s undoubtedly positive that this individual ultimately became a responsible person and disclosed the information, what if they hadn’t? Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good? Has there been cases where the risk involved wasn’t justified by the relatively low $4k reward? Or any specific companies you wouldn’t want to do this with because of a past incident with them?

If you engage in “white hat security research” on organisations who haven’t agreed to it (such as by offering roles of engagement on a site like hacker one) there is indeed a risk.

For example they might send the police to your door, who’ll tell you you’ve violated some 1980s computer security law.

I know 99.99% of cybercrime goes unpunished, but that’s because the attackers are hard to identify, and in distant foreign lands. As a white hat you’re identifiable and maybe in the same country, meaning it’s much easier to prosecute you.

> Furthermore, on Discord’s side, what if they were unaware of this person and encountered someone attempting to snoop on this information, mistakenly believing them to be up to no good?

Companies will create bug bounty programs where they set ground rules (like no social engineering), and have guides on how to identify yourself as an ethical hacker, for example:

https://discord.com/security

There are laws governing these scenarios. It's different everywhere. Portugal just updated theirs in favor of security researchers: https://www.bleepingcomputer.com/news/security/portugal-upda...

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.

$11k in bounties. Might have got more from the onion.

Stupid, especially because he is a kid and young in his career. His lifetime earnings and ability to score a better paying job is worth way more than an extra couple thousand dollars selling this kind of exploit to criminals. It's why NDA's for security vulnerabilities are harmful because it doesn't allow a kind of social credit accumulation

Back in the day the US government would give you $20k-60k cash in a nice briefcase for this type of exploit. Just another thing big tech has ruined I suppose.

Apple gave me $47k back when I was 16 and it definitely changed my life. Was subsequently able to get out of my 3rd world country and pay for university in the UK. While the quality of education is disappointing, having a graduate visa makes it so much easier to get a job or start a business there.

No not to individuals. There are absolutely contracts you can score for certain attack surfaces but that usually involves going through a company. If this person is from the united states, they will absolutely land themselves a good scholarship and a very well-paid job with a security clearance.

Can you cite a source for that claim? The USG paying mid-5-figures for an XSS vulnerability? That's news to me.

The book "This Is How They Tell Me the World Ends" by Nicole Perlroth, while it's about the history of cyberweapons it does a very good job detailing the late 90s to early 2010s exploit market.

I don't have it in front of me, but I'm talking about the "nobody but us" era of exploit markets:

https://en.wikipedia.org/wiki/NOBUS

Where the NSA seemingly was buying anything, even if not worthwhile, as a form of "munitions collection" to be used for the future attacks.

edit: this mostly ended in the US because other nations started paying more, add in more regulations (only a handful companies are allowed to sell these exploits internationally) and software companies starting to do basic security practices (along with ruling out their own bug bounties), it just mostly whimpered away.

Also relevant to the discussion, the book discusses how the public exploit markets are exploitive to the workers themselves (low payouts when state actors would pay more) and there are periods of times where there would be open revolts too (see 2009 "No More Free Bugs" movement, also discussed in the book).

Definitely worth it if you aren't aware of this history, I wasn't.

I haven't read her book, am myself somewhat read in to the background here, and if she's claiming NSA was stockpiling serverside web bugs, I do not believe her.

In reality, intelligence agencies today don't even really stockpile mobile platform RCE. The economics and logistics are counterintuitive. Most of the money is made on the "backend", in support/update costs, paid in tranches; CNE vendors have to work hard to keep up with the platforms even when their bugs aren't getting burned. We interviewed Mark Dowd about this last year for the SCW podcast.

Maybe there is a misunderstanding, I'm not saying that the NSA would be buying XSS scripts. I'm saying that if this was 35 years ago the NSA would be buying exploits with common user software. Back then the exploits were "lesser" but there still was a market and not every exploit that was bought was a wonder of software engineering. Nowadays the targeted market is the web and getting exploits on some of the most used sites would be worthy of buying.

Kid was simply born in the wrong era to cash out easy money.

I think you're wrong about this. 35 years ago was 1990. Nobody was selling vulnerabilities in 1990 at all. By 1995, I was belting out memory corruption RCEs (it was a lot easier then), and there was no market for them at all. And there has never been a market for web vulnerabilities like XSS.

Building reliable exploits is very difficult today, but the sums a reliable exploit on a mainstream mobile platform garner are also very high. Arguably, today is the best time to be doing that kind of work, if you have the talent.

I can't imagine intelligence agencies/DoD not doing this with their gargantuan black budgets, if it's relevant to a specific target. They already contract with private research centers to develop exploits, and it's not like they're gonna run short on cash

If that were the case, we'd routinely see mysterious XSS exploits on social networks. The underlying bugs are almost always difficult to target! And yet we do not.

The biggest problem, again, is that the vulnerabilities disappear instantaneously when the vendors learn about them; in fact, they disappear in epsilon time once the vulnerabilities are used, which is not how e.g. a mobile browser drive-by works.

Why would YOU see a mystery XSS exploit on a social network? The idea of the DoD scoring these little exploits in a box is usually to deploy in a highly controlled and specific manner. You as a layperson is of no interest to them unless you are some kind of intelligence asset or foreign adversary

Wouldn't platforms see the supposed XSS payloads in their logs and publish analyses of them, or at the very least, announce that they happened?

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

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?

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

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.

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.

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

Sounds like you pwned Mintlify!

Okay, seriously, can we just get one, just ONE document/image spec that doesn't let you embed scripts or remote content? What is with this constant need to put the same exactly vulnerability into EVERYTHING?! Just let me have a spec for completely static documents, jfc!

Cool. Makes me want to get into that — checking out sites for vulnerabilities. Very impressive for a 16 year old. Should definitely have been paid more.

fascinating! but this is not a supply-chain attack unless i'm misunderstanding

The linked site https://heartbreak.ing/ explains that Mintlify disabled CORS, so that 3rd party sites can run code in your Mintlify-using environment (X, Vercel, etc).

The OP site says that .svg files can only run scripts if they are directly opened, not via <img> tags.

So how does the attack work?

My understanding, the SVGs were imported directly and embedded as code, not as a `src` for an img tag. This is very common, it's a subjectively better (albeit with good security practices) way to render SVGs as it provides the ability to adjust and style them via CSS as they are now just another element in the HTML DOM. It should only be done with "trusted" SVGs however!

As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.

Thanks, that makes sense. Strange that the writeup skipped the most important step in the vulnerability!

Move fast and break things?

I have this feeling with almost all web tools I am required to use nowadays.

No trust.

Move fast and break _other people's things._

JFC bug bounty money is pathetic now. This would have destroyed this company's reputation, downstream effects for customer reputations and data.

I struggle to understand the issue .. could someone help me out ?

Ok, you got "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma..." to send a controlled payload

But regular users will never hit "https://discord.com/_mintlify/_static/hackerone-a00f3c6c/lma...", so they will never execute your script

I fail to understand how this can be exploited, by whom and in what conditions

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

the impact varied by customer. in Discord's case, the auth token is stored in local storage and their docs is hosted on the primary domain; they were susceptible to a full account takeover. X's docs are on a different subdomain but we found a CSRF attack that could facilitate a full account takeover. most companies were significantly affected in one way or another.

Interesting. I agree with the other commenter about the post should've included how an account takeover was possible.

You mention one method being a cookie sent to an attacker-controlled domain, but that in itself is a vulnerability given it being incorrectly scoped (missing HTTPOnly & SameSite atleast).

> the auth token is stored in local storage

Has anyone reported this (rhetorical question)? What in the world could be the justification for this?

In my opinion, any full account takeovers due to XSS is a vulnerability, even ignoring XSS. Changing email/password/phone should require verification back to one of those methods. Or at least input of the previous password.

And to my earlier point, none of that is in the writeup here to support the enormous claims made in framing the finding. This is good work, and congratulations on the bounty. I hope you have a long career in security ahead. Obviously you communicated your findings to Discord clearly enough for them to understand the impact. I look forward to reading more research from you all in the future and I hope the technical details will accompany it.

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.

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

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.

Cool bug. Bug bounty money is pathetic.

I was going to ask. Isn't 4k from Discord pretty low for the work conducted here? I'm not familiar with bounty payouts. I'm hoping these companies aren't taking advantage of them.

4k is sadly discords highest bounty they give out (screenshot from their bugcrowd program: https://imgur.com/a/KNIdeXh) even more critical issues then this one get paid the same amount out

What is the reason for the low values? I would understand if it was a small company, but we are talking about Discord here.

Supply and demand. Selling via grey markets is an option, but many white hats don't go that route due to risk. There's plenty of people that will also find vulnerabilities without any money attached.

That's a limited view. The damage this could cause should be accounted for. People don't have to sell shit, they could fuck things up just for the fun of it. That's something to consider, especially with a bunch of teenagers. Now, these big corpos didn't take the chance to sponsor and encourage these kids early careers and make this fuck-up good PR, at least.

What "grey market" are you talking about? How specific can you be about it?

I know you love asking people this question, so sorry to spoil your fun, but you know just as well as I do that there isn't really a "grey market".

There absolutely is. I'm just not familiar with one that buys these vulnerabilities.

Supply and demand I guess.

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

You are right, but that could (probably not) make them go for the bad route because they would get way more money that way. 4k for a bug that could take control of your customer account sounds disrespectful to me.

Yeah, my read is that the teenage hacker confronted with this ridiculous payslip sees two ways forward: accept the pay cut for the CV benefit of working with bug bounties, or get a bit better at hiding your ass and make them really pay.

If I were 16, I’d be thinking I just made an obscene amount of money ($4,000!) messing with computers for fun, and got to meet people at a famous company.

That’s a free car. Free computer. Uber eats for months.

And my status with my peers as a hacker would be cemented.

I get that bounty amounts are low vs SE salary, but that’s not at all how my 16yo self would see it.

Playing devils advocate but 4k is probably more money than most kids that age have seen in their life

I hope I'm not assuming too much but I'm really hope the up and coming hacker is smart enough to know that his work was worth more than $4,000. That's 1-2% of an annual SE salary for someone with similar skillset.

> That's 1-2% of an annual SE salary for someone with similar skillset.

I agree $4,000 is way too low, but a $400k salary is really high, especially for security work.

And this will help them land that six figure job

I mean, as a hiring manager, a fresh grad with multiple bug bounties tells me a lot about their drive and skill, so I'd agree. It's a great differentiator.

[dead]