Skip to main content

openvpn-auth-oauth2 CVE-2026-41070

CRITICAL
Improper Authentication (CWE-287)
2026-04-22 https://github.com/jkroepke/openvpn-auth-oauth2 GHSA-246w-jgmq-88fg
10.0
CVSS 3.1 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
10.0 CRITICAL
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
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
None

Lifecycle Timeline

4
Analysis Generated
Apr 22, 2026 - 15:00 vuln.today
Analysis Generated
Apr 22, 2026 - 14:39 vuln.today
Patch released
Apr 22, 2026 - 14:39 nvd
Patch available
CVE Published
Apr 22, 2026 - 14:28 nvd
CRITICAL 10.0

DescriptionGitHub 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:

go
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):

go
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 client

Patches

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.

Share

CVE-2026-41070 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy