Description

Podgrab contains a missing authentication vulnerability in which the /ws WebSocket route is registered on the root gin engine instead of the BasicAuth-protected router group, allowing unauthenticated network clients to connect even when PASSWORD is configured. Attackers can join the allConnections set, capture PlayerExists broadcasts containing client-supplied player identifiers, and replay them in a RegisterPlayer message to hijack queue payloads intended for authenticated users, exposing episode IDs, titles, and server-side file paths while potentially disrupting legitimate playback.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-10-01T19:17:19.320Z",
  "pubdate": "2026-10-01T19:17:19.320Z",
  "executiveSummary": "Podgrab suffers from a critical authentication bypass vulnerability due to an improper configuration of the /ws WebSocket route within the Gin web framework. Although the application supports Basic Authentication via the PASSWORD configuration, the WebSocket endpoint is explicitly registered on the root gin engine rather than the protected router group. This architectural error allows unauthenticated network clients to establish full-duplex communication with the server, effectively nullifying intended access control mechanisms. The vulnerability permits unauthorized remote actors to interface with the application's internal event bus. By successfully connecting to the /ws route, an attacker can monitor sensitive internal broadcasts, hijack session-specific queue payloads, and exfiltrate internal metadata, including episode titles and server-side file paths. The exposure of these identifiers enables arbitrary replay attacks and potential disruption of legitimate playback services. Given that the vulnerability resides in the core routing logic, any deployment relying on the built-in password protection is considered compromised. The risk to confidentiality and integrity is high, as the application fails to enforce authentication for a highly sensitive interface, granting unauthenticated users the same visibility into real-time playback synchronization as authorized administrators.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper route registration pattern within the application's initialization logic. In the Gin web framework, route groups are utilized to apply middleware, such as BasicAuth, to specific endpoints. However, the /ws WebSocket route has been incorrectly bound directly to the base gin.Engine object instead of the protected router group. This design oversight bypasses the middleware chain entirely, rendering the BasicAuth configuration ineffective for WebSocket upgrade requests.\nThe exploitation flow begins with the attacker initiating a standard HTTP GET request with an Upgrade header to the /ws endpoint. Because no authentication check is enforced at the routing level, the server completes the WebSocket handshake successfully. Once the connection is established, the attacker joins the allConnections set, which is the internal registry for broadcast distribution. By subscribing to the message stream, the attacker passively monitors the server's state.\nThe attacker specifically targets PlayerExists broadcasts. These messages contain client-supplied player identifiers that are necessary for queue synchronization. By capturing these identifiers, an attacker can perform a RegisterPlayer message injection. The vulnerability allows the attacker to associate their unauthorized WebSocket session with an existing player ID. By spoofing these identifiers, the attacker effectively hijacks the payload flow intended for legitimate users. This hijacking allows the attacker to exfiltrate private episode IDs and local file paths stored on the server's filesystem, which are transmitted within these message frames.\nThe impact of this manipulation is twofold: First, information disclosure regarding the library structure and file system architecture. Second, service disruption; the attacker can issue conflicting commands to the queue, causing playback desynchronization or forced skips for the actual user. Since this vulnerability does not require any credentials and is accessible over the network to any host with access to the service port, it represents a total failure of the authentication boundary for the WebSocket subsystem. The lack of validation on the Origin header or session tokens during the WebSocket lifecycle further exacerbates the vulnerability, as it does not enforce stateful verification once the initial upgrade request is processed."
}