OpenVPN Access Server CVE-2025-3110

Exploitation requires that OpenVPN Access Server be deployed behind a reverse proxy (such as nginx, HAProxy, Apache mod_proxy, or a cloud load balancer) that forwards HTTP/1.1 connections to the Access Server backend. The bare-LF parsing flaw only produces a smuggling opportunity when there is a front-end proxy that does not independently strip or reject bare LF sequences in headers before forwarding. Deployments where the Access Server is exposed directly to the internet without a reverse proxy, or where the reverse proxy terminates and reconstructs HTTP headers (normalizing LF sequences), are not exploitable via this attack path. The CVSS 4.0 vector indicates PR:N and UI:N, meaning no authentication or user interaction is required once network access to the proxy-fronted Access Server is established. Exploitation is limited to versions 2.7.2 through 3.1.0 - versions below 2.7.2 and 3.2.0 or later are outside the affected range.

The CVSS 4.0 score of 6.9 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:L/SA:N) signals a moderate-severity, network-reachable, unauthenticated vulnerability. However, the official vector uses AT:N (no attack requirements), which understates the real exploitation constraint: the vulnerability is only exploitable when OpenVPN Access Server is deployed behind a reverse proxy - a conditional topology that limits the exposed population. The tags include 'Information Disclosure', suggesting that beyond integrity manipulation, request smuggling may expose headers or body fragments from co-tenanted user sessions. No EPSS score was provided in the source data, and the vulnerability is absent from the CISA KEV catalog, meaning confirmed active exploitation is not established. The combination of no KEV, no known public POC, and a reverse-proxy dependency makes this a realistic but non-urgent priority for most organizations - highest risk for multi-tenant or shared-infrastructure deployments where user-to-user request isolation through the proxy is a security assumption.

An attacker targeting an organization's VPN gateway identifies that the OpenVPN Access Server is fronted by an nginx or HAProxy reverse proxy. The attacker sends a crafted HTTP request containing a bare LF character within a header value - for instance inside a custom or forwarded header - causing the proxy to interpret the message as a single request while the Access Server backend parses it as two separate requests. The smuggled second request can be used to prepend attacker-controlled content to another user's legitimate request, potentially hijacking their session, accessing restricted management endpoints, or poisoning shared request queues. No public proof-of-concept code has been identified at time of analysis.