Skillv2.0.2

ClawScan security

Lota Football · ClawHub's context-aware review of the artifact, metadata, and declared behavior.

Scanner verdict

SuspiciousApr 24, 2026, 3:54 AM

Verdict: suspicious
Confidence: high
Model: gpt-5-mini
Summary: The skill appears to do what its description says (fetch and cache football data), but there are multiple inconsistencies and insecure defaults you should understand before installing (missing declared requirements, plaintext default API URL, and a cron example that exposes the API key).
Guidance: This skill appears to implement a legitimate football-data fetcher, but several red flags and insecure defaults need attention before installation: - Required secrets/binaries: The scripts require LOTA_API_KEY (and optionally LOTA_API_BASE_URL, LOTA_DATA_DIR) and the fetcher requires jq, bc, awk. The registry metadata incorrectly lists none — ask the publisher to correct that. - Insecure default endpoint: The default BASE_URL is http://deepdata.lota.tv (HTTP). Unless you explicitly set LOTA_API_BASE_URL to an HTTPS endpoint, your API key will be sent in plaintext. Change the base URL to use HTTPS or verify the host's TLS support. - Cron/secret exposure: The example cron entry embeds LOTA_API_KEY directly in the crontab line. Crontab entries are often readable by system users; avoid embedding secrets there. Prefer a protected environment file (with tight file perms), a systemd timer that reads a protected unit environment, or a secrets manager. - File writes and permissions: The scripts create skills/lota_data/ and write JSON and logs. Ensure the directory location and permissions are appropriate for your environment so sensitive data (API keys, logs) is not broadly readable. - Verify the API host: deepdata.lota.tv is the default API host; confirm this is the legitimate service you intend to use before supplying an API key. - Operational dependencies: If you plan to run the periodic fetcher, install and audit jq, bc, and awk as required. Test in a sandbox first. If you are not comfortable changing the default BASE_URL to HTTPS or avoiding exposing the key in crontab, do not install or run the periodic fetcher. Ask the skill author to (1) declare LOTA_API_KEY and required binaries in the registry metadata, (2) default to an HTTPS endpoint, and (3) provide a secure example for scheduling that does not expose secrets in crontab.

Review Dimensions

Purpose & Capability: noteThe scripts and SKILL.md align with the stated purpose (query match lists and compact feature reports). However the registry metadata declares no required environment variables or binaries while the scripts clearly require LOTA_API_KEY and (for the fetcher) jq, bc and awk — a metadata mismatch that reduces transparency.
Instruction Scope: okRuntime instructions restrict actions to reading/writing local cache files and calling the included bash scripts / the Lota API. There is no instruction to read unrelated system files or export other credentials. The SKILL.md specifically mandates checking local cache before making API calls, which is within scope.
Install Mechanism: okThere is no install spec (instruction-only with shipped scripts), so nothing is downloaded at install time. Scripts are plain bash and readable; no obfuscated or remote install steps were found.
Credentials: concernThe skill requires an API key (LOTA_API_KEY) and optionally LOTA_API_BASE_URL and LOTA_DATA_DIR, but the registry metadata lists none. The fetch script enforces jq, bc, and awk; two scripts earlier claim only curl/jq optional. Default BASE_URL uses plain HTTP (http://deepdata.lota.tv), meaning the API key would be sent in cleartext unless you override the base URL to HTTPS — an insecure default. The SKILL.md also shows a cron line that embeds the API key directly in crontab, which makes the secret visible to anyone with read access to the crontab file.
Persistence & Privilege: notealways:false and model invocation are normal. The scripts write cache and metadata under a local data directory (default skills/lota_data/). The skill suggests adding a cron job; scheduling itself is not automatic, but following that guidance would persist data and periodically call the remote API. No code modifies other skills or system-wide agent settings.