Readarr

• Outcome: Pass
• Latest audit: Sep 11, 2026 · 5:20 PM UTC
• Version: 1.0.0

Overview

This skill is a straightforward Readarr API helper, but users should handle the API key carefully and review the Docker setup before using it.

Install only if you intend the agent to control your Readarr library. Store the API key using a safer secret-entry method than inline echo, avoid printing it, consider pinning the Docker image to a reviewed version or digest, and confirm before delete, queue removal, rescan, or all-missing-search operations.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: references/setup.md:10
• Finding: Mutable Development Container Image Creates a Supply-Chain Risk<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md`, lines 7–21; vulnerable image declaration at line 10 **Vulnerability Type**: Unpinned mutable third-party container image **Risk Level**: Medium ### Vulnerable Code ```yaml version: "3" services: readarr: image: lscr.io/linuxserver/readarr:develop container_name: readarr environment: - PUID=1026 - PGID=101 - TZ=Europe/Lisbon volumes: - /volume1/docker/readarr:/config - /volume1/Books:/books - /volume1/Downloads:/downloads ports: - 8787:8787 restart: unless-stopped ``` ### Technical Analysis The deployment uses the mutable `develop` tag without pinning the image to a reviewed version or immutable SHA-256 digest. The content associated with this tag can change after the Skill has been audited. Development tags also commonly receive less stable and less thoroughly reviewed updates than fixed release versions. Consequently, a future image pull may execute container code that differs from the code originally reviewed. This creates a supply-chain trust dependency on the image registry, publisher account, and all future updates assigned to the tag. The container receives persistent access to three host-backed volumes: - `/volume1/docker/readarr`, mounted as `/config` - `/volume1/Books`, mounted as `/books` - `/volume1/Downloads`, mounted as `/downloads` It also listens on host port 8787 and is configured to restart unless explicitly stopped. The Compose configuration does not mount the Docker socket or grant privileged mode, so direct host-root compromise is not established by the reviewed configuration. Nevertheless, a malicious image could access or alter the mounted data under the configured UID/GID permissions. ### Attack Path 1. An attacker compromises the image publisher, registry account, build pipeline, or mutable `develop` tag. 2. The attacker publishes a modified image under `lscr.io/linuxserver/readarr:deve ...[truncated 1110 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the `develop` tag with a reviewed stable release and pin it to an immutable digest: ```yaml image: lscr.io/linuxserver/readarr:<reviewed-version>@sha256:<verified-digest> ``` 2. Verify the digest against the publisher's authenticated release metadata before deployment. 3. Test new versions in an isolated environment before changing the pinned digest. 4. Use an update process that reviews image provenance, release notes, vulnerability scan results, and software bills of materials. 5. Consider enabling signature verification through an appropriate container-image policy mechanism. 6. Restrict the container's filesystem and runtime capabilities where compatible: - Mount data read-only where writes are unnecessary. - Drop unneeded Linux capabilities. - Apply `no-new-privileges`. - Restrict outbound network access. 7. Back up the mounted configuration and library data independently so that a compromised update cannot destroy the only available copy. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: references/setup.md:39
• Finding: API Key Entry Through a Shell Command Can Expose the Credential<![CDATA[ ## Vulnerability Details **File Location**: `references/setup.md`, lines 39–43 **Vulnerability Type**: Insecure plaintext secret entry and non-atomic permission hardening **Risk Level**: Medium ### Vulnerable Code ```bash echo "<api-key>" > ~/clawd/credentials/readarr_api_key chmod 600 ~/clawd/credentials/readarr_api_key ``` ### Technical Analysis The instructions encourage replacing `<api-key>` with the actual Readarr API key directly in a shell command. In an interactive shell, that command may be retained in shell history, terminal logging, session recording, audit logs, or command telemetry. This can leave a durable copy of the secret even though the destination file is later restricted to mode `600`. The destination file is also created before `chmod 600` is executed. Its initial permissions therefore depend on the user's current `umask`. With a permissive `umask`, another local account could potentially read the file during the interval before the permission change or if execution stops before `chmod` runs. Mode `600` is appropriate after it has been applied, and loading a purpose-specific API key is necessary for the Skill's declared Readarr functionality. The weakness concerns how the key is entered and how permissions are established, not the legitimate need to authenticate. ### Attack Path 1. The user replaces `<api-key>` with the real Readarr API key and runs the documented `echo` command. 2. The shell or surrounding environment records the command in history, a terminal transcript, an audit facility, or command telemetry. 3. Alternatively, the file is initially created with permissions derived from a permissive `umask`, and the permission-hardening command is delayed, interrupted, or never executed. 4. A local user, administrator of a logging platform, or attacker who later compromises the account retrieves the key from the retained command or temporarily exposed file. 5. The attacker sends requests with the `X-Api-Key` header to an ...[truncated 885 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Establish restrictive permissions before creating the credential file: ```bash umask 077 mkdir -p ~/clawd/credentials chmod 700 ~/clawd/credentials ``` 2. Read the key without displaying or embedding it in the command line: ```bash read -rsp "Readarr API key: " READARR_KEY printf '\n' printf '%s' "$READARR_KEY" > ~/clawd/credentials/readarr_api_key unset READARR_KEY ``` 3. Retain `chmod 600` as a defense-in-depth verification: ```bash chmod 600 ~/clawd/credentials/readarr_api_key ``` 4. Avoid passing the key through command-line arguments, clipboard automation, shared environment files, or shell-history-visible commands. 5. Prefer an operating-system credential manager or secret-management service where available. 6. Ensure backups, terminal logs, and telemetry do not collect the credential file or secret-entry sessions. 7. Rotate the API key immediately if it was previously entered inline or may have been logged. 8. Restrict Readarr network exposure to localhost or trusted private hosts and apply firewall controls so possession of the key alone is insufficient from untrusted networks. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (12)

External Script Fetching

High

• Category: Supply Chain

Content

### Find and add a book
```bash
# 1. Look up by title or ISBN
curl -s "$READARR_URL/api/v1/book/lookup?term=<title>" \
  -H "X-Api-Key: $READARR_KEY" | python3 -c "
import sys,json
books = json.load(sys.stdin)

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

External Script Fetching

High

• Category: Supply Chain

Content

"

# 2. Add it (need qualityProfileId + metadataProfileId from /api/v1/qualityprofile and /api/v1/metadataprofile)
curl -s -X POST "$READARR_URL/api/v1/book" \
  -H "X-Api-Key: $READARR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"foreignBookId":"<id>","monitored":true,"author":{...},"qualityProfileId":1,"metadataProfileId":1,"rootFolderPath":"/path/to/books","addOptions":{"searchForNewBook":true}}'

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

External Script Fetching

High

• Category: Supply Chain

Content

### Trigger a search
```bash
curl -s -X POST "$READARR_URL/api/v1/command" \
  -H "X-Api-Key: $READARR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"MissingBookSearch"}'

• Confidence: 90% confidence
• Finding: Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.

External Transmission

Medium

• Category: Data Exfiltration

Content

"

# 2. Add it (need qualityProfileId + metadataProfileId from /api/v1/qualityprofile and /api/v1/metadataprofile)
curl -s -X POST "$READARR_URL/api/v1/book" \
  -H "X-Api-Key: $READARR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"foreignBookId":"<id>","monitored":true,"author":{...},"qualityProfileId":1,"metadataProfileId":1,"rootFolderPath":"/path/to/books","addOptions":{"searchForNewBook":true}}'

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium

• Category: Data Exfiltration

Content

### Trigger a search
```bash
curl -s -X POST "$READARR_URL/api/v1/command" \
  -H "X-Api-Key: $READARR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name":"MissingBookSearch"}'

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The skill explicitly instructs the user to read an API key from a local credentials file without any warning about secret handling, redaction, or limiting exposure. In an agent context, documenting where secrets live and how to load them can normalize unsafe secret access and increase the chance that the key is echoed, logged, or reused in unintended contexts.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

restart: unless-stopped
```

Note: Synology Docker requires `sudo docker` (no docker group). Passwordless sudo for `/usr/local/bin/docker` is configured.

## First-Time Config (via web UI at http://192.168.42.79:8787)
1. Set root folder → `/books` (maps to Claptrap `/volume1/Books`)

• Confidence: 70% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## Credentials
```bash
echo "<api-key>" > ~/clawd/credentials/readarr_api_key
chmod 600 ~/clawd/credentials/readarr_api_key
```

## Prowlarr → Readarr sync

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Low

• Confidence: 88% confidence
• Finding: This markdown file lists a DELETE endpoint for removing a book, but provides no warning that the operation is destructive or may remove user-managed data. Under the markdown-file criteria, descriptions of behaviours affecting user data should include a warning or caution.

Missing User Warnings

Low

• Confidence: 87% confidence
• Finding: The API reference includes a DELETE endpoint to remove an author, which can affect monitored content and user library state, but no warning is provided. Markdown documentation should disclose potentially destructive operations that affect user data or system state.

Missing User Warnings

Low

• Confidence: 82% confidence
• Finding: The file documents deletion from the queue but does not warn users that this may interrupt or remove active download tasks. For markdown files, actions that affect system behavior or user-managed workflows should include a visible warning.

Missing User Warnings

Low

• Confidence: 71% confidence
• Finding: The command examples include actions like searching for all missing books and rescanning root folders, which may trigger broad changes or heavy system activity, but the documentation gives no cautionary context. Markdown descriptions should warn when actions can materially affect system behavior or generate substantial automated activity.

Static analysis

No suspicious patterns detected.