openvpn-auth-oauth2 CVE-2026-41070
CRITICAL
GHSA-246w-jgmq-88fg
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify OpenVPN server with plugin-mode oauth2
-
DeliveryConnect using legacy OpenVPN CLI client
-
ExploitPlugin returns success despite deny logic
-
ExecutionOpenVPN grants unauthenticated network access
-
ImpactPivot to internal resources
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A07:2025 - Authentication Failures
ASVS 5.0
V6 - Authentication Authentication mechanism validation
MITRE ATT&CK
2 techniques across 2 tactics: Defense Evasion, Initial Access The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires the target OpenVPN server to be running openvpn-auth-oauth2 versions 1.26.3-1.27.2 deployed specifically in experimental plugin mode (loaded as shared library via OpenVPN plugin directive). The default management-interface deployment mode is NOT vulnerable. Attacker must connect using an OpenVPN client that does NOT advertise WebAuth/SSO support (e.g., Linux openvpn CLI, older OpenVPN clients). No authentication credentials, user interaction, or non-default OpenVPN server configuration is required beyond the plugin-mode deployment. Attack vector is network (AV:N), attack complexity is low (AC:L), no privileges required (PR:N), no user interaction (UI:N). Limiting factor: organizations using the recommended management-interface mode (default) are immune; only those who explicitly configured the experimental plugin mode are at risk. |
| Impact | CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N) indicates maximum severity: network-exploitable, no authentication required, low complexity, scope change (VPN clients gain access to internal networks), high confidentiality and integrity impact. However, real-world risk is constrained by deployment context. Only installations using the experimental plugin mode (not the default management-interface mode) across versions 1.26.3-1.27.2 are vulnerable. EPSS and KEV data not provided, suggesting no confirmed active exploitation at time of vendor disclosure. Exploitation is trivial-any standard OpenVPN CLI client connects and is authenticated without OIDC flow-but requires attackers to know a vulnerable endpoint is running this specific deployment mode. SSVC considerations: exploitation is automatable (no user interaction), technical impact is total (authentication neutralization), but scope is limited to non-default configurations. Vendor response was rapid with patch in v1.27.3, fix commit 36f69a6, and PR #829 providing verifiable remediation. Organizations using plugin mode face critical risk; those on default management-interface mode are unaffected. Missing data: no public POC published in advisories, no third-party validation of patch completeness beyond vendor confirmation. |
| Exploit ScenarioDerived | An external attacker identifies an organization's OpenVPN endpoint running openvpn-auth-oauth2 in plugin mode. Using the standard Linux openvpn CLI client (which does not advertise IV_SSO=webauth), the attacker initiates a connection with arbitrary credentials. The plugin issues a client-deny command but returns OPENVPN_PLUGIN_FUNC_SUCCESS to OpenVPN, which interprets this as successful authentication and grants the connection. The attacker now has full access to the internal corporate network behind the VPN without completing any OIDC authentication flow. No public proof-of-concept code is referenced in the advisory, but exploitation requires only a standard OpenVPN client and knowledge of the server endpoint. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Apr 22, 2026
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.
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.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in go
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N
Primary rating from Vendor (https://github.com/jkroepke/openvpn-auth-oauth2).
CVSS VectorVendor: https://github.com/jkroepke/openvpn-auth-oauth2
Lifecycle Timeline
2DescriptionCVE.org
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.
Executive ViewAI
The openvpn-auth-oauth2 plugin (versions 1.26.3-1.27.2) contains a critical authentication bypass that allows any VPN client to gain full network access without valid credentials, completely circumventing OIDC-based access controls. Organizations using the experimental shared-library plugin deployment mode face immediate risk of unauthorized network access and potential lateral movement, as attackers require only standard OpenVPN tools to exploit this vulnerability.
If immediate patching is not feasible: (1) Disable or restrict the openvpn-auth-oauth2 plugin and revert to native OpenVPN authentication until patched; (2) Implement network-layer controls (firewall rules, IP allowlisting) to restrict VPN access to known, trusted client IP ranges; (3) Increase monitoring and alerting on VPN connection logs for anomalous access patterns; (4) If using management-interface mode instead of shared-library mode, no compensating controls are required-apply vendor patch (version 1.27.3 or later) as primary remediation.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allVendor StatusVendor
SUSE
Severity: Critical| Product | Status |
|---|---|
| SUSE Linux Enterprise Server 16.1 | Affected |
| SUSE Linux Enterprise Server for SAP applications 16.1 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP5 | Affected |
| SUSE Linux Enterprise Module for Package Hub 15 SP6 | Affected |
| openSUSE Leap 15.5 | Affected |
| openSUSE Leap 15.6 | Affected |
Exploit-DB