CVE-2026-23538: Feast Feature Server DoS Vulnerability

CVE-2026-23538 Overview

CVE-2026-23538 is a denial-of-service vulnerability in the Feast Feature Server's /ws/chat WebSocket endpoint. The endpoint accepts connections without performing authentication. Remote attackers can open many simultaneous persistent WebSocket connections and exhaust server memory, CPU, and file descriptors. Legitimate clients lose access once the server can no longer allocate resources for new sessions. The issue is tracked under CWE-770: Allocation of Resources Without Limits or Throttling and was disclosed through the Red Hat data services fork of Feast.

Critical Impact
Any unauthenticated network attacker can render the Feast Feature Server unavailable by holding open a large number of WebSocket connections against /ws/chat.

Affected Products

Feast Feature Server (upstream project)
Red Hat OpenShift AI / Red Hat Data Services distributions bundling Feast
Deployments exposing the /ws/chat WebSocket endpoint to untrusted networks

Discovery Timeline

2026-07-16 - CVE-2026-23538 published to the National Vulnerability Database
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-23538

Vulnerability Analysis

The Feast Feature Server exposes a chat interface backed by a WebSocket route at /ws/chat. The handler upgrades incoming HTTP requests to WebSocket sessions without requiring credentials, tokens, or any form of client validation. Each accepted session consumes server-side state including a socket, buffered send/receive queues, and an application task.

Because no per-client connection cap or global concurrency limit exists on this route, an attacker can script clients that repeatedly open new WebSocket connections and keep them alive. As accepted sessions accumulate, the process consumes additional memory, event-loop time, and operating-system file descriptors. Once the operating system limit on open descriptors is reached, or memory pressure triggers allocator failures, the server can no longer service legitimate feature-serving traffic.

The defect is a pure availability issue. Confidentiality and integrity of stored feature data are not affected, and no code execution or data disclosure is possible through this vector.

Root Cause

The root cause is missing resource governance on an unauthenticated endpoint, classified as CWE-770. The /ws/chat handler does not authenticate the peer, does not rate-limit new connections per source, and does not bound the total number of concurrent WebSocket sessions. The upstream fix is tracked in the Red Hat data services Feast pull request.

Attack Vector

Exploitation requires only network reachability to the Feature Server. An attacker sends repeated WebSocket upgrade requests to /ws/chat from one or more source addresses and does not close the returned sessions. Each open session pins server resources. Scaling the attack across multiple sources amplifies file-descriptor and memory pressure and shortens time to outage.

No verified public exploit code is available for CVE-2026-23538. See the Red Hat CVE advisory and the Red Hat bug report for vendor technical details.

Detection Methods for CVE-2026-23538

Indicators of Compromise

Sudden growth in the count of established WebSocket sessions terminating at the Feature Server on /ws/chat.
Rising open file-descriptor counts on the Feast process without a matching rise in feature-serving request rates.
Repeated HTTP 101 Switching Protocols responses from /ws/chat to a small set of source IPs or ASNs.
Feature Server health checks failing or timing out while CPU and RSS climb toward configured limits.

Detection Strategies

Instrument the reverse proxy or ingress in front of Feast to log WebSocket upgrade requests and alert on high per-source connection counts to /ws/chat.
Track process-level metrics (open_fds, resident memory, active tasks) for the Feature Server and alert on sustained deviation from baseline.
Correlate WebSocket connection rate with authenticated API traffic; unauthenticated upgrade floods should stand out.

Monitoring Recommendations

Emit and retain access logs for /ws/chat including source IP, user agent, and session duration.
Export container and pod resource metrics to a central store so exhaustion events can be reconstructed after an outage.
Alert on file-descriptor utilization crossing 70% of the configured ulimit for the Feast process.

How to Mitigate CVE-2026-23538

Immediate Actions Required

Restrict network exposure of /ws/chat so only trusted client networks or service meshes can reach it.
Place the Feature Server behind a reverse proxy that enforces authentication and per-IP connection limits on WebSocket upgrades.
Lower operating-system and application connection limits to fail fast rather than degrade under flood conditions.
Track upstream Feast releases and the Red Hat data services pull request for the merged fix.

Patch Information

Red Hat is tracking remediation in Bugzilla 2429311 and via the Red Hat VEX document. The proposed code change lives in the red-hat-data-services/feast PR #192, which adds authentication and connection controls to the WebSocket endpoint. Apply vendor updates once released and rebuild any container images that embed Feast.

Workarounds

Disable the /ws/chat route in deployments that do not use the chat feature.
Enforce mutual TLS or an authenticating gateway (for example, an OAuth2 proxy) in front of the Feature Server.
Apply per-source connection rate limits and total concurrent WebSocket caps at the ingress layer (NGINX limit_conn, Envoy max_connections, or equivalent).
Run Feast under a systemd unit or container with a low LimitNOFILE so exhaustion is contained to the single workload.

bash

# Configuration example: NGINX ingress limits for the Feast /ws/chat endpoint
http {
    limit_conn_zone $binary_remote_addr zone=ws_per_ip:10m;

    server {
        listen 443 ssl;
        server_name feast.example.internal;

        location /ws/chat {
            limit_conn ws_per_ip 5;
            proxy_pass http://feast_backend;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_read_timeout 60s;
            proxy_send_timeout 60s;
        }
    }
}