openvpn-auth-oauth2 CVE-2026-41070
CRITICALSeverity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
Summary
When openvpn-auth-oauth2 is deployed in the experimental plugin mode (shared library loaded by OpenVPN via the plugin directive), clients that do not support WebAuth/SSO (e.g., the openvpn CLI on Linux) are incorrectly admitted to the VPN despite being denied by the authentication logic. The default management-interface mode is not affected because it does not use the OpenVPN plugin return-code mechanism.
Impact
Authentication bypass - any VPN client that does not advertise WebAuth/SSO support (IV_SSO=webauth) is granted full network access without completing OIDC authentication.
This affects only deployments running the experimental plugin mode in versions 1.26.3 through 1.27.2. The default and recommended deployment via the management interface is not affected.
An unauthenticated attacker can connect to the OpenVPN server using any standard OpenVPN client that does not support webauth (e.g., the Linux openvpn CLI). The plugin correctly issues a client-deny command via the management interface, but returns OPENVPN_PLUGIN_FUNC_SUCCESS (status=0) to OpenVPN. Because the auth_control_file content is only consulted when the plugin returns FUNC_DEFERRED, OpenVPN interprets status=0 as "authentication passed" and admits the client - granting full access to the internal network behind the VPN.
Root Cause
In lib/openvpn-auth-oauth2/openvpn/handle.go, the ClientAuthDeny branch of handleAuthUserPassVerify wrote "0" (deny) to the auth_control_file but returned OPENVPN_PLUGIN_FUNC_SUCCESS. OpenVPN only reads the auth_control_file when the plugin returns FUNC_DEFERRED; a synchronous FUNC_SUCCESS return is treated as immediate approval regardless of file contents.
Before fix:
case management.ClientAuthDeny:
// ... writes "0" to auth_control_file ...
if err := openVPNClient.WriteToAuthFile("0"); err != nil {
// only returned ERROR on write failure
return c.OpenVPNPluginFuncError
}
return c.OpenVPNPluginFuncSuccess // ← BUG: OpenVPN sees this as "auth passed"After fix (commit 36f69a6):
case management.ClientAuthDeny:
// ... writes "0" to auth_control_file ...
if err := openVPNClient.WriteToAuthFile("0"); err != nil {
logger.ErrorContext(p.ctx, "write to auth file", slog.Any("err", err))
}
return c.OpenVPNPluginFuncError // ← FIX: OpenVPN now correctly rejects the clientPatches
This vulnerability is fixed in v1.27.3. Users of the experimental plugin mode should upgrade immediately.
Workarounds
- Switch to standalone management client mode (the default, non-plugin deployment). This mode is not affected by the vulnerability because authentication decisions are communicated entirely through the management interface protocol, not through the plugin return code.
- Restrict VPN access at the network level to only clients known to support WebAuth/SSO (e.g., OpenVPN Connect 3+), although this is difficult to enforce reliably and is not recommended as a sole mitigation.
AnalysisAI
Complete authentication bypass in openvpn-auth-oauth2 plugin mode (v1.26.3-1.27.2) grants VPN access to unauthenticated clients. Legacy OpenVPN clients lacking WebAuth/SSO support bypass OIDC authentication entirely and gain full network access due to incorrect plugin return codes. Only the experimental shared-library plugin deployment is affected; the default management-interface mode is not vulnerable. Vendor patch released in v1.27.3 with confirmed fix commits. No active exploitation reported, but trivial to exploit with standard Linux openvpn CLI against vulnerable deployments.
Technical ContextAI
openvpn-auth-oauth2 is a Go-based authentication plugin that integrates OpenID Connect (OIDC) flows into OpenVPN servers. It supports two deployment architectures: a standalone management client (default/recommended) and an experimental shared-library plugin loaded via OpenVPN's plugin directive. The vulnerability arises in the plugin-mode implementation of the OpenVPN plugin API (CWE-287: Improper Authentication). When a client lacking WebAuth/SSO capability (identified by absence of IV_SSO=webauth) connects, the plugin's handleAuthUserPassVerify function in lib/openvpn-auth-oauth2/openvpn/handle.go correctly writes '0' (deny) to the auth_control_file but erroneously returns OPENVPN_PLUGIN_FUNC_SUCCESS. OpenVPN's plugin framework only consults the auth_control_file when the plugin returns FUNC_DEFERRED; a synchronous SUCCESS return is interpreted as immediate authentication approval regardless of file content. The affected Go package is pkg:go/github.com_jkroepke_openvpn-auth-oauth2.
RemediationAI
Primary fix: upgrade openvpn-auth-oauth2 to version 1.27.3 or later immediately if running plugin mode. Patch commit 36f69a6c67c1054da7cbfa04ced3f0555127c8f2 (PR #829) changes ClientAuthDeny logic to return OPENVPN_PLUGIN_FUNC_ERROR instead of FUNC_SUCCESS, forcing OpenVPN to reject unauthenticated clients. Download patched release from https://github.com/jkroepke/openvpn-auth-oauth2/releases/tag/v1.27.3. For organizations unable to upgrade immediately: migrate to standalone management-client mode (default deployment architecture) which is unaffected by this vulnerability-this requires OpenVPN server reconfiguration to use management interface instead of plugin directive. If migration is infeasible short-term, implement network-layer ACLs restricting OpenVPN server access to only known WebAuth-capable client IPs (OpenVPN Connect 3+), though this is difficult to enforce reliably as client IPs may change and legacy clients may be deployed unknowingly. Do not rely on client capability filtering alone as a long-term control. Advisory URLs: https://github.com/jkroepke/openvpn-auth-oauth2/security/advisories/GHSA-246w-jgmq-88fg and https://github.com/jkroepke/openvpn-auth-oauth2/pull/829.
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-246w-jgmq-88fg