jack CVE-2026-62979

Requires possession of the shared peer API key sent as the X-Api-Key header (PR:L) - by design this is handed to every peered 'friend', and there is no inbound peer allowlist, so key possession is the only check. If the target deployment is gated behind Cloudflare Access, valid CF Access service-token headers are also required. The attacker then hits an endpoint that propagates FetchError to handle-error.ts - GET /peer/items/:id or GET /servers/health (leak the internal *arr X-Api-Key), or GET /torznab/download/:id (leaks another peer's key plus CF-Access-Client-Secret) - and forces an upstream non-2xx response (e.g., a 404 via a non-existent entity id) or a schema-validation failure. No user interaction and no race are needed. Limiting factors: exploitation is confined to holders of the shared peer key; the /peer/search and /items routes swallow the error and return [], so they are not affected; and the flaw is fully remediated only by upgrading to 0.1.0.

This is a genuine, high-value disclosure flaw for anyone actually running jack, tempered only by the product's tiny footprint. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:H/SA:N, 8.4) is internally consistent with the description: network-reachable, low attack complexity, no user interaction, and PR:L reflecting the shared peer API key every 'friend' already holds. The high subsequent-system impact (SC:H/SI:H) is well justified - the leaked internal X-Api-Key grants full administrative control of the backend Radarr/Sonarr, a deliberate trust boundary the architecture otherwise enforces. The GHSA advisory includes a concrete step-by-step PoC (force a 404 from *arr by requesting a non-existent entity id), so triggering is trivial and attacker-controlled with no race. No EPSS score is provided in the input and the issue is not in CISA KEV, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is 'this_week', indicating prompt-but-not-emergency remediation. The practical risk is bounded by who holds the peer key - by design a trusted-friends set with no inbound allowlist - rather than the open internet, which is why this is a real same-week priority for operators but not a mass-exploitation event. EPSS data is absent and should be checked to refine prioritization.

A peer who has been issued the shared jack API key (plus Cloudflare Access service-token headers if the instance is CF-gated) calls GET /peer/items/:id with a valid connector id from /peer/search but a non-existent entity id, forcing the upstream Radarr/Sonarr to return a 404. jack serializes the raw FetchError - including the outbound X-Api-Key header - into the HTTP response body, handing the peer the internal *arr admin key. A public PoC reference exists in the GHSA advisory demonstrating exactly this; it is not verified as working exploit code.