Feast Feature Server CVE-2026-23538

The exploit requires only network reachability to the Feature Server's /ws/chat WebSocket endpoint, which per the CVSS vector (PR:N/UI:N) accepts unauthenticated connections against affected default builds and requires no user interaction. The concrete prerequisite is that the vulnerable, unpatched Feature Server exposes /ws/chat on a network path the attacker can reach. What LIMITS exploitation: in most real deployments the Feature Server is not directly internet-facing but sits behind an ML-platform ingress or service mesh, so an attacker typically needs access to that internal network or a mis-scoped external route; the impact is availability-only (C:N/I:N) with no code execution or data access, and any patched instance enforces the 5-connection/rate/size limits that neutralize the flood.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent with the description: network-reachable, low-complexity, no privileges, no user interaction, and availability-only impact with zero confidentiality or integrity loss. This is a pure availability threat, not RCE or data exposure, so the 7.5 should be read as 'high nuisance/outage potential' rather than 'critical compromise.' No EPSS score, SSVC decision, KEV entry, or public POC was provided, so exploitation probability cannot be quantified from the input; the attack is trivially automatable in principle (a simple loop of WebSocket connects), which raises practical concern despite the absence of confirmed in-the-wild activity. Real priority is highest where the Feature Server is exposed to untrusted networks; in typical deployments it sits behind an ML platform's ingress, which meaningfully limits blast radius. Net: a genuine but availability-only issue - patch promptly, but it is not a data-breach emergency.

An attacker who can reach the Feature Server's HTTP port opens thousands of persistent connections to /ws/chat, none of which require credentials, and holds them open while streaming traffic. Server memory, CPU, and file descriptors are consumed until the process can no longer accept connections from legitimate ML applications, producing a sustained outage. No public POC is identified, but the attack requires only a scripted WebSocket client and low complexity (AV:N/AC:L).