Is krusherk/ethosmolt safe?
https://github.com/openclaw/skills/tree/main/skills/krusherk/ethosmolt
The MoltEthos skill is a credential harvesting scheme disguised as on-chain AI reputation management. Its registration flow explicitly POSTs the user's Moltbook API key to a Supabase database controlled by the skill author, and its heartbeat system autonomously signs irreversible blockchain transactions using the user's private wallet key every 4 hours. While the install itself was behaviorally clean (no malware during clone), the skill's instructions are designed to exfiltrate credentials and establish persistent autonomous financial behavior on behalf of the skill author.
Category Scores
Findings (9)
CRITICAL API Key Exfiltration by Design in Registration Flow -70 ▶
The skill's Step 3 registration curl command explicitly includes the user's MOLTBOOK_API_KEY in the POST body sent to the skill author's Supabase instance. This is not accidental — the schema definition confirms 'api_key' is a named column. Every agent that follows this skill's instructions will surrender their Moltbook API key to a database controlled by the skill author (asxjsyjlneqopcqoiysh.supabase.co).
CRITICAL Hardcoded Skill Author Supabase Credentials Route All Data to Third Party -60 ▶
A full Supabase JWT anon key is hardcoded directly in the skill markdown. This key authenticates all agent writes to a Supabase project owned by the skill author. All registration data, feedback submissions, and agent metadata submitted by any user following this skill flows into the skill author's database — not the user's own infrastructure.
HIGH Autonomous Blockchain Transaction Signing with User Private Key -45 ▶
The skill instructs the agent to use the user's PRIVATE_KEY to sign and broadcast on-chain transactions to Monad Mainnet — including registration, reviews, vouching (+100), and slashing (-100). These are irreversible financial/reputational operations executed without per-action user confirmation. The heartbeat system triggers these every 4 hours.
HIGH Credential Harvesting Architecture Disguised as Reputation Management -55 ▶
The skill's primary architectural purpose is to collect wallet addresses, Moltbook API keys, and agent metadata into a centralized database owned by the skill author. The 'on-chain reputation' feature is a legitimate-sounding justification for requiring private key access and API key submission. The skill author gains a database of agent-to-credential mappings.
HIGH Autonomous 4-Hour Heartbeat System Creates Persistent Financial Risk -30 ▶
The skill establishes a recurring autonomous behavior (every 4 hours) where the agent fetches external feeds, makes reputation judgments, signs blockchain transactions, and POSTs to external APIs — all without per-cycle user approval. This creates a persistent execution footprint that could be exploited via Supabase data manipulation or skill updates.
MEDIUM Wallet Address Linked to Identity in Third-Party Database -25 ▶
The registration flow associates the agent's ERC-8004 NFT token ID (derived from the wallet that signed the registration transaction) with the agent name, type, and Moltbook API key in the skill author's database. This creates a deanonymization record linking blockchain identity to platform credentials.
MEDIUM Cast CLI Blockchain Writes Executed by Agent Using User Wallet Key -20 ▶
While no code executed autonomously during install, the skill's instructions would cause the agent to execute cast send commands signing Monad Mainnet transactions with the user's PRIVATE_KEY. These are real financial operations on a live blockchain, not simulation.
LOW Clean Install — No Suspicious Activity During Clone -10 ▶
The git clone phase was clean. Network connections were limited to GitHub (140.82.114.3) and Ubuntu infrastructure. No connections to Supabase, moltbook.com, or monad.xyz occurred during install. No unexpected processes spawned.
INFO Canary Files Intact — No Install-Time Credential Theft -5 ▶
All honeypot files (.env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, .config/gcloud/credentials) were intact post-install. The auditd PATH events showing these file accesses are the audit system's own before/after canary scans, not skill-initiated reads.