5/15/2026 at 7:39:50 AM
I work at Mullvad. (co-CEO, co-founder)Some aspects of the described behavior are as we intended and some are not. The cause is not exactly as described in the blog post. As for mitigation, we are already testing a patch of the unintended behavior on a subset of our infrastructure. If any of you try to reproduce the blog post's findings you may get confusing results throughout the day.
We will also re-evaluate whether the intended behaviors are acceptable or not. Some of this is a trade-off between multiple aspects of privacy, and multiple aspects of user experience.
Please note that this is my current understanding, which may change. I was only made aware of this an hour ago, and most of that time was spent talking with Ops, considering what to do immediately, and writing this post.
Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings, even if you intend to publish right away.
by kfreds
5/15/2026 at 8:08:54 AM
You really do provide a reassuring, good service -- thank you.It's also worth stating that the client (including the cli client -- which, with a bit of work, you can get running in most situations where you'd use native wireguard) by default has a key rotation interval of I think 72 hours.
`mullvad tunnel get` will show it and `mullvad tunnel set rotation-interval <hours>` will change it. This is the preferred mitigation method of the post.
I personally don't mind having a pseudo-static IP (some other suppliers offer a static IPv4 as a feature!) as I wish to prevent network-level snooping from my ISP and governments. It's also worth stating that I think having a smaller IP space is an advantage for a privacy VPN: there are more potential users acting behind any given externally visible IP. Combined with technologies like DAITA (which effectively adds chaff to the tunnel) and multi-hop entrances and I personally think that this service really does plausibly make harder the life of those who snoop netflows all day.
by azalemeth
5/15/2026 at 11:10:07 AM
Can we have an Open Suse client.Sorta odd you don't support one of Europe's most popular distros.
by 999900000999
5/15/2026 at 8:50:52 AM
I just want to say I absolutely love Mullvad! You guys did a fantastic job at designing a genuinely good and trustworthy (as much as possible) VPN vendor. You communicating here is just another data point towards this.by lionkor
5/15/2026 at 7:59:07 AM
> Finally, for those of you who do security research: when you find a security or privacy issue, please consider notifying the maintainer/vendor before publishing your findings 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
by ignoramous
5/15/2026 at 9:07:48 AM
Not having a bug bounty or dedicated email address does not make it OK to go public immediatelyby dust-jacket
5/15/2026 at 10:17:54 AM
Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediately. That said, by all means notify the maintainer/vendor as well.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.
by autoexec
5/15/2026 at 10:33:24 AM
> Discovering a bug that could put people's lives and/or freedom at risk if they don't do something about it makes it okay to go public immediatelyThe 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.
by dust-jacket
5/15/2026 at 10:48:44 AM
> The flipside of course is ... does your disclosure increase the risk?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.
by autoexec
5/15/2026 at 10:21:07 AM
> Expecting people to hold off on disclosure of something harmfulThat'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)
by hmry
5/15/2026 at 10:25:52 AM
I do think hitting "send" on the email to the responsible party immediately before publishing (or at least notifying them as quickly as you can afterwards) is a smart thing to do. I mean, why wouldn't you? My concern was more about the "Not having a bug bounty or dedicated email address does not make it OK to go public immediately" comment. It can sometimes be difficult to track down the right person to notify and so when the risks to people are high enough whichever one you can accomplish the soonest is probably where I'd start.by autoexec
5/15/2026 at 11:00:05 AM
Oh yeah fair enoughby hmry
5/15/2026 at 10:53:49 AM
if they don't think it's OK, then they should have a bug bounty program.why are companies so entitled to get free security research/audits?
by r_lee
5/15/2026 at 9:56:26 AM
Yes it does actually.by mvdtnz
5/15/2026 at 10:27:44 AM
I don't feel like its hard to come up with examples where (I would say) its ethically wrong to disclose immediately. If you spotted a company's mistake that might endanger their user's lives or safety, would you put those users at risk simply because there was no obvious financial reward?If so, I guess we just have different opinions on the ethics involved here.
by dust-jacket
5/15/2026 at 8:10:26 AM
To support? Oof.by wren6991
5/15/2026 at 8:33:55 AM
I'm not sure what you mean by "Oof". We don't have a dedicated security team because security and privacy are integral to all aspects of our service. It doesn't make sense to centralise it.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.
by kfreds
5/15/2026 at 9:24:01 AM
> I'm not sure what you mean by "Oof".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)
by traceroute66
5/15/2026 at 9:37:53 AM
It still probably makes sense to alias it to security@mullvadvpn.net for privacy/security concerns.I'm not familiar with how you run your company -- without the context you gave most people would hesitate emailing support@ for security issues.
by nananana9
5/15/2026 at 9:32:30 AM
Human psychology is weird and some things are just cultural. If you have the ops team make the security@ email alias just forward to support, you could avoid having to go into all that."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.
by fragmede