OpenVPN Access Server CVE-2025-3110

Q: What is the CVSS score of CVE-2025-3110?

CVE-2025-3110 has a CVSS 4.0 base score of 6.9 (Medium). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

EUVD-2025-210441 MEDIUM

HTTP Request/Response Smuggling (CWE-444)

2026-07-08 OpenVPN

GHSA-92x4-7936-ww96

Request Smuggling Information Disclosure Access Server Red Hat

6.9

CVSS 4.0 · Vendor: OpenVPN

Severity by source

Vendor (OpenVPN) PRIMARY

6.9 MEDIUM

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

5.4 MEDIUM

AC:H reflects the required reverse-proxy deployment topology; S:C applies because smuggled requests cross user/session boundaries through the shared proxy.

3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N

4.0 AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N

Red Hat

5.3 MEDIUM

qualitative

Primary rating from Vendor (OpenVPN).

CVSS VectorVendor: OpenVPN

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Jul 08, 2026 - 17:27 vuln.today

DescriptionCVE.org

OpenVPN Access Server 2.7.2 through 3.1.0 accepts bare line-feed sequences inside HTTP header values, allowing remote attackers to perform HTTP request smuggling when deployed behind a reverse proxy

AnalysisAI

HTTP request smuggling in OpenVPN Access Server 2.7.2 through 3.1.0 enables remote unauthenticated attackers to inject or manipulate backend requests when the Access Server is deployed behind a reverse proxy. The server incorrectly accepts bare line-feed (LF-only, without carriage return) characters inside HTTP header values, creating a parsing discrepancy between the front-end proxy and the Access Server backend - the hallmark of CWE-444. No public exploit has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog; however, the CVSS 4.0 score of 6.9 with integrity impact on both the vulnerable and subsequent systems indicates meaningful risk in typical enterprise VPN gateway deployments fronted by load balancers or reverse proxies.

Technical ContextAI

OpenVPN Access Server is a commercial SSL/TLS VPN solution that exposes an HTTPS management and client API interface. The affected component is its HTTP/1.1 request parser, which fails to reject or normalize bare LF (0x0A) bytes in header values as required by RFC 7230. In HTTP request smuggling (CWE-444), the front-end reverse proxy and the back-end application server interpret the boundaries of an HTTP message differently; an attacker can exploit this parsing gap to prepend or inject a second, hidden request into the same TCP connection. The CPE string cpe:2.3:a:openvpn:access_server:*:*:*:*:*:*:*:* covering versions 2.7.2-3.1.0 confirms this is a server-side application vulnerability, not a client or kernel-level issue. The CVSS 4.0 vector reflects a network-reachable, unauthenticated flaw with low integrity impact on both the vulnerable system and subsequent systems, consistent with smuggling attacks that can redirect or poison requests destined for other users or internal services.

RemediationAI

The primary fix is upgrading to OpenVPN Access Server 3.2.0 or later, as documented in the vendor release notes at https://openvpn.net/as-docs/as-3-2-release-notes.html. The exact patched release version is confirmed as 3.2 by the vendor advisory, though the precise point release (e.g., 3.2.0) should be verified against the release notes before deployment. If immediate upgrade is not feasible, a compensating control is to configure the front-end reverse proxy (e.g., nginx, HAProxy) to strictly reject or normalize bare LF characters in HTTP header values before forwarding to the Access Server backend - for example, in nginx this can be enforced by enabling strict header parsing and using the 'ignore_invalid_headers on' and 'underscores_in_headers off' directives, though these do not universally block all LF-smuggling payloads. Additionally, restricting the reverse proxy to HTTP/2 between proxy and backend (where supported) eliminates the HTTP/1.1 framing ambiguity, though Access Server compatibility should be verified. Organizations that do not deploy Access Server behind a reverse proxy are not exposed to this specific attack vector.