The CVE describes a WebSocket fragmentation attack causing OutOfMemoryError, but the critical dimension isn't the vulnerability itself—it's the deceptive configuration parameter that preceded it. maxWebSocketBufferSize is named to imply it bounds total WebSocket buffer consumption, but it actually constrains only individual frame payloads. Any operator who set this parameter believing they've hardened their deployment has received positive validation while remaining fully exposed. This is a design-level failure, not merely an implementation bug, and it matters because operators who believed they'd addressed the risk are precisely those who won't realize they're still exposed.
The attack mechanics amplify the risk. Continuation frames carry per-frame JVM object overhead—headers, allocation metadata, internal buffer wrappers. A modest stream of tiny fragments, each individually compliant with maxWebSocketBufferSize, drives disproportionate heap consumption. The attacker needs patience, not bandwidth, and individual frames appear innocent to traffic analysis.
The severity vector is where most defenders will underestimate this. The OutOfMemoryError occurs on the blaze selector thread, which is the load-bearing structure for ALL connections on that server instance. One malicious WebSocket client doesn't just impact their own traffic—they collapse the event loop that every concurrent WebSocket and HTTP connection shares. In Kubernetes deployments with multiple services per node, selector thread death triggers liveness probe failures, pod restarts, connection pool drainage, and potential thundering herd on surviving replicas. This is operationally a severity-9 event masquerading as CVSS 7.5.
The fix in 0.23.18 and 1.0.0-M42 presumably adds aggregate tracking, but verify what changed: a total-message byte limit, fragment count limit, timeout-based cleanup, or combination? More importantly, confirm whether the fix changes failure behavior from silent enforcement to explicit rejection with logged warnings—operators need negative feedback when they've hit a limit, not just silent truncation. If the patch introduces a new configurable parameter without changing the failure mode, the deception has relocated rather than resolved.