The report for the 2024 security audit of the app is now available

December 11, 2024 External audits App Security

The third party security audit of the Mullvad VPN app has concluded that the app has a high security level. Some non-critical issues were found, and have been fixed to the extent possible.

We have been conducting external security audits of our VPN apps biennially since 2018. We did this in 2018, 2020 and 2022. Two more years have passed and a fourth audit has recently been completed.

Four people from X41 D-Sec performed a penetration test and source code audit of the Mullvad VPN app on all supported platforms for a total of 30 person-days. The audit was performed between 23rd October 2024 and 28th November 2024. The audit report was handed over to Mullvad on 30th November 2024.

Three quotes with key conclusions from the report:

A total of six vulnerabilities were discovered during the test by X41. None were rated as having a critical severity, three as high, two as medium, and one as low. Additionally, three issues without a direct security impact were identified.

Overall, the Mullvad VPN Application appear to have a high security level and are well positioned to protect from the threat model proposed in this report. The use of safe coding and design patterns in combination with regular audits and penetration tests led to a very hardened environment.

In conclusion, the client applications exposed a limited number of relevant vulnerabilities. Mullvad VPN AB addressed them swiftly and the fixes were audited to be working properly.

Read the report

X41 has posted an announcement about the audit on their website(direct link to the final report). We also host all revisions of the report in our git repository.

Overview of findings

Mullvad implemented fixes for four of the issues during the audit, and released a new version of the app on the affected platforms around the time when we were handed the audit report.

For more details on each finding, please see our audit documentation in git.

MLLVD-CR-24-01: Signal Handler Alternate Stack Too Small (Severity: High)

The alternative stack configured for the fault signal handler in mullvad-daemon was too small. Since there was no guard page or other stack overrun protections in place, this could lead to the signal handler reading and writing beyond the allocated stack, leading to potential heap corruption and undefined behavior. This affected Android, Linux and macOS.

The fix for this issue is included in version 2024.8 for desktop and version 2024.9 for Android.

We agree with the conclusion from X41 that this vulnerability is not trivial to exploit, but if exploited it would be severe. Due to the low exploitability and the fact that this issue has been present for multiple years without any practical issues surfacing, we decided to not immediately mark existing apps as unsupported, but to release a fixed app version as soon as the audit was complete. We still recommend users on the affected platforms to upgrade to the latest version of the app at their earliest convenience.

MLLVD-CR-24-02: Signal Handler Uses Non-Reentrant Safe Functions (Severity: High)

The fault signal handler in mullvad-daemon called functions which are not signal safe. This could cause undefined behavior, or worst case, be exploitable if the attacker was able to control enough of the program state and externally trigger a fault. This affected Android, Linux and macOS.

The fix for this issue is included in version 2024.8 for desktop and version 2024.9 for Android.

We are not aware of any way to maliciously or accidentally exploit or trigger this bug. This bug has been around for multiple years without any practical issues surfacing. So just like for MLLVD-CR-24-01 above, we decided to not release any quick patch release immediately, but instead wait for the audit to finish and release fixes for all audit findings at the same time.

MLLVD-CR-24-03: Virtual IP Address of Tunnel Device Leaks to Network Adjacent Participant (Severity: Medium)

The Linux kernel (and consequently Android) by default replies to ARP requests for any local target IP address, configured on any interface. This allows an attacker on the same local network to learn the IP address of the VPN tunnel interface by sending an ARP request for every private IPv4 address to the device.

This can be used by an adversary on the same local network to make a qualified guess if the device is using Mullvad VPN. Furthermore, since the in-tunnel IP only changes monthly, the adversary can also possibly identify a device over time.

Linux and Android are the only affected operating systems. For Linux, the fix for this issue is included in version 2024.8.

Android apps, including Mullvad VPN, do not have the permission to change this OS behavior. All Android devices that we know of are affected. We have reported this issue upstream to Google, and recommended that they change the relevant settings to prevent this issue.

We don't consider this a high severity leak since the in-tunnel IP does not disclose a lot about the user. The IP is also automatically rotated every month, only making it a temporary identifier. However, Android users that are worried can log out and back in to the app, as this gives them a new tunnel IP. We are working on solutions that stops the in-tunnel IP from remaining the same over time. When this has been deployed, the issue will be gone on Android also.

MLLVD-CR-24-04: Deanonymization Through NAT (Severity: Medium)

This attack is about how an attacker that can both observe a user’s tunnel traffic and also send UDP traffic with a spoofed sender IP can potentially infer if the user has a connection to a specific internet service. They can do this by sending UDP packets with a unique size with the source address and port set to the internet service they are interested in, the destination IP to the exit VPN relay of the user. They need to do this for every possible destination port. If the user has a connection with that internet service endpoint, eventually one packet will match the NAT table entry on the VPN relay and be forwarded down the tunnel. The attacker can then observe a packet on the tunnel with the unique size (plus VPN headers).

The attack would be hard to carry out. First of all the attacker would need to be able to send UDP packets with spoofed source IPs. Many network providers prevent this, but not all of them. The attacker would also need to be able to observe the client's tunnel traffic. On top of this, the attacker would also need to send large volumes of data with good timing to carry out the attack. If the attacker knows what VPN relay IP address the client exits through, they would need to send tens of thousands of packets before hitting the correct destination port, that match the relay's NAT table entry. Since every Mullvad relay has multiple exit IPs, and each client is assigned a random IP, the attacker would need to figure out what exit IPs the relay has, and repeat the above brute force method on all of them. Moreover, if the client uses multihop, the attacker can't easily infer what exit VPN relay the client uses. The attacker must then perform the above brute force attack against every exit IP of every Mullvad relay. All of this must be carried out in the somewhat short amount of time that the NAT table entry is active on the relay, meaning a time window of just a few minutes around when the client device communicates with the internet service.

This is a privacy problem with how UDP works in general, and not really about Mullvad VPN specifically. Since UDP is becoming a more common and important protocol due to http/3 and similar, Mullvad would love if it became the norm that all network providers performed UDP source address validation, as it would mitigate issues like this to a large extent.

The DAITA feature in Mullvad VPN can mitigate this attack to some extent. Since all packets are padded to the same size, and extra noise packets are injected, it becomes harder for the attacker to detect when their probing packet is forwarded to the client.

Mullvad does not plan to actively mitigate this issue further in the app. The attack is already hard to carry out, and can be prevented further by enabling multihop and/or DAITA. Concerned users can also choose to avoid using UDP to communicate with sensitive services.

MLLVD-CR-24-05: Deanonymization Through MTU/delays (Severity: Low)

This attack is about how an attacker that can both observe a user’s tunnel traffic and also manipulate internet traffic en route to the exit VPN relay of the user can potentially deanonymize the user. By adjusting the MTU of the traffic, delaying or dropping packets or cause traffic bursts in connections outside the tunnel, they can observe if the same traffic patterns occur on the encrypted tunnel traffic. With this information they can potentially infer if the connections belong to the user of the observed tunnel or not.

Attacks like these are not specific to Mullvad VPN. The attack simply relies on core internet functionality and pattern matching. The threat model defined in the report makes it clear that it's virtually impossible to be fully protected against a very powerful attacker that can observe and manipulate internet traffic on a global scale.

DAITA mitigates this attack to some extent by padding all packets to the same size and injecting noise in the tunnel. This makes it significantly harder for the attacker to detect the pattern they created in the tunnel.

Mullvad's multihop feature also makes this attack harder to carry out. Multihop hides the client's real IP from the exit VPN relay. If the attacker can observe and control traffic in and out of the exit VPN relay, they can perform the above attack. But if the client is using multihop, the attacker cannot see the real IP of the client. The attacker can deduce which entry VPN relay the client likely connects via, but they must then also be able to observe all traffic in and out of the entry VPN relay to find the IP of the client. Preventing attacks like these was one of the reasons multihop was introduced, and is why Mullvad recommends using entry and exit relays from different hosting providers for the best protection.

We think this kind of attack is not in the threat model of most users. However, we encourage everyone to consider their own situation and decide what they need to protect against.

We agree with the severity rating being set to low on this issue, since it requires a powerful attacker and only provide them with heuristics to make qualified guesses about who the client is.

MLLVD-CR-24-06: Windows installer runs adjacent taskkill.exe (Severity: High)

The Windows installer for the Mullvad VPN app had an issue where it executed a binary named taskkill.exe placed next to the installer. If the user was tricked into downloading a malicious binary with that name to their downloads directory, then ran the installer from the same directory, the installer would execute the malicious code.

Since the installer runs with administrator privileges, this vulnerability allows for privilege escalation. Given the impact of a compromise, and how relatively easy it is to trigger, we agree with the severity rating of high.

The fix was released in version 2024.8. Since the vulnerability only exists in the installer, and not the actual VPN app, we decided to not mark existing apps as unsupported or vulnerable. An already installed app is not affected by this.

Informational notes

The audit made three observations that does not have a direct security impact. X41 did not give these a severity rating, but included them as they still recommended us to mitigate the issues. You can read about these in the audit documentation in the git repository.

Last words

Mullvad is very happy with the quality of the audit performed by X41 D-Sec. X41 managed to find issues in our code that previous audits missed, which shows that there is great benefit in having audits performed by different companies. This is not meant as criticism against the previous audit companies. The app is too big to realistically look into every aspect and detail in a few weeks. We have always had the explicit tactic to use a different third party auditor for every audit, to get different sets of eyes from people with different skills and mindsets every time.

We would like to thank X41 D-Sec for their great security assessment and the nice collaboration we have had with you during the planning and execution stages of the audit.