CVE-2026-58172: Ocelot Auth Bypass Vulnerability

CVE-2026-58172 Overview

CVE-2026-58172 is a security control bypass vulnerability in Ocelot, an open-source .NET API Gateway maintained by ThreeMammals. Versions through 24.1.0 allow denied clients to circumvent IP-based access restrictions by sending WebSocket upgrade requests. The WebSocket upgrade pipeline branch configured via MapWhen in OcelotPipelineExtensions.cs omits SecurityMiddleware. As a result, requests originating from blocked IP addresses are proxied to downstream services without enforcement of the configured allow/block list. The issue is classified as [CWE-288] Authentication Bypass Using an Alternate Path or Channel. It is fixed in commit f156fd4.

Critical Impact
Attackers on blocked IP ranges can reach downstream services through the WebSocket upgrade path, bypassing configured IPSecurityPolicy and ISecurityPolicy enforcement.

Affected Products

Ocelot API Gateway versions through 24.1.0
Deployments using SecurityOptions with IP allow/block lists
Routes exposing WebSocket (ws/wss) upstream schemes

Discovery Timeline

2026-06-30 - CVE-2026-58172 published to NVD
2026-07-02 - Last updated in NVD database

Technical Details for CVE-2026-58172

Vulnerability Analysis

Ocelot supports IP allow/block lists through the SecurityOptions configuration, enforced by SecurityMiddleware in the standard request pipeline. The middleware inspects the upstream client IP and returns 403 Forbidden when the address matches a blocked entry or falls outside the allowed set. It relies on IPSecurityPolicy and any registered ISecurityPolicy implementation.

In affected versions, Ocelot builds a separate pipeline branch for WebSocket upgrade requests using MapWhen in OcelotPipelineExtensions.cs. This branch handles the HTTP CONNECT semantics required for upgrading a connection to a WebSocket. The branch did not register SecurityMiddleware, so upgrade requests skipped the IP filter entirely and reached the downstream proxy stage. Any attacker able to issue an Upgrade: websocket request can therefore contact backend services that operators explicitly intended to isolate from their IP range.

Root Cause

The root cause is an incomplete pipeline branch. The main Ocelot pipeline registered SecurityMiddleware, but the WebSocket branch created by MapWhen was assembled with a reduced middleware set. Because IP filtering is implemented as middleware rather than as an unconditional gate, omitting it from one branch creates an alternate channel that bypasses the security control [CWE-288].

Attack Vector

Exploitation requires only network reachability to the Ocelot gateway. An attacker on a blocked source IP sends a standard WebSocket upgrade handshake to an Ocelot route configured with SecurityOptions. Ocelot routes the request into the WebSocket branch, skips IP enforcement, and proxies the traffic to the downstream service. No authentication or user interaction is required.

text

// Documentation change accompanying the fix (docs/features/routing.rst)
.. warning::
  1. The *Security Options* feature is designed for static routes only,
     and it is not supported in Dynamic Routing mode.
  2. WebSockets support and its ``ws`` scheme have been available since
     version 25.0. IP allowed/blocked lists are enforced on WebSocket
     upgrade requests (also known as CONNECT method).

Source: GitHub Commit f156fd4

Detection Methods for CVE-2026-58172

Indicators of Compromise

Successful HTTP 101 Switching Protocols responses from Ocelot to source IPs listed in SecurityOptions block lists.
Downstream service access logs showing traffic from IP ranges not present in the gateway's allow list, correlated with Upgrade: websocket headers.
Gateway logs where SecurityMiddleware produced no 403 Forbidden entry despite requests originating outside the allowed range.

Detection Strategies

Compare upstream client IPs on WebSocket upgrade requests against the configured SecurityOptions policy and alert on mismatches.
Instrument downstream services to log the immediate peer IP forwarded by Ocelot and reconcile it against expected allow lists.
Hunt for anomalous WebSocket session establishment from previously unseen network ranges targeting routes that should be IP-restricted.

Monitoring Recommendations

Enable verbose Ocelot request logging and forward it to a centralized analytics platform for IP-based correlation.
Track the ratio of 403 responses to WebSocket upgrade attempts before and after patching to validate enforcement.
Monitor build manifests and container images for Ocelot package versions at or below 24.1.0.

How to Mitigate CVE-2026-58172

Immediate Actions Required

Upgrade Ocelot to the release containing commit f156fd4 or later, which adds SecurityOptions support to the WebSocket pipeline.
Inventory all Ocelot deployments and identify routes that rely on SecurityOptions for IP allow/block enforcement.
Until patched, restrict access to Ocelot at the network perimeter using a firewall or load balancer ACL that also inspects WebSocket upgrade requests.

Patch Information

The fix is applied in commit f156fd4017ca25025fffdad8ec56c1d657dfb402, delivered through pull request #2406 addressing issue #2403. The patch registers SecurityMiddleware in the WebSocket pipeline branch so IPSecurityPolicy (and any custom ISecurityPolicy) evaluates upgrade requests and returns 403 Forbidden for disallowed clients. Refer to the VulnCheck Security Advisory and the GitHub Pull Request #2406 for full details.

Workarounds

Enforce IP allow/block lists at an upstream reverse proxy or WAF that inspects both HTTP and WebSocket upgrade traffic.
Disable WebSocket routes in Ocelot configuration until the gateway is upgraded, where operationally feasible.
Apply network segmentation so downstream services fronted by Ocelot are not directly reachable from untrusted networks.

bash

# Example: block non-allowed source ranges at the perimeter for the Ocelot host
# Replace 203.0.113.0/24 with your allowed range
iptables -A INPUT -p tcp --dport 443 -s 203.0.113.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP