jack: upstream error responses expose backend and peer credentials
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 0.1.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
The jack project, a peer-to-peer tool for sharing media libraries through Radarr and Sonarr, is affected. Error responses from certain routes can leak internal backend API keys and connector credentials, such as Radarr/Sonarr keys and Cloudflare Access secrets, to any client holding the shared peer key, giving them full administrative control over those media servers and crossing the boundary between shared peer access and private backend credentials.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- roziscoding jack
fixed in 0.1.0
References 3
GitHub · roziscoding/jack
Questions about CVE-2026-62979
What does this mean?
When an upstream Radarr, Sonarr, or peer backend returns an error, jack passes the error details back to the caller. Those details can include the internal Radarr/Sonarr API key, and via the torznab download path, other peers' keys and Cloudflare Access client secrets.Source: github.com
Am I affected, and how do I check?
Affected versions are those before 0.1.0. The problem only shows up when a request reaches an upstream backend that returns an error, through GET /peer/items/:id, GET /torznab/download/:id, or GET /servers/health. An instance gated by Cloudflare Access also needs Access service-token headers for the request to reach those endpoints.Source: github.com
What should I do about it?
Upgrade jack to 0.1.0 or later, which contains the fix.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data