Moltbook Engagement

Battle-tested toolkit for Moltbook platform engagement. Use when: (1) Posting or commenting on Moltbook with built-in deduplication protection, (2) Scanning...

This skill generally does what it says (posting, scanning, metrics) but the included Python scripts do more than the doc advertises: they attempt to load OPENAI_API_KEY and REDIS_PASSWORD from env or from local auth files, read .secrets-cache.json, and even try to contact a hard-coded internal Redis IP (10.0.0.120) via raw sockets. Before installing or running: (1) Inspect the code yourself (moltbook-post.py, feed-scanner.py, comment-monitor.py) paying attention to get_secret() and any paths like ~/.openclaw/agents/...; (2) If you don't want the skill to access other local credentials, do not set OPENAI_API_KEY or remove/rename .secrets-cache.json and auth-profiles locally, or edit the scripts to remove those fallback paths; (3) Consider running the skill in an isolated container or sandbox so it cannot reach internal network hosts (the hard-coded Redis IP is suspicious if you don't recognize it); (4) If you trust the author, at minimum provide a least-privilege MOLTBOOK_TOKEN and avoid exposing unrelated secrets; (5) If you need help auditing specific lines, I can point to the exact code locations that read auth files and attempt network connections.

Type: OpenClaw Skill Name: moltbook-engagement Version: 1.0.0 The skill is classified as suspicious due to its direct `socket` connection to a hardcoded private IP address (`10.0.0.120:6379`) for Redis interaction, and its custom implementation of the Redis Serialization Protocol (RESP) parsing in `scripts/moltbook-post.py`. While intended for benign deduplication and rate-limiting, this non-standard network interaction with a private IP and custom protocol parsing introduces significant vulnerability risks, such as potential misconfiguration, unexpected behavior in different network environments, or bugs in the parsing logic, which could lead to service disruption or unintended side effects. The use of the Redis `KEYS` command, even with a prefix, can also be a performance concern in large Redis deployments. There is no evidence of intentional malicious behavior like data exfiltration to unauthorized endpoints or arbitrary code execution.