Transparency in Action: OpenVPN v2.7 Independent Security Audit Results

Open source software invites innovation, but it is only as trustworthy as the scrutiny applied to it. That's why we've long believed that inviting independent eyes to examine the OpenVPN source code isn't just a best practice — it's a responsibility we owe to the millions of people and organizations who depend on OpenVPN every day.

Today, we're sharing the results of a comprehensive third-party security audit of OpenVPN v2.7, conducted by Security Research Labs (SRLabs). In this post, we’ll cover exactly what was found, what has been fixed, and where we're headed next.

Before we dive in, it's important to note: OpenVPN Inc. is the primary maintainer of the OpenVPN open-source project, and the OpenVPN 2.7 codebase discussed here is part of that publicly available community software. While OpenVPN Inc. incorporates OpenVPN technology into our commercial products, those offerings may include additional features, integrations, and in some cases different codebases (such as OpenVPN 3) that are not represented in the OpenVPN 2.7 community code. Additionally, other vendors also build products on top of the same open-source foundation.

📄 Download the Full Audit Report (PDF)

Why did SRLabs audit OpenVPN's source code?

This audit was funded by the Sovereign Technology Fund (in collaboration with the Open Tech Fund), an initiative dedicated to strengthening the open-source ecosystem that underpins critical digital infrastructure worldwide. OpenVPN, an open-source, most widely deployed open source VPN solution and protocol on the planet, was a natural candidate for this kind of deep investment.

Over 16 weeks, from October 15, 2025, through March 23, 2026, a team of four SRLabs security researchers worked alongside community developers with full access to the source code and internal documentation. The goal wasn't to rubber-stamp our codebase. Rather, it was to stress-test it the same way a sophisticated adversary would.

How the audit was conducted

The SRLabs team applied a rigorous, structured methodology:

Threat modeling using the STRIDE framework (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to identify realistic attack scenarios before any code was reviewed.

Static analysis using industry tools, including semgrep, weggli-rs, and cppcheck, supplemented by a curated set of reasoning-capable large language models to surface nuanced risk areas and latent attack surfaces.

Dynamic analysis and fuzz testing, including three custom-built fuzzing harnesses developed specifically for this audit — fuzz_tls_pre_decrypt_lite, fuzz_tls_pre_decrypt, and fuzz_options — targeting previously undiscovered remotely accessible entry points. The team also used AddressSanitizer (ASan) and UndefinedBehaviorSanitizer (UBSan) to catch memory corruption issues.

Manual code review of dozens of core source files spanning cryptography, packet handling, TLS integration, DNS, Windows Interactive Service, networking, and authentication modules.

All findings were reported in real time via a dedicated private repository and biweekly sync meetings, allowing the OpenVPN development team to begin remediation before the final report was published.

What SRLabs found: the honest summary

The audit identified 18 issues in total across the codebase:

Here's what that looks like in plain terms: 14 of 18 issues have already been resolved. The remaining issues are either acknowledged and under active consideration or being actively worked on.

Equally important is what was not found. As SRLabs noted directly in their report: "We did not find any attacks against the OpenVPN transport security guarantees." The cryptographic core of OpenVPN — the fundamental tunnel security that protects your traffic — held up under rigorous examination. The overall defensive architecture was found to be sound.

"We did not find any attacks against the OpenVPN transport security guarantees."

A closer look at the key findings

The critical issue: Session-ID Replay Firewall Enabling Spoofing (S4-1) — ✅ mitigated

Issue S4-1 stated, “Session-ID replay firewall always accepts bogus values, enabling blind handshake spoofing.”

The attack scenario: An attacker wants to perform a denial-of-service attack on a server.

This was the most serious finding and has been fully resolved. The issue existed in the server's UDP packet handling, where an inverted comparison in the session-ID firewall check caused spoofed packets — rather than legitimate ones — to pass authentication. An attacker could exploit this to create half-open sessions on the server and potentially exhaust the connection state without any credentials.

Our team moved quickly to address this. The fix corrects the comparison logic to properly validate session IDs and rejects any packets lacking proper ACK/session-ID data.

Medium severity findings — 3 of 4 mitigated

Three medium-severity issues have been addressed:

A heap buffer overflow in the PKCS11 certificate deserialization path (S2-2) that could have leaked memory contents or crashed the process — resolved with proper bounds checking.

An AEAD cipher usage counter undercount (S2-3) on the receive path, which in receive-heavy environments could delay key renegotiation and theoretically weaken nonce reuse protections — corrected to properly accumulate plaintext lengths from both decryption steps.

Out-of-bounds memory writes in DNS domain conversion (S2-4) within the Windows Interactive Service, caused by mixed byte/character accounting in a registry value handler, were rewritten to unify internal accounting and validate inputs properly.

The one remaining open medium-severity issue (S2-5) involves unauthenticated UDP packet processing that can cause the server to allocate connection instances before a TLS handshake completes. This is more of an architectural challenge, and we're actively evaluating approaches. Configurations using --tls-auth or --tls-crypt significantly mitigate this risk; we strongly recommend using one of these options.

Low and informational findings

The majority of lower-severity findings were concentrated in the OpenVPN Interactive Service on Windows — the component that allows unprivileged users to manage VPN connections. SRLabs noted this component had not received the same level of prior security scrutiny, and we agree. Addressing these issues is a priority, and most have already been resolved. Issues included a named pipe race condition with predictable identifiers, a routing metric reference bug, a case-insensitive certificate path hijack, and several DNS configuration logic errors — all of which were mitigated.

We have also acknowledged a small number of lower-severity issues in which remediation involves broader architectural changes or the exploitation surface is tightly constrained. We'll address these in upcoming releases.

What this means for the community

Is this all bad news? Quite the contrary. Finding 18 issues in a codebase as complex and long-lived as OpenVPN isn't alarming. In fact, it's expected and is the whole point of this kind of audit. A codebase with no findings isn't a sign of perfection; it's often a sign that no one looked hard enough.

Our developers were actively engaged throughout the audit, worked hand in hand with the SRLabs team on remediations, and had fixes underway before the final report was even published. That's the open source security model working exactly as it should.

Of note, this audit was conducted on the code before it was stamped as 2.7.0. This means the audit was conducted on a new code that doesn't exist in 2.6 (all new features developed for 2.7), and that 2.7.0 had the opportunity to be released with all the bugfixes mentioned above already included

Read the full report

Transparency means nothing without access. The complete SRLabs audit report is publicly available:

📄 Download the Full Audit Report (PDF)

We encourage community members, security researchers, and anyone with a stake in open source infrastructure to read it in full.

You can also access OpenVPN’s additional security reports, audits, and compliance documents by visiting our Trust Center.

Security is never finished. It's built one honest audit at a time.

Have questions about the findings or the remediation status of specific issues? Join the discussion on the OpenVPN community forums or open an issue on GitHub.