CVE-2026-41070: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-41070 is a critical authentication bypass vulnerability in openvpn-auth-oauth2, a plugin/management interface client for OpenVPN that handles OIDC-based SSO authentication flows. When deployed in experimental plugin mode, clients that do not support WebAuth/SSO (e.g., the standard OpenVPN CLI on Linux) are incorrectly admitted to the VPN despite being denied by the authentication logic. The vulnerability affects versions 1.26.3 through 1.27.2 of openvpn-auth-oauth2; the default management-interface mode is not affected. It was published on May 8, 2026, with the security advisory (GHSA-246w-jgmq-88fg) originally published by the maintainer on April 17, 2026. It carries a CVSS v3.1 base score of 10.0 (Critical) (GitHub Advisory).

The root cause (CWE-287: Improper Authentication) lies in the handleAuthUserPassVerify function within lib/openvpn-auth-oauth2/openvpn/handle.go. In the ClientAuthDeny branch, the plugin correctly wrote "0" (deny) to the auth_control_file, but then returned OPENVPN_PLUGIN_FUNC_SUCCESS (status=0) to OpenVPN. OpenVPN only reads the auth_control_file when the plugin returns FUNC_DEFERRED; a synchronous FUNC_SUCCESS return is interpreted as immediate authentication approval regardless of the file's contents. This means any standard OpenVPN client that does not advertise IV_SSO=webauth support — such as the Linux openvpn CLI — bypasses OIDC authentication entirely and is granted VPN access. The fix (commit 36f69a6) changes the return value in the deny branch from OPENVPN_PLUGIN_FUNC_SUCCESS to OPENVPN_PLUGIN_FUNC_ERROR, causing OpenVPN to correctly reject the client (GitHub Advisory, Fix Commit).

An unauthenticated remote attacker can connect to an OpenVPN server protected by openvpn-auth-oauth2 in plugin mode without completing any OIDC/SSO authentication, gaining full access to the internal network resources behind the VPN. The scope change in the CVSS score reflects that a successful bypass on the VPN gateway exposes all downstream network assets — internal servers, databases, and services — to the attacker. The confidentiality and integrity impacts are rated High, as the attacker can read and potentially modify data on any resource reachable through the VPN tunnel; availability is not directly impacted by the bypass itself (GitHub Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of active in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is trivially exploitable by any unauthenticated attacker with network access to the OpenVPN server using a standard OpenVPN client that lacks WebAuth/SSO support — no special tools or credentials are required. The EPSS score is 0.043% (low probability of near-term exploitation), and the vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The vulnerability is detected by Qualys (detection ID 5011393) and Tenable Nessus (plugin 315695) (Feedly).

1. Identify target: Locate an OpenVPN server running openvpn-auth-oauth2 in experimental plugin mode (versions 1.26.3–1.27.2), identifiable by the plugin directive in the OpenVPN server configuration referencing the openvpn-auth-oauth2 shared library.
2. Use a non-WebAuth client: Use a standard OpenVPN CLI client on Linux (or any client that does not send IV_SSO=webauth in its environment variables during the handshake).
3. Initiate connection: Connect to the OpenVPN server with a valid certificate (or any credentials, depending on other auth layers) but without completing the OIDC/SSO browser-based flow.
4. Authentication bypass occurs: The plugin issues a client-deny via the management interface but returns OPENVPN_PLUGIN_FUNC_SUCCESS to OpenVPN. OpenVPN interprets this as authentication success and admits the client.
5. Gain VPN access: The attacker is now connected to the VPN and has full network access to internal resources protected by the OpenVPN server, without ever completing OIDC authentication (GitHub Advisory, Fix Commit).

• Logs: OpenVPN server logs showing a client connection being established immediately after a client-deny management interface command — look for CLIENT_CONNECT or successful TLS/auth completion log entries for clients that did not complete the SSO browser flow.
• Logs: openvpn-auth-oauth2 logs showing client-deny issued for a session, followed by no corresponding OIDC token exchange or callback, yet the OpenVPN session remains active.
• Network: VPN tunnel traffic from clients that do not have a corresponding OIDC session or token in the auth-oauth2 token storage (in-memory or persistent).
• Process/Environment: OpenVPN client connections where the client environment does not include IV_SSO=webauth but the session is nonetheless admitted — visible in OpenVPN's --status output or management interface status command.
• File System: The auth_control_file for a session contains "0" (deny) but the associated VPN session is still active, indicating the file was not consulted by OpenVPN (GitHub Advisory).

Upgrade openvpn-auth-oauth2 to version 1.27.3 or later, which corrects the return code in the ClientAuthDeny branch to OPENVPN_PLUGIN_FUNC_ERROR (GitHub Advisory, Fix Commit). If an immediate upgrade is not possible, switch to the default management-interface mode (remove the plugin directive and use the standalone management client), which is not affected by this vulnerability. As an additional network-level control, restrict access to the OpenVPN server port to known, trusted IP ranges until patching is complete.

The vulnerability was reported by security researcher kkalev and credited in the GitHub advisory. The Hacker Wire published a dedicated article on the critical authentication bypass (The Hacker Wire). The issue was also noted on Mastodon and Bluesky by CVE tracking accounts shortly after publication. Community reaction has been focused on the fact that the experimental plugin mode — not the default deployment — is affected, limiting the overall exposure.