OpenVPN, strongSwan and WireGuard vulnerabilities in embedded firmware: identify, prioritise and fix

Because the VPN daemon is often the only service a device deliberately exposes to the internet. A branch router, a 4G/5G industrial gateway or a machine builder's remote-access box listens on UDP 500 and 4500 for IKE, on 1194 for OpenVPN or on 51820 for WireGuard, and it has to parse packets from anyone before it knows who they are. Several of the bugs below sit exactly there: strongSwan's CVE-2023-41913 advisory describes a stack buffer overflow reachable through "a specially crafted and unauthenticated IKE_SA_INIT message", and libreswan's CVE-2026-77206 advisory says a malicious IKE_AUTH packet can crash pluto without the peer being authenticated.

Embedded images also tend to carry these components as prebuilt packages from a feed, not as code the device maker reviews. On OpenWrt and the many vendor SDKs derived from it, OpenVPN, strongSwan and libreswan come from the community packages feed and WireGuard comes from the kernel, so the version a product ships is whatever the feed or SDK held when the firmware was frozen.

The ones a remote peer can reach before or during authentication, the ones that break authentication itself, and the ones in plugins your build actually loads. The table covers representative CVEs from each project's own advisories; "Needs" is the condition that makes it reachable.

strongSwan. Most strongSwan CVEs are in a plugin or in libcharon's IKEv2 state machine, so a build that does not load the plugin is not reachable. The 6.1.0 release notes list eleven fixes in PKCS#7, X.509 attribute certificate, EAP-AKA, EAP-PEAP/TTLS and libcharon code, and credit "improvements in AI-assisted security analysis" for finding them. Two are protocol-level: the CVE-2026-78135 advisory explains that libcharon did not reject CREATE_CHILD_SA requests on unestablished IKE SAs, which "can allow an unauthenticated peer to potentially establish a usable Child SA", and the CVE-2026-78133 advisory describes a use-after-free in multi-KE rekey collisions that an authenticated peer could exploit for remote code execution. On the client side, the CVE-2025-62291 advisory shows why EAP plugins matter on gateways that dial out: a 6 to 8 byte EAP-MSCHAPv2 Failure Request causes an integer underflow and, depending on compiler options, a heap overflow.

OpenVPN. The OpenVPN Security Announcements page lists each CVE with a short description; many recent entries are Windows-only (interactive service, ovpn-dco-win, tapctl) and do not apply to Linux firmware. The ones that do concentrate in the server's control channel and authentication. The CVE-2026-35058 announcement explains that a crafted packet carrying a valid tls-crypt-v2 client key can trigger an ASSERT and crash the server, and that "setups that do not use tls-crypt-v2 are not affected". The CVE-2026-84790 announcement covers impersonation through a crafted certificate subject in versions 2.3.0 through 2.7.7, which matters for any gateway that maps certificate names to users or configurations. Older plugin-related flaws still turn up in long-lived images: the CVE-2022-0547 announcement describes access granted "with only partially correct credentials" when more than one plug-in uses deferred authentication.

libreswan. The libreswan CVE table lists mostly denial-of-service bugs in pluto, the IKE daemon, each with a vulnerable range and a signed advisory. Several are reachable before authentication, and a crash-restart loop on a remote-access gateway is an outage for every connected site. The CVE-2026-94453 advisory adds that remote code execution "could be possible", and that only configurations with listen-tcp=yes are affected.

WireGuard. The Linux module has a small CVE history, assigned by the Linux kernel CNA and fixed through stable releases, such as the handshake race fixed by this stable commit for CVE-2026-99059. In device firmware the larger WireGuard risk is the code around it. NVD records command injection in the WireGuard configuration of the TP-Link ER7206 (CVE-2023-46683) and in the WireGuard VPN feature of InHand Networks IR302, IR305, IR315 and IR615 routers (CVE-2026-38704, CVSS 9.8, root privileges). RTOS products that use a separate WireGuard implementation inherit its bugs instead of the kernel's: Zephyr's GHSA-x7q7-fjx9-4vj2 advisory describes peer state changed before the anti-replay check, which let a replayed packet redirect the tunnel. Our embedded TCP/IP stack guide covers the network stacks underneath such implementations.

Because all of these daemons rely on a TLS or crypto library, check that library too: our OpenSSL vulnerabilities and mbedTLS and wolfSSL vulnerabilities guides cover the libraries behind OpenWrt's three OpenVPN variants.

Each project publishes its own list, and the format tells you how to automate tracking.

Support windows matter as much as the list. The OpenVPN supported versions page puts 2.7 in full stable support and 2.6 in old-stable support (security and critical fixes) until August 2027, with end of life in August 2028; 2.5 and older are unsupported. As of 2026-11-13 the newest releases are OpenVPN 2.7.9 (5 November 2026, whose security fixes are all Windows-specific) and 2.6.23, strongSwan 6.1.0, and libreswan 5.4.1.

Rank by reachability first: does the device run the daemon as a server or a client, is it reachable from the internet, and are the affected plugin and mode enabled? Then look at exploitation data, and use CVSS only to break ties. Data as of 2026-11-12 (CISA KEV catalog version 2026.11.10, FIRST EPSS scores dated 2026-11-12):

No CVE in this guide was in CISA's KEV catalog in its 2026.11.10 release, and no KEV entry names strongSwan, libreswan, OpenVPN or WireGuard as the vendor or product. The 40 KEV entries that mention VPN are all commercial products, led by Cisco (12), Fortinet (6) and Citrix (5), which is a reminder that exploitation follows exposure: an open-source daemon on a gateway faces the same internet as those appliances. Use the scores as a sort order inside the reachable set, as our KEV and EPSS prioritisation guide explains, not as a reason to skip a pre-authentication bug.

