Mullvad Exit IP Fingerprinting: Small Signal, Real Linkability

Mullvad has disclosed a narrow but real privacy issue in how exit IP addresses can be assigned across different VPN servers. The important part: this is not identity exposure. It does not mean a website can suddenly see your home IP address, your Mullvad account number, your payment method, or your name.

But it can weaken a specific privacy assumption many VPN users make: that switching from one VPN server to another creates a clean break between sessions.

According to Mullvad, under some conditions, a website or online service may be able to make a confident guess that the same VPN user who appeared from one Mullvad server later appeared from another. The signal comes from the relative position of assigned exit IP addresses across server ranges. That sounds technical because it is — but the privacy implication is simple: a server switch may not always reset linkability.

Mullvad says it is testing a new exit IP assignment method and plans to roll it out to VPN servers in the coming weeks. Until then, users who rely on server switching for unlinkability should understand the limits and apply the current mitigation.

What Mullvad disclosed#

Mullvad says it learned on Friday, May 15, about a fingerprinting issue affecting users who switch between VPN servers.

The issue involves exit IP assignment. When you connect to a VPN server, your traffic exits to websites from an IP address controlled by the VPN provider. A single server usually does not use only one exit IP. Instead, users are distributed across a range of exit addresses.

Mullvad explains that, under certain conditions, when a user moves from one VPN server to another, the exit IP assigned on the new server can reveal a pattern related to the exit IP previously assigned on the old server. A website observing both connections may be able to infer that the same VPN user is behind them.

That inference is not the same as identification.

A website seeing this pattern does not automatically know who the user is. It does not receive the user’s real IP address. It does not break VPN encryption. It does not give access to accounts or browsing content. The exposed information is narrower: continuity between VPN exits.

That distinction matters because VPN privacy is often reduced to one question: “Is my real IP hidden?” For many ordinary use cases, that is the central benefit. But for users who deliberately switch VPN servers to separate sessions, accounts, research activity, locations, or browsing contexts, continuity itself is sensitive.

If the goal of changing servers is to make the next connection look unrelated to the previous one, this issue can undermine that goal.

How the fingerprint works#

The mechanism is about assignment patterns, not malware, traffic interception, or identity leaks.

Mullvad users connect with WireGuard keys. Each device has a unique WireGuard key used to encrypt the VPN connection. In Mullvad’s system, there is also an internal tunnel address. Mullvad says this internal tunnel address is usually, though not always, correlated with the user’s WireGuard key.

The fingerprinting issue appears when the same internal tunnel address is used while connecting to different VPN servers.

Each VPN server has a range of exit IP addresses. Because of technical limits, not every user can be placed behind exactly the same exit address, so users are distributed across the available range. Mullvad describes a scenario where a user may be assigned an exit IP around the same relative position in each server’s range — for example, around 40% into the available exit IP block.

If that relative position repeats across server changes, an outside observer can compare the old and new exit IPs and notice the pattern.

In plain terms: the exit IP can carry a positional clue. If that clue survives a server switch, the new VPN IP may not be as independent from the old one as the user expects.

This is not a perfect one-person identifier. Mullvad notes that many users are usually assigned to every exit address. That means multiple users may share the same apparent signal, reducing certainty. But privacy failures do not always require certainty. In tracking and correlation, the signal only needs to improve the guess.

A website may already have timing data, account behavior, browser information, language settings, screen characteristics, cookies, or login state. The exit IP pattern can become one more data point. In some cases, that data point may be enough to make an observer confident that two sessions are related.

That is why this is best understood as an unlinkability failure, not deanonymization.

Why this matters for VPN users#

Most VPN users think about privacy in layers. The first layer is hiding the real network address from websites and apps. A VPN usually does that by replacing the user’s home, work, school, or mobile carrier IP address with a VPN exit IP.

But hiding the original IP is not the same as becoming unlinkable.

Websites and online services can recognize users through many signals, including:

• login sessions;
• persistent cookies;
• browser fingerprinting;
• device characteristics;
• time zone and language settings;
• behavioral patterns;
• account recovery details;
• payment or subscription identifiers;
• timing and traffic patterns;
• IP reputation and IP assignment behavior.

This Mullvad issue concerns one specific VPN-side signal: how exit IP addresses may relate across different servers.

For many users, practical impact may be low. If you stay logged into the same account, keep the same browser profile, accept the same cookies, and use the same device fingerprint, switching VPN servers was never enough to create a clean privacy break. The website already has simpler and stronger ways to connect your activity.

For stricter threat models, the issue is more relevant.

Some users switch VPN servers specifically to separate one activity from another. That may include journalists, researchers, activists, investigators, people testing abuse infrastructure, people avoiding targeted tracking, or ordinary users who want to separate work, personal, and sensitive browsing.

For those users, the lesson is precise: a new VPN server does not automatically mean a new privacy context.

Changing the visible IP address is only one part of unlinkability. If assignment logic leaks a relationship between old and new exits, a server switch may preserve more continuity than expected.

