CVE-2026-62979 in jack
Summary
by MITRE • 10/30/2026
jack lets users share media libraries through their Radarr/Sonarr stack, peer-to-peer. Prior to 0.1.0, `middleware/handle-error.ts` serializes raw `FetchError` objects into HTTP responses. `lib/servers/base.ts` attaches outbound request headers on upstream non-success responses and schema-validation failures; the public `extras` field in `lib/errors/FetchError.ts` remains enumerable and is emitted by JSON serialization. These headers include the internal Radarr/Sonarr `X-Api-Key` and custom connector headers such as `CF-Access-Client-Secret`. `lib/redact.ts` redacts logs and spans but not this response path. Any client with the shared peer API key, plus Cloudflare Access credentials if required by the deployment, can force an error without a race or user interaction. `GET /peer/items/:id` and `GET /servers/health` can expose the internal media-server key, while `GET /torznab/download/:id` can expose another peer's key and Cloudflare Access secrets. The /peer/search and /items routes catch these errors and are not affected. Disclosed internal keys grant full administrative control of the corresponding Radarr/Sonarr instance, crossing the intended boundary between friends' shared peer access and private backend credentials. This issue is fixed in version 0.1.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified involves a critical information disclosure flaw within the Jack application, specifically affecting versions prior to 0.1.0. The core of this security failure lies in how the application handles errors during peer-to-peer media library sharing operations through Radarr and Sonarr stacks. When an error occurs during upstream requests to these backend services or when schema validation fails, the middleware responsible for handling errors serializes raw FetchError objects directly into HTTP responses. This serialization process inadvertently exposes sensitive internal data that was intended to remain confidential within the application's operational boundary.
The technical root cause is rooted in the structure of the error handling logic found in lib/servers/base.ts and lib/errors/FetchError.ts. When an upstream request results in a non-success response or fails schema validation, the system attaches outbound request headers to the error object for debugging purposes. Among these attached fields is the public extras field from FetchError, which remains enumerable during JSON serialization. Consequently, this data structure includes sensitive authentication credentials such as internal Radarr and Sonarr X-Api-Key values, as well as custom connector headers like CF-Access-Client-Secret used by Cloudflare Access for identity verification. Although other parts of the application utilize lib/redact.ts to sanitize logs and telemetry spans, this specific response serialization path was overlooked, allowing these secrets to be transmitted back to the client in plaintext within the HTTP response body.
The operational impact of this vulnerability is severe due to its ease of exploitation and high privilege escalation potential. An attacker does not need to exploit a race condition or require any form of user interaction to trigger the error state. By simply sending specific requests that induce upstream failures, an authenticated peer can force the application to return these sensitive headers in the response payload. Specific endpoints such as GET /peer/items/:id and GET /servers/health are vulnerable when interacting with internal media servers, potentially exposing the administrative API key of a Radarr or Sonarr instance. Similarly, requests directed at GET /torznab/download/:id can expose another peer's API key along with Cloudflare Access secrets if such infrastructure is in use. The routes for /peer/search and /items are not affected as they implement different error handling logic that does not serialize the raw error object.
This information disclosure leads to a complete compromise of backend services, effectively crossing the intended security boundary between shared peer access and private administrative credentials. Possession of an internal X-Api-Key grants full administrative control over the corresponding Radarr or Sonarr instance, allowing an attacker to modify media libraries, download sensitive content, or potentially execute further attacks against the underlying infrastructure. This represents a significant breach of confidentiality and integrity within the application's architecture. The vulnerability is classified under CWE-209: Generation of Error Message Containing Sensitive Information and aligns with ATT&CK technique T1530: Data from Cloud Storage Object, as it involves exfiltrating configuration secrets that control access to stored data services.
The issue has been resolved in version 0.1.0 by ensuring that sensitive headers are not included in the serialized error responses sent to clients. To mitigate this risk for any deployments still running older versions, immediate upgrade is strongly recommended. Additionally, organizations should audit their API key management practices and rotate all exposed Radarr/Sonarr keys and Cloudflare Access secrets immediately upon discovery or patching, as these credentials may have been compromised during the window of vulnerability exposure.