GHSA-xv8g-fj9h-6gmv: Missing Authentication in Linkdave Audio Streaming Server

Linkdave operates as a Go-based audio streaming server, designed as a lightweight alternative to Lavalink. The application relies on a control plane consisting of a REST API and a WebSocket endpoint to manage audio playback, session state, and connected guilds. This control plane is exposed over network ports, typically 8080 or 18080, to receive commands from the primary bot application.

The core vulnerability is classified as CWE-306 (Missing Authentication for Critical Function). Prior to the patch, Linkdave did not implement any authentication or identity verification mechanisms on its network endpoints. The server accepted and processed commands from any inbound connection capable of reaching the listening port.

This architectural omission exposes the entire audio streaming infrastructure to unauthorized access. Any remote actor with network routing to the Linkdave instance can issue administrative commands. The lack of network-level identity checks means the application implicitly trusts all traffic arriving at its designated control ports.

The root cause of this vulnerability lies in the initial design of the server's HTTP multiplexer and request routing logic. The application utilizes Go's standard http.ServeMux to handle inbound requests for both the REST endpoints and the WebSocket upgrade path. The developers omitted any middleware or handler logic responsible for validating access tokens or session credentials.

In the cmd/linkdave/main.go and server/server/routes.go files, the application defines routes such as /ws and various REST paths. The application wraps REST routes with a withSession middleware function. However, this middleware only extracts the session and guild identifiers from the URL path parameters to construct the operational context. It performs no validation to ensure the requester is authorized to interact with those specific identifiers.

Similarly, the server/server/websocket.go file contains the HandleWebSocket function. This function executes the HTTP-to-WebSocket upgrade using the Gorilla WebSocket library (or similar standard implementations). The upgrade process proceeds unconditionally, granting the requester a persistent, bidirectional communication channel for issuing JSON payloads. The failure to enforce an authentication handshake prior to or during this upgrade process constitutes the primary technical flaw.

Prior to the patch, the application routing blindly accepted connections. The patch, introduced in commit 0f9a00d9d549b16278db81fce6dfec350c2abc01, implements a shared-secret authentication model using a new environment variable, LINKDAVE_PASSWORD. The implementation modifies both the HTTP middleware and the WebSocket handler to enforce identity verification.

The withSession middleware was updated to inspect incoming REST requests for an Authorization header. The server extracts the provided Bearer token and compares it against the configured LINKDAVE_PASSWORD. If the token is missing or incorrect, the server returns an HTTP 401 Unauthorized status code.

For the WebSocket endpoint, the HandleWebSocket function now parses the URL query parameters during the initial HTTP request phase of the upgrade. It specifically looks for a password parameter. The server compares this parameter to the shared secret, rejecting the upgrade if the values do not match.

Despite resolving the immediate vulnerability, the patch introduces several residual security risks. The comparison logic relies on standard Go string comparison (!=), which is not constant-time and theoretically exposes the endpoint to timing side-channel attacks. Furthermore, transmitting the shared secret via a URL query parameter (?password=...) for the WebSocket connection risks credential exposure. Reverse proxies and load balancers routinely log complete request URLs, including query parameters, potentially writing the plaintext password to disk.

Exploitation of this vulnerability requires no specialized tools beyond a standard network scanner and a WebSocket client. An attacker begins by identifying an exposed Linkdave instance. This is typically achieved by scanning external IP ranges for open TCP ports 8080 or 18080, followed by sending a basic HTTP GET request to verify the service signature.

Once a target is confirmed, the attacker initiates a WebSocket connection to the /ws endpoint. They can utilize standard command-line tools like wscat or write a custom script leveraging the official Linkdave TypeScript client library (version 0.1.4 or earlier). The server accepts the connection immediately without requiring any handshake payloads or headers.

With the connection established, the attacker gains full control over the session state. They can transmit JSON payloads defining commands to join arbitrary voice channels, play unapproved audio streams, or forcefully disconnect legitimate users. Concurrently, the attacker can issue HTTP GET requests to the REST API to enumerate active sessions and extract guild metadata, facilitating targeted disruption.

The missing authentication vulnerability yields complete administrative control over the Linkdave instance to any network-adjacent or remote attacker. While this flaw does not provide direct operating system-level remote code execution, it entirely compromises the integrity and availability of the application's primary function. Attackers can arbitrarily control audio playback across all connected Discord guilds.

The vulnerability enables severe denial-of-service conditions. An attacker can systematically enumerate and terminate all active streaming sessions, rendering the bot non-functional for legitimate users. Furthermore, the attacker can command the server to initiate high-bandwidth external connections to download malicious or excessively large audio files, leading to resource exhaustion and potential network saturation.

Additionally, the flaw introduces a significant privacy risk through metadata exposure. By querying the unauthenticated REST endpoints, an attacker can map the bot's deployment footprint. They can extract session identifiers, guild IDs, and active player states, leaking sensitive operational data about the bot's user base and infrastructure scale.

Organizations deploying Linkdave must immediately update their Go server instances to include commit 0f9a00d9d549b16278db81fce6dfec350c2abc01 or newer. Simultaneously, the corresponding client applications must be updated to utilize the linkdave TypeScript library version 0.1.5 or higher, which supports the transmission of the required authentication credentials.

Applying the software update is insufficient without proper configuration. System administrators must explicitly define the LINKDAVE_PASSWORD environment variable using a cryptographically secure, randomly generated string. The server is designed to maintain backward compatibility; if this variable is left undefined or empty, the application falls back to its insecure, unauthenticated state.

To mitigate the residual risks associated with the patch implementation, network-level defenses are mandatory. The Linkdave instance must be isolated from the public internet using strict firewall rules, permitting inbound connections exclusively from the primary application server. Furthermore, Linkdave should be deployed behind a reverse proxy configured for TLS termination. This ensures that the WebSocket query parameters and REST authorization headers are encrypted in transit, preventing credential interception over the wire.