What Mullvad recommends now#

Mullvad’s current advice is narrow. Users only need to change behavior if they switch VPN servers specifically to prevent activity on one server from being linked to activity on another.

For that case, Mullvad recommends logging out and logging back into the Mullvad app when switching servers. According to Mullvad, this regenerates the WireGuard key and changes the internal IP address.

That matters because the issue is tied to the internal tunnel address and its relationship to exit IP assignment. Resetting that session state should reduce the cross-server continuity that enables the fingerprint.

A practical higher-sensitivity workflow would look like this:

1. Finish activity on the first VPN server.
2. Log out of the Mullvad app.
3. Log back in so the WireGuard key and internal IP change.
4. Connect to the new VPN server.
5. Use a separate browser profile, container, or clean browsing state if unlinkability is the goal.
6. Do not log into the same account in both sessions unless account continuity is acceptable.
7. Avoid reusing cookies, saved sessions, persistent identifiers, and distinctive browser settings across the two activities.

The last points are broader privacy hygiene, not the core Mullvad-specific fix. They are still essential. If you remain logged into the same website account, keep the same cookies, or reuse the same browser fingerprint, then fixing the VPN-side signal will not remove easier tracking signals.

For real session separation, VPN switching should be paired with browser and account separation. Otherwise, the VPN may change while the web identity stays the same.

Practical takeaways#

Use the takeaway that matches your threat model.

If you use Mullvad mainly to hide your real IP from sites#

• No evidence in Mullvad’s disclosure says your real IP address, account number, payment details, traffic contents, or identity were exposed.
• You do not need to panic-switch providers or rotate accounts because of this disclosure alone.
• Keep using normal privacy basics: update the app, keep the VPN connected when needed, and avoid assuming that a VPN hides cookies, logins, or browser fingerprints.

If you switch Mullvad servers to make sessions look unrelated#

Until Mullvad’s new exit IP assignment method is deployed, treat a simple server change as incomplete separation.

Do this instead:

1. End the first activity.
2. Log out of the Mullvad app.
3. Log back in to regenerate the WireGuard key and change the internal IP address, as Mullvad recommends.
4. Connect to the next server.
5. Start the next activity in a separate browser profile, container, or clean session.
6. Do not carry over cookies, active logins, recovery identifiers, or other persistent web state.

This does not guarantee anonymity against every tracker, but it removes the specific VPN-side continuity Mullvad described and reduces easier web-side correlation signals.

If you manage privacy guidance for a team#

• Tell users that “new VPN server” and “new identity context” are not the same thing.
• For sensitive work, define a repeatable separation procedure: reset Mullvad session state, change browser state, separate accounts, and document what must not be reused.
• Monitor Mullvad’s rollout of the new exit IP assignment method before relaxing that procedure.
• If a workflow depends on unlinkability, test the full workflow rather than only checking that the visible IP address changed.

Quick self-check#

Before treating two sessions as separate, ask:

• Did I log out and back into Mullvad before changing servers?
• Am I using a fresh browser profile or container?
• Am I avoiding the same website account in both sessions?
• Did I remove or isolate cookies and saved sessions?
• Are browser fingerprinting signals, language, time zone, extensions, and device traits still linking me?

If the answer is “no” to any of these, the VPN server switch may not provide the separation you expect.

What not to overclaim#

This disclosure should be taken seriously, but it should not be exaggerated.

It is not evidence that Mullvad exposed user identities. The disclosed issue concerns correlation between VPN exits, not direct deanonymization.

It is not described as an exploit that gives attackers control over devices, accounts, or VPN servers. The source material does not claim remote code execution, credential theft, traffic decryption, or disclosure of browsing content.

It also requires observation. A website or online service needs to see the relevant connections and compare exit IPs. This is useful to an observer trying to link sessions that reach it or its infrastructure. It is not a universal tracking beacon available to everyone on the internet.

And the signal is not necessarily unique to one user. Mullvad says many users are usually assigned to every exit address. That means the pattern can strengthen a correlation guess, but it does not automatically prove that two connections came from the same person.

The accurate framing is this: the bug can reduce the anonymity set in some cross-server switching scenarios. It does not collapse the VPN privacy model by itself.

Conclusion#

Mullvad’s disclosure is a good example of how VPN privacy can fail in subtle ways. The issue does not reveal user identity, break encryption, or expose browsing content. But it may allow a website or service to correlate activity across different Mullvad servers when the user expects a server switch to create separation.

That is a narrow failure, but a real one.

Mullvad says it is testing a new exit IP assignment method designed so that the exit IP used on one server gives no information about which exit IP is used on another server, or by another user on the same server. The company plans to roll out the change in the coming weeks.

Until then, the safest interpretation is simple: switching VPN servers changes your visible IP, but it may not fully reset your privacy context. If unlinkability is the goal, reset the VPN session state, separate browser state, and avoid carrying identifiers across sessions.

Privacy is not only about encryption. It is also about small mapping rules that decide what patterns remain visible from outside.