Podgrab EUVD-2026-91004

Requires only network reachability to Podgrab's WebSocket endpoint (/ws); no authentication, no user interaction, and no non-default configuration are needed, matching the PR:N/UI:N/AT:N vector. The limiting factors are deployment-related rather than technical: Podgrab must be running and its /ws endpoint must be reachable by the attacker (e.g., internet-exposed or reachable on the LAN), and exploitation depends on sustaining enough concurrent connections and message traffic to win the race on the unsynchronized maps. Impact is restricted to availability - the process crashes and requires manual operator restart - with no data exposure or integrity effect.

This is a genuine availability-only risk with a plausibly easy trigger, but its absolute priority is tempered by the product's limited footprint. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) is internally consistent with the description: a remote, unauthenticated attacker reaches the /ws endpoint over the network with no special conditions, and the impact is confined to availability (VA:H) with no confidentiality or integrity effect (VC:N/VI:N) - correctly matching a CWE-362 data-race crash rather than code execution, so the 8.7 score reflects a high-impact DoS, not a critical compromise. No EPSS score, no CISA KEV listing, and no SSVC decision data were provided, so widespread or automated exploitation cannot be asserted from the signals at hand. The reporting advisory (VulnCheck) plus a referenced gist suggest exploit methodology is at least partially public, which raises practical likelihood, but the gist is not explicitly labeled as working exploit code in the input, so POC availability is unconfirmed. Net: treat as a real, low-effort DoS worth patching promptly where Podgrab is internet-exposed, but it is not a mass-exploitation emergency - the main dampener is deployment scale, not difficulty, since a data race under concurrent WebSocket load is typically easy to provoke.

An attacker who can reach a Podgrab instance's /ws endpoint opens many concurrent WebSocket connections and sends messages in a tight loop, driving the Wshandler and HandleWebsocketMessages goroutines to read and write the shared activePlayers and allConnections maps simultaneously. The resulting Go runtime data race causes the process to crash, taking the service offline until an operator manually restarts it. The low attack complexity and lack of authentication or user interaction make this trivially repeatable, and a referenced public gist appears to document the technique.