Jellyseerr
PassAudited by VirusTotal on May 12, 2026.
Overview
Type: OpenClaw Skill Name: jellyseerr Version: 1.0.0 The skill is classified as suspicious due to its use of high-risk capabilities, including establishing persistence via `crontab` modification (`SKILL.md`, `scripts/auto_monitor.sh`) and creating systemd services with `sudo` (`scripts/install_service.sh`, `scripts/setup_webhook.sh`). It also opens a network port (`0.0.0.0:8384`) using `scripts/webhook_server.py` to receive incoming webhooks. While these actions are plausibly required for the stated purpose of automated media requests and notifications, they represent significant system modifications and network exposure.
Findings (0)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
Anyone who can reach the port may be able to send fake Jellyseerr webhook events, creating notification spam or injecting misleading content into the notification queue.
The webhook receiver listens on all network interfaces and processes POST bodies directly, with no shared secret, signature validation, source allowlist, or path token shown.
server = HTTPServer(('0.0.0.0', port), WebhookHandler) ... data = json.loads(body) ... if notification_type == 'MEDIA_AVAILABLE':Expose the webhook only to the Jellyseerr server, use firewall allowlists or a reverse proxy with authentication, and add a shared secret or signature check before queuing notifications.
A forged webhook could leave misleading or adversarial text in the pending notification file for a later agent run to send or act on.
Queued notification text is later emitted in a tool-like format for an agent/message workflow; because the webhook queue can be populated from external POST data, untrusted content can persist and be reused later.
This script is meant to be called from Clawdbot context with message tool access. ... print(f"SEND_MESSAGE:{notif['message']}")Treat queued notification contents as untrusted, sanitize message fields, restrict who can write to the queue, and require user review before sending externally sourced notifications.
The webhook server can continue running after the initial setup and may keep accepting notifications until the service is stopped or removed.
The setup creates a persistent systemd service that starts immediately and is enabled at boot; this is disclosed and purpose-aligned for webhook notifications.
sudo systemctl enable ${SERVICE_NAME}
sudo systemctl start ${SERVICE_NAME}Install the service only if you want persistent notifications, and use the documented systemctl stop/disable commands when you no longer need it.
Anyone who can read the config file may be able to use your Jellyseerr API key to search or request media depending on that key's permissions.
The skill stores a Jellyseerr API key locally for later API calls. This is expected for the integration and the file is restricted to the user, but it is still account authority.
read -p "Enter your API key: " API_KEY ... "api_key": "$API_KEY" ... chmod 600 "$CONFIG_FILE"
Use the least-privileged Jellyseerr API key available, keep the config file private, and rotate the key if the machine or file is shared.
Invoking the request scripts can change Jellyseerr state and may start a media acquisition workflow on the connected server.
The skill can submit media requests to Jellyseerr, which is the stated purpose, but it is a mutating action that may trigger downloads or approvals on the user's media server.
url = f"{config['server_url']}/api/v1/request" ... response = requests.post(url, headers=headers, json=data)Review the selected search result before confirming requests, avoid using --auto unless you are comfortable with the first-result selection, and ensure Jellyseerr approval settings match your preferences.