How to report a bug or vulnerability
... we (currently) have no bug bounty program ... send an email to support@mullvadvpn.net
https://mullvad.net/en/help/how-report-bug-or-vulnerability / https://archive.vn/BeHhr How to report a bug or vulnerability
... we (currently) have no bug bounty program ... send an email to support@mullvadvpn.net
https://mullvad.net/en/help/how-report-bug-or-vulnerability / https://archive.vn/BeHhrAmerican culture is highly varied. For some this is true, for others this is wrong and highly insulting.
Maybe try a narrower brush next time.
Amazingly brazen assumption right there.
Maybe not everything is aimed towards you, especially if you don't feel like the description actually matches you :)
What's your point again? Something about all Americans whether they live in the US or not? Are you trying to be incoherent? Daft? Representative of all Swedes by origin?
Since when do you have professionals giving you examinations out of common courtesy? Out of courtesy can I get a free cancer screening?
But that would never happen, so the point is moot.
Maybe when they decide on their own volition, without any external pressure, to go and poke around your system?
"Hey, I'm a mechanic, I was looking at your car parked out there and noticed something incredibly dangerous that needs immediate fixing. I'll tell you what it is for $1,000."
Please...
Seems to be a systemic issue with computer guys feeling entitled to financial compensation for strange reasons. See also, people licensing their software as "open source" and then being mad when people make money off it.
The mechanic writes a blog post about how the locks on [a car model] don't work, and how anyone could just steal [cars], but doesn't tell the [car company] because, after all, the [company] wasn't paying him to.
Especially, when the car company spends on 'certifications' (security audits, in this case) and specifically markets it as a differentiator. That said, uncoordinated public disclosures in cybersecurity are bad form, given the well-established existing norms & culture; but at least, let's get analogies right.But yes, if you found a general fault in the locks of a certain car model and publicized it without first informing the company and giving them a fair chance to inform the affected customers, people would probably be annoyed with you. Individuals even, not just companies.
"You chose that car that advertises good locks. Guess what, the locks are actually bad and now I'm gonna publish exactly how, to teach the manufacturer a lesson about paying me money".
Time and time again private companies have rug pulled things like api access for 3rd party apps (such as twitter/X). Building 3rd party clients for private systems should already be approached with heavy scepticism and always be prepared for the worst.
Notify, then publish
This is the best VPN regarding security and privacy there is.
I did my research
Someone with likely substantial qualifications put in time to find this. The company is in it for profit (at least partially). What’s fair for the company is fair for the individual. The company can either offer to pay for bugs under the terms they want, hire more security folks to find the bugs themselves, or just accept that researches get to do whatever they want with their findings.
I’d tell Mullvad, but there are companies I don’t respect enough to feel compelled to give them a heads up. Perhaps the author feels that way about Mullvad, it’s entirely within their right to use this to publicly shame Mullvad.
Those who do bug bounties full-time ignore programs with no rewards. Those who want to gain experience or pad their resume can submit reports to programs with no rewards because they are not as competitive as those with rewards.
Another issue that is often talked about is the size of the bounty. Most are small <$10K so for users in developed countries, it's not sustainable to go full-time. https://www.theregister.com/security/2019/01/15/want-to-get-...
The whole bug bounty thing is a mess, admittedly, but lacking a bug bounty program entirely feels like immediately losing the moral high ground on “you should have told us first”. There’s a lively debate about what bugs are worth, but it’s objectively not $0 for many classes because a botnet developer will buy them for some amount.
Personally, a big part of my view is formed by the educated assumption that security practices will never improve unless poor security becomes a liability. That’s unlikely to happen with “responsible disclosure” because it gets swept under a rug. Immediate public disclosure changes that risk calculus a lot. I think wed see a lot more downward pressure from vendors to their suppliers if $RandomSaaS had to worry about losing their pants because Oracle had a vuln published.
The way your argument reads to me is “software as a category has such little utility that profit margins can only be derived from corner cutting”.
The reality of the landscape is that most companies don’t get hacked as the result of an incredible and novel Spectre-esque attack, it’s something bland and entirely preventable.
Eg https://nvd.nist.gov/vuln/detail/CVE-2025-31324
SAP got a CVE because they just flat out didn’t implement auth on an endpoint in an app architecture that will execute files just for being in a certain directory, and also didn’t prevent writing files to executable paths (or maybe that’s how the feature works, not a SAP person). For every 0 day with a novel root, there are like a thousand that are some kind of humdrum “didn’t enforce auth/SQL sanitation/XSS/other well known exploit with comprehensive solutions”.
I do think there are good reasons to withhold some classes of exploit. If a hacker writes a 14 page proof on how to beat some encryption we had no idea was vulnerable, that’s one thing. Getting owned for making an insecure architecture and then not even putting auth over it is a whole other issue.
I think it's mostly ship product faster > secure product first that leads to such insecure architecture. Ideally, security should be incorporated early in the software development life cycle but most start-ups rarely hire a security guy in the initial phases. https://www.reddit.com/r/indianstartups/comments/1r6zwbg/why... They expect the software devs to have that knowledge. But security hardening is a skill that takes time to develop so most devs just focus on feature development.
Even for well-established companies, most security teams are not given top priority. ->https://www.reddit.com/r/ITManagers/comments/1qwnywo/devs_ig... ->https://www.reddit.com/r/cybersecurity/comments/wjypns/does_... ->https://www.reddit.com/r/cybersecurity/comments/1fjnl9j/fed_...
Will immediate public disclosures change the mindset of top leadership regarding security? For some, yes but most will not change because breaches have become too common. They reason if top tech firms like Microsoft or GitHub can suffer breaches and come out on the other side unscathed, they too can survive a major security incident.
If so, I guess we just have different opinions on the ethics involved here.
But when it comes to money making corporations then personally I dont agree that revealing flaws in their product comes into ethics at all.
A companies paid product is flawed, their own paid engineers didnt figure that out, why should I do it for free becasue 'ethics'?
This is the entire reason bug bounty programs exist in the first place.
For me, it’s more subtle than that.
Everybody (“almost all software”) has exploitable bugs. Are you a fool for not finding the ones in yours? Maybe. Sometimes.
There is a huge difference between Project Zero finding a trivial vulnerability almost identical to one reported months earlier (close to negligence) and Mullvad having the CEO personally posting a response here in a very calm tone.
If I have a company which sells a paid product, and my paid engineers do not find bugs then I absolutely do not expect the public to willfully and freely make my product better for me. This is why I would have a bug bounty program as an incentive for the public to help me makle my product better and more secure, like any other company serious about finding security bugs.
If I didnt have a bug bounty program and found out that some black hats were selling backdoors to my system online, I would consider that fully my fault for not incentivizing those hackers against doing so.
It should always be assumed that someone else (if not several someone elses) have already discovered the same flaw and are currently taking advantage of it while users remain totally unaware of their actual risk. By going public immediately, you give as many of those users as possible a chance to protect themselves.
Waiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up.
That's not what they said though. They said "please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away" (emphasis mine)
The priority should be on protecting users, and not helping the company responsible for the vulnerability save face, or give them extra time to spin up their PR team, or get a head start on a patch.
When the risk to users is low, or when there's really nothing users can do to protect themselves anyway I'd agree with you. In a case like this where the risk to users can be extremely high, and the moment they are made aware of the problem there are steps the user can take to eliminate that risk, the safety of those users should outweigh inconvenience to the people responsible for the vulnerability
Mullvad fucked up. They should been as inconvenienced as thru possibly could be too fix the problem promptly! The issue is irresponsible disclosure hurts more users than it helps.
It's not as if the odds of new would-be exploiters seeing it are any better. It helps that the people who are at the most risk tend to have their ear to the ground already because they know what's at stake.
When the risks are this high you have to assume that it's already being actively exploited. That means that already there are more attackers who know about the vulnerability than there are users who know about the mitigation.
All you can do at that point is let as many users as possible know how to protect themselves while Mullvad figures out how to fix the issue on their end, writes and puts out the update, and the remaining users get around to updating their systems. You can't save everyone, but hopefully you at least gave some people the chance to save themselves.
The flipside of course is ... does your disclosure increase the risk?
> aiting to disclose something harmful when the users in danger could otherwise take steps to make themselves safe would be like not warning people entering a building not to go in because of a gas leak until after you've contacted the building owner and the fire department has shown up
I don't think it's like this at all. The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred. To stretch your analogy, I'd say its more like you've found the gas leak and instead of turning off the gas supply are instead running around outside the building shouting about how there's a gas leak.
When you've got that much on the line you have to assume that the risk is already present for all users. It's true that there's always a chance that some users won't find your disclosure in time and additional would-be attackers who weren't aware of it already will start taking advantage of the flaw, but the alternative is that no users are safe.
> The risk of a gas leak is not increased by telling people about it and can't be prevented after its occurred.
It's true that warning people not to enter wouldn't make the gas more dangerous, but it limits the death count of the impending explosion. It keeps at least some people from entering the building and walking into a death trap.
There's no way to shut off the gas supply when you can't control what's already running on user's devices and more users are downloading and installing the buggy code all the time. It's really not a perfect analogy. The point is that immediate action will save some people, while waiting around means that nobody has a chance of being saved.
why are companies so entitled to get free security research/audits?
As for our support team they are responsive and experienced. Several of them have worked with us for many years and do offensive security research in their free time.
Unlike many organisations we don't see customer support as a cost center, just like we don't see security as a cost center. Our support team represent our customers, and as a consequence contribute a lot to how we prioritise our roadmap.
I second this.
Clearly the person who wrote "Oof" has never emailed Mullvad support.
Whenever I have emailed Mullvad support I have received a prompt reply from a human being who clearly actually cares about taking ownership of the question and seeing it through to resolution.
I have also witnessed first-hand the support person taking the question to an internal team member where it requires additional input. So there are clear paths for escalation if circumstances require it.
Finally the support mail allows for PGP encryption of communications too.
(I am not a Mullvad shill. Not a Mullvad employee. Just a satisfied customer)
"Just email support@" feels like you don't care. That you do, and that your support team is awesome, doesn't change the fact that there are other companies out there who's aren't. Security people are human with human egos, and they want to feel special, so giving them a special way to reach you, even if it's the same thing behind the scene, makes a world of difference.
I'm not familiar with how you run your company -- without the context you gave most people would hesitate emailing support@ for security issues.
Do you have people whose role is explicitly security? Who are the security SMEs in your organization if not? I personally find the "Security is so important to us that we don't have a team dedicated to it" argument weak, and often results in misaligned incentives - if individuals have to alternate hats from "deliver results" to "properly vet security", the business push to deliver tends to win out. I'd be very curious to hear how you ensure your team doesn't fall into that trap.