We pwned X, Vercel, Cursor, and Discord through a supply-chain attack
gist.github.com
gist.github.com
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!
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.
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).
XSS is a big problem. If a hacker can inject a script into your front end and make it execute, it's game over. Once they get to that point, there's an infinite number of things they can do. They basically own the user's account.
Terrifying.
And serves a reminder crime does pay.
In the black market, it would have been worth a bit more.
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.
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.
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.
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
Discord uses HttpOnly cookies (except for the cookie consent banner).
So your code goes like:
// Try localStorage first
const token = getLocalStorageItem('token')
if (token) return token
// Try webpack if localStorage fails
const webpackToken = await getTokenFromWebpack()
if (webpackToken) return webpackToken
I believe if you search for the snippet above, you can find the code for the webpack way.
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.
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.
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.
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.
But in the age of AI, it seems like chasing the popular thing takes precedence to good practices.
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 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.
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.
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.)
1: https://owasp.org/www-community/vulnerabilities/XML_External...
Whoever decided it should be enabled by default should be put into some sort of cybersecurity jail.
<img src="untrusted.svg"> <!-- this is ok -->
<svg from untrusted src> <!-- this is not ok -->
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.
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.
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.
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.
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.
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.
It’s so regular like clockwork that it has to be a nation state doing this to us.
(Yes I'm still salty about Flash.)
That wasn't the only reason. Flash was also proprietary, and opaque, and single-vendor, among many other problems with it.
No, Flash was terrible and killing it was good.
Anyway, I just set `svg.disabled` in Firefox. Scary world out there.
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.
Didn’t we do this already with Flash? Why would this lesson not have stuck?
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.
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.
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...
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.
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.
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.
Why bitter? Did they miss some?
Otherwise, isn't that the goal to begin with? Shouldn't you be proud instead?
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.
>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.
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.
But who knows.
Human intelligence/aptitude has such extreme distributions it's almost unthinkable.
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.
If you really saw a recurring security risk you'd have many other better use of your money.
It wouldn't surprise me if he's in this thread - curious what his thoughts would be.
A lot of other companies would have ignored the email for weeks or threatened legal action.
no, he needs to make his own agency
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.
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".
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 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.
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
This is also why an `app.` or even better `tenant.` subdomain is always a good idea; it limits the blast radius of mistakes like this.
We've made different product decisions than them. We don't support this, nor do we request access to codebases for Git sync. Both are security issues waiting to happen, no matter how much customers want them.
The reason people want it, though, is for SEO: whether it's true or outdated voodoo, almost everyone believes having their documentation on a subdomain hurts the parent domain. Google says it's not true, SEO experts say it is.
I wish Mintlify the best here – it's stressful to let customers down like this.
I think the answer likely is quite nuanced, for what it's worth.
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.
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-feedFound by a 16 year old, what a legend.
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.
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:
"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...
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 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?
As for CORS, they were uploading the SVGs to an account of their own, but then using the vulnerabilities to pivot to other accounts.
if extension == .svg
set-header Content-Security-Policy: script-src 'none'
end
Why do you need AI for this? Aren't there tons of packages which do very similar things without AI?
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
I suspect Coinbase and others already use CSP.
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.
So, rough estimate, how much would you have made for this?
Even that is quite cheap compared to letting a blackhat find this.
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.
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.
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).
The other three companies mentioned though... yeah, they totally pwned the dependency first and foremost
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
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.
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.
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.
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
Or maybe we need a new image format, "SVG without scripts and CSS".
So yes, CSS is not needed.
I have this feeling with almost all web tools I am required to use nowadays.
No trust.
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.
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.
goodsite.com loads a script from user-generated-content-size.com/evil.js
evil.js reads and writes all your goodsite.com account data.
Oh yikes. I did not know.
simultaneously there are many opportunities throughout to harden one's app to avoid similar exploits.
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.
- that bug bounty was insufficient (Fidelity?!?!)
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
I would think that such a sale makes one inherently not "white hat".
Pathetic for a senior SE but pretty awesome for a 16 year old up and coming hacker.
I agree $4,000 is way too low, but a $400k salary is really high, especially for security work.
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.