{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","favicon":"https://feed.craftedsignal.io/favicon-32x32.png","feed_url":"https://feed.craftedsignal.io/vendors/podgrab/feed.json","home_page_url":"https://feed.craftedsignal.io/","icon":"https://feed.craftedsignal.io/apple-touch-icon.png","items":[{"_cs_actors":[],"_cs_cpes":["cpe:2.3:a:podgrab:podgrab:*:*:*:*:*:*:*:*"],"_cs_cves":[{"cvss":7.5,"id":"CVE-2026-104057"}],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Podgrab"],"_cs_severities":["low"],"_cs_tags":["denial-of-service","vulnerability","web-application"],"_cs_type":"advisory","_cs_vendors":["Podgrab"],"content_html":"\u003cp\u003ePodgrab contains a high-severity denial-of-service vulnerability (CVE-2026-104057) originating from unsynchronized concurrent access to shared memory maps. Specifically, the 'activePlayers' and 'allConnections' maps within the application's WebSocket handler are accessed simultaneously by 'Wshandler' and 'HandleWebsocketMessages' goroutines without the use of a mutex or other synchronization primitives. Because the Go runtime panics when concurrent read and write operations are detected on maps, a remote attacker can intentionally trigger this condition. By opening multiple WebSocket connections to the /ws endpoint and flooding the service with messages in a loop, an attacker forces a data race that crashes the entire Podgrab process. The resulting crash requires manual operator intervention to restart the service, making this a persistent denial-of-service condition for exposed instances.\u003c/p\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows an unauthenticated remote attacker to crash Podgrab instances, leading to a complete denial of service. The impact is significant for users relying on Podgrab for media management, as the service becomes unavailable until a manual restart occurs. There is no information currently regarding victim count, but any internet-facing Podgrab instance is at risk of disruption.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cp\u003ePrioritized actions for administrators and detection engineers:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMonitor webserver logs for anomalous high-frequency WebSocket traffic originating from a single source to the /ws endpoint.\u003c/li\u003e\n\u003cli\u003ePatch Podgrab immediately upon the release of a security update that implements proper mutex locking for the 'activePlayers' and 'allConnections' maps.\u003c/li\u003e\n\u003cli\u003eImplement rate limiting or connection limits on the /ws endpoint at the reverse proxy or firewall level to mitigate the ease of triggering the crash until a patch is applied.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-10-01T20:23:51Z","date_published":"2026-10-01T20:23:51Z","id":"https://feed.craftedsignal.io/briefs/2026-10-podgrab-dos/","summary":"Podgrab is vulnerable to an unauthenticated denial-of-service attack where an attacker can trigger a Go runtime crash by exploiting unsynchronized concurrent access to shared maps in the WebSocket handler.","title":"Unauthenticated Denial of Service in Podgrab via WebSocket Data Race","url":"https://feed.craftedsignal.io/briefs/2026-10-podgrab-dos/"}],"language":"en","title":"CraftedSignal Threat Feed - Podgrab","version":"https://jsonfeed.org/version/1.1"}