Mullvad's Exit IPs Are Fingerprinting Its Users

Earlier today, a researcher who goes by tmctmt published a short, precise post that has rattled the privacy corner of the internet.

Mullvad, long the gold standard for no-logs, anonymous-payment VPNs, assigns each WireGuard connection a stable exit IP drawn from a small pool per server (of which they have 578 for now). That much is intentional. What is not supposed to happen is that the combination of IPs you receive across different servers forms a reliable fingerprint, even if you hop locations while keeping the same key.

How the fingerprinting vector works

The mechanism is elegant in its ugliness. Mullvad’s backend uses the public key (or tunnel address) as a seed for a Rust random_range call whose first output is effectively constant for a given seed. The resulting index is then scaled to each server’s pool size. Because the same float is used before scaling, the chosen IP always lands at roughly the same percentile of its local pool. A few hundred such percentile tuples are enough to identify a key with high confidence. tmctmt’s script generated 3,650 keys and found only 284 unique combinations.

The blog post is careful not to over-claim. It is not a full de-anonymisation in the sense of linking your real-world identity to traffic. It is a persistent identifier that survives server changes within the lifetime of a single key. For anyone treating different Mullvad exits as compartmentalised identities, sockpuppet accounts, separate research sessions, or simply “new identity after I switch countries”, this breaks the assumption.

Mullvad’s response has been swift and refreshingly non-defensive. On Hacker News the co-CEO and co-founder posted within hours: some of the behaviour was intended, some was not, the root cause is not exactly as described, and a patch for the unintended part is already under test on part of the fleet:

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.

They also flagged the trade-off explicitly: stable-ish IPs improve user experience (fewer logouts from banking sites, less CAPTCHAs) but cost a slice of privacy. That honesty is rare and welcome.

Credit where it is due: the post by soft_fox_lad helped surface this for a wider audience, and rightly stressed that it represents a threat model most Mullvad users had not seriously contemplated. The suggestion that the behaviour is “borderline backdoorish”, however, is overheated. The fingerprint is real and worth fixing, but it does not indicate malice or deliberate design to undermine anonymity.

It is far more plausible as a classic case of an engineering decision that looked harmless until someone with a scripting habit and a weekend to burn looked at the output distribution. Still, this fox's post has a point: "it's happening is via a threat model almost nobody [...] has ever even considered." Do you often seen IP address

Why this matters now

Most VPN “privacy” claims stop at “we don’t log.” Mullvad has always gone further: pay in cash or Monero, no account, no persistent identifiers. The exit-IP fingerprint quietly reintroduces one. An adversary who can observe traffic to multiple Mullvad servers (or query WHOIS data via Team Cymru-style feeds) now has a cheap join key between sessions. Browser fingerprinting is higher-entropy, yes, but this one works at the network layer and survives even careful users who spoof everything else.

It is also a reminder that Rust’s rand crate, like every other PRNG, does not magically become perfectly uniform when bounds change. The first output after seeding is consistent enough to create the percentile effect. That detail alone is worth knowing if you ever roll your own randomness.

What Mullvad users should do today

1. Force key rotation. The official app defaults to rotating every 30 days (CLI every 720 hours). You can tighten that to 72 hours or simply log out and back in whenever you want a fresh set of IPs. The researcher’s own mitigation note was clear: new pubkey equals new fingerprint.
2. Understand the threat model. If you are worried about nation-state correlation or law-enforcement data purchases, treat each key lifetime as a single identity. For day-to-day ISP hiding or geo-unblocking, this is noise.
3. Watch for the patch. Mullvad says they are already deploying a fix for the unintended behaviour. Once rolled out, the percentile alignment should disappear and the fingerprint collapses.

None of this changes my overall view of Mullvad. It remains one of the very few providers that demonstrated actual measures to ensure privacy, instead of the usual "trust me bro". But privacy is not a static badge; it is the sum of a thousand small implementation details. This was one that slipped. They are fixing it. That is how the good ones behave.

If you are on Mullvad, rotate your key and carry on. If you are shopping, the episode is a useful stress test: ask every provider how their exit-IP assignment actually works, and whether they have ever tested the resulting distribution for fingerprintability. Most will not have an answer. Mullvad at least now does.