Feeds lag too. As of 2026-11-13 the OpenWrt packages feed builds strongSwan 6.0.7 according to its strongswan Makefile, and its patch directory carries three non-security patches, so a product built from it carries all eleven issues fixed in 6.1.0. The same feed's libreswan Makefile builds 4.12, which falls inside the vulnerable ranges of nine libreswan advisories, including CVE-2024-3652, CVE-2026-77206 and CVE-2026-94453. Its OpenVPN package is 2.7.8, which already has every non-Windows fix to date.

The ones that make an attack offline, unauthenticated or invisible. They are configuration rather than code, so a version upgrade does not remove them.

IKE. strongSwan's strongswan.conf reference names the Aggressive Mode setting i_dont_care_about_security_and_use_aggressive_mode_psk and says it is "strongly discouraged due to security concerns (offline attacks on the openly transmitted hash of the PSK)". On OpenWrt, a single UCI option sets it: the feed's swanctl init script writes that setting when a connection has aggressive enabled, so check /etc/config/ipsec rather than only the generated files. strongSwan 6.1.0 goes further: IKEv1 is disabled by default, must be built with --enable-ikev1, and version defaults to 2.

OpenVPN. The OpenVPN Changes.md for 2.7 says static key mode "is no longer considered good and secure enough" and is removed by default, available only with --allow-deprecated-insecure-static-crypto. The SWEET32 announcement lists BF, DES and RC2 ciphers as ones that "should no longer be used"; OpenVPN 2.5 already dropped BF-CBC from the default cipher set. An image that still ships a 2.4-era configuration with cipher BF-CBC and comp-lzo keeps both weaknesses after an upgrade unless the configuration changes too.

WireGuard. WireGuard has no cipher setting: the protocol page lists one fixed set of primitives (ChaCha20-Poly1305, Curve25519, BLAKE2s, HKDF). Its weak defaults are about keys and the front end: private keys generated once and copied into every image, keys readable by non-root processes, and web pages that pass peer names or endpoints to a shell. Our hard-coded credentials and command injection guides cover both fixes.

Upgrade or backport, remove what the product does not use, harden the defaults, then rebuild and verify.

Upgrade or backport. Move to strongSwan 6.1.0, OpenVPN 2.7.9, libreswan 5.4.1 or 5.3.3, and a supported kernel stable release for WireGuard. Where a full upgrade is too large, strongSwan publishes a patch for each advisory and libreswan links patches from each CVE row, so a backport is a defined task. On OpenVPN's 2.6 old-stable branch, check each announcement for a 2.6 fix: the CVE-2026-84790 announcement names only 2.7.8 as fixed, and the newest 2.6 release, 2.6.23, came out before it. Record each backport in the SBOM or a VEX statement, because the version string will still show the old base; our CSAF VEX for device makers guide shows the format.

Remove what is unused. Build strongSwan without plugins the product does not need, especially EAP methods, charon-tkm and PKCS#7 handling; the 6.1.0 release notes also recommend leaving its removed plugins disabled on older releases. Ship only one VPN stack if the product needs only one. Leave libreswan's listen-tcp off unless IKE-over-TCP is required, and avoid multiple OpenVPN deferred-auth plug-ins.

Harden the defaults. Ship IKEv2 only, with per-device certificates or per-device random keys; never ship Aggressive Mode or a shared PSK. For OpenVPN, ship TLS mode with tls-crypt or tls-crypt-v2 on a patched release, AEAD ciphers only and no compression, and verify certificate names against the right field. Our weak cryptography guide covers cipher and key-size choices.

Rebuild, re-scan, release. Regenerate the firmware SBOM, confirm the shipped binaries carry the new versions, and diff against the previous release; our firmware diffing and patch analysis guide covers checking that a backport really landed. For WireGuard, the check is the kernel: our Linux kernel CVEs guide covers tracking stable releases on a vendor kernel. Then publish the affected and fixed firmware versions for each CVE so operators of remote-access gateways can plan the update.

SoftWSP's automated scan unpacks a firmware image, catalogs the software components in the extracted file system, and identifies OpenVPN, strongSwan, libreswan and WireGuard-related packages by name and version. It then matches those versions against CVE records, CISA's KEV catalog and FIRST's EPSS scores. This is deterministic code: the code scores, and AI narrates.

AI's part is the written explanation on top of that matching. It summarises which VPN CVEs matched, which are KEV-listed or have a high EPSS score, and what the version evidence was, and every sentence cites the component, version and record it relies on. An engineer reviews every finding before the report is delivered. The judgements this guide describes as manual stay with that engineer: which strongSwan plugins and OpenVPN options are active, whether IKEv1 or a shared PSK is configured, which kernel a WireGuard module belongs to, and whether a vendor backport already closes a matched CVE.

For where VPN review fits in a full assessment, see the OWASP Firmware Security Testing Methodology guide, or device & firmware security services to have a specific image reviewed.

This guide draws on the strongSwan, OpenVPN and libreswan security advisories and release notes, OpenVPN's Changes.md and supported-versions page, strongSwan's strongswan.conf reference, the WireGuard protocol and compilation pages, the wireguard-linux-compat repository, Linux kernel source and stable commits, the Zephyr security advisories, OpenWrt package Makefiles and init scripts, NVD, CISA's KEV catalog (version 2026.11.10) and FIRST EPSS data dated 2026-11-12, all read directly on 2026-11-13.