# CVE-2026-41070: openvpn-auth — Fixed in 1.27.3

🐹

🐹 Go

Not in CISA KEV

CRITICAL severity

# CVE-2026-41070 — openvpn-auth-oauth2

CRITICAL [Fix: jkroepke/openvpn-auth-oauth2@36f69a6](https://github.com/jkroepke/openvpn-auth-oauth2/commit/36f69a6c67c1054da7cbfa04ced3f0555127c8f2)

CVE-2026-41070 is a critical-severity (CVSS 10) Improper Authentication vulnerability in github.com/jkroepke/openvpn-auth-oauth2. A fix is available for github.com/jkroepke/openvpn-auth-oauth2 — see the affected versions and patch details below.

openvpn-auth-oauth2 returns FUNC\_SUCCESS on client-deny, allowing unauthenticated VPN access

Also known as[GHSA-246w-jgmq-88fg](/vulnerability/GHSA-246w-jgmq-88fg)GO-2026-4963

Published

May 8, 2026

Updated

Oct 28, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Nov 9, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

## Exploitation Status

### No confirmed exploitation observed yet

-   A successful exploit gives an attacker total control of the affected component, not partial access.
-   CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-41070.

## EPSS Exploitation Probability

[via FIRST.org ↗](https://www.first.org/epss/)

0.4%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs38th percentile — riskier than 38% of all scored CVEsHighest risk

0.00%0.36%0.72%1.08%0.0%0.4%Jun 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/).

## How urgent is this, really

## Where this sits among everything scored

## Real-World Exposure

1 pkg affected

🐹`github.com/jkroepke/openvpn-auth-oauth2`

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

## Description

## 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`](https://github.com/jkroepke/openvpn-auth-oauth2/commit/36f69a6c67c1054da7cbfa04ced3f0555127c8f2)):**

```
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.

-   **Fix commit:** [`36f69a6`](https://github.com/jkroepke/openvpn-auth-oauth2/commit/36f69a6c67c1054da7cbfa04ced3f0555127c8f2)
-   **Fix PR:** [#829](https://github.com/jkroepke/openvpn-auth-oauth2/pull/829)

## 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.

## Affected Packages

1 total 1 fixed

Ecosystem

Package

Vulnerable range

Fix

🐹Go

`github.com/jkroepke/openvpn-auth-oauth2` 

≥ 1.26.3&&< 1.27.3

1.27.3`go get github.com/jkroepke/openvpn-auth-oauth2@v1.27.3`

## Detection & mitigation playbook

Open-source dependency

1.  ### Detect
    
    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/jkroepke/openvpn-auth-oauth2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
    
2.  ### Fix
    
    Update github.com/jkroepke/openvpn-auth-oauth2 to 1.27.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-41070 is resolved across your whole dependency graph.
    
3.  ### Workarounds
    
    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.
    

## Frequently Asked Questions

\# 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 O

O3 Security · Impact-Aware SCA

### Is CVE-2026-41070 in your dependencies?

Find it across Go, including transitive dependencies.

[Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)