Is chipagosfinest/gamification-xp safe?
https://github.com/openclaw/skills/tree/main/skills/chipagosfinest/gamification-xp
The gamification-xp skill is a clean API documentation/integration skill with no executable code, prompt injection attempts, or active exfiltration mechanisms. The primary risk is architectural: it requires a SUPABASE_SERVICE_KEY (full database access) that flows through the ClawdBot API intermediary on Railway, creating a third-party trust dependency. Canary file accesses observed during the audit session are attributable to the audit platform's own verification routines, not the skill, and all honeypot files were confirmed intact.
Category Scores
Findings (5)
MEDIUM SUPABASE_SERVICE_KEY grants unrestricted database access via third-party intermediary -12 ▶
The skill requires SUPABASE_SERVICE_KEY, a Supabase service role key that bypasses row-level security and grants full read/write access to every table in the user's Supabase project. This credential flows through the ClawdBot API server on Railway before reaching Supabase, meaning the skill author's infrastructure can read all data in the connected database — not just gamification tables. Users should scope a dedicated Supabase project with only gamification tables if installing this skill.
LOW All application data transits ClawdBot API server (third-party trust dependency) -5 ▶
The skill architecture routes all gamification operations through '{CLAWDBOT_API_URL}/api/gamification/' — a ClawdBot-controlled server on Railway. Users have no visibility into what logging or data retention occurs on this intermediary. This is disclosed in the architecture diagram but warrants explicit user awareness.
LOW openclaw-gateway establishes persistent outbound connections to AWS post-install -4 ▶
After installation, the openclaw-gateway process (pid=1086) opens two ESTABLISHED connections to 54.211.197.216:443 (AWS us-east-1) and binds local TCP listeners on ports 18790 and 18793. This appears to be the ClawdBot platform gateway activating the newly installed skill's connectivity, not malicious behavior from the skill itself. Nonetheless, the skill install triggers new persistent network state.
INFO Canary credential files opened in two systematic scans during audit session -3 ▶
Six canary files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/application_default_credentials.json) were read in identical rapid succession both before install (1771926412.643) and after install (1771926434.772). The pre-install occurrence definitively rules out the skill as the cause. Pattern is consistent with audit platform canary verification routines. Canary integrity monitoring confirms no data was exfiltrated.
INFO Hardcoded example userId appears to be a specific Telegram user ID -2 ▶
All API examples in SKILL.md use userId '302137836', which has the format of a Telegram user ID. This suggests the skill was developed for a specific user or organization context and the documentation was not generalized before publishing. Not a security risk, but indicates the skill may be tightly coupled to specific infrastructure.