T05 · Unauthorized Access and Privilege Escalation
- Location
scripts/player.js:622- Finding
Remote Game Server Controls the Destination of Signed SOL Transfers
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a real-money Solana betting daemon that is mostly disclosed, but it gives a remote service and a long-running local process too much practical control over funds and sensitive data.
Install only with a dedicated low-balance wallet you are prepared to lose, and avoid passing the private key on the command line. Treat game chat as untrusted, avoid using --profile-pic with sensitive paths, and look for a version that pins the payment recipient locally, adds explicit confirmation and loss limits, and fixes the fairness status logic.
scripts/player.js:622Remote Game Server Controls the Destination of Signed SOL Transfers
scripts/player.js:301Solana Private Key Is Forwarded in the Persistent Daemon Command Line
scripts/player.js:54Profile Picture Option Can Upload Arbitrary Readable Local Files
scripts/player.js:117Remote Chat Messages Are Surfaced to the Agent Without a Prompt-Injection Trust Boundary
scripts/player.js:548Fairness Status Can Be Reported as Verified Without Successful Verification
The metadata and description understate the skill's real behavior: it is not just a status/control utility, but a system that onboards to remote services, sends outbound chat, processes mentions, and uses a private key to place real-money bets. This mismatch is dangerous because users and reviewers may approve the skill without understanding that it can spend funds and communicate externally on its own.
The metadata and description understate the skill's real behavior: it is not just a status/control utility, but a system that onboards to remote services, sends outbound chat, processes mentions, and uses a private key to place real-money bets. This mismatch is dangerous because users and reviewers may approve the skill without understanding that it can spend funds and communicate externally on its own.
Referenced artifact was not completely inspected
**You do not make betting decisions.** A background daemon (`player.js`) runs
The README describes starting the skill with a natural-language command and later says the daemon 'begins betting,' but it does not foreground at the startup point that this action will automatically place real-money wagers and continue running in the background. In a skill that controls a funded wallet and private key, this omission materially increases the risk of uninformed consent, accidental financial loss, and users starting a persistent betting process without understanding the consequences.
Persisting a Solana private key in ~/.bashrc creates long-lived secret exposure on disk and increases the chance the key is recovered by local compromise, backups, shell history mistakes, or by any same-user process able to read the environment after login. In this skill's context, the secret directly controls real funds, so even a single disclosure can lead to wallet theft.
Add to your shell profile on the EC2 instance:
# Add to ~/.bashrc (NOT to any file the agent can read)
export TURING_POT_PRIVATE_KEY="your_base58_private_key_here"
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Lock down the file permissions on .bashrc as a basic precaution:
chmod 600 ~/.bashrc
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Lock down the file permissions on .bashrc as a basic precaution:
chmod 600 ~/.bashrc
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Lock down the file permissions on .bashrc as a basic precaution:
chmod 600 ~/.bashrc
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
| Put key in SKILL.md or SOUL.md | Loaded into every conversation context |
| Put key in a `.env` file in the skill directory | Agent has read access to skill files |
| Commit anything to git | GitHub credential bots scan within minutes |
| Store key in plain text in any world-readable file | `chmod 600` at minimum on any file that must contain it |
---
Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.
| Put key in SKILL.md or SOUL.md | Loaded into every conversation context |
| Put key in a `.env` file in the skill directory | Agent has read access to skill files |
| Commit anything to git | GitHub credential bots scan within minutes |
| Store key in plain text in any world-readable file | `chmod 600` at minimum on any file that must contain it |
---
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Regardless of which option you use, lock down the OpenClaw config directory:
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.turing-pot/session.json # contains wallet pubkey + stats
Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.
Regardless of which option you use, lock down the OpenClaw config directory:
chmod 700 ~/.openclaw
chmod 600 ~/.openclaw/openclaw.json
chmod 600 ~/.turing-pot/session.json # contains wallet pubkey + stats
The skill requires access to a highly sensitive environment secret (TURING_POT_PRIVATE_KEY) and performs networked, fund-moving actions, but it declares no explicit tool scope or permission boundary. That omission increases the chance an agent or platform will expose capabilities more broadly than intended, reducing reviewability and making accidental misuse of wallet credentials and external actions more likely.
The start instructions launch a daemon that will automatically place real-money bets using a funded wallet, but the operational step is not paired with a clear, immediate warning or confirmation requirement at the point of execution. In context, this is risky because a user may treat --start as a harmless service action rather than authorizing autonomous spending from their wallet.
The manifest advertises a SOL betting game for AI agents but provides no warning about financial risk, wallet usage, or the possibility of losing funds. In an agent-skill context, this omission is dangerous because automated systems or operators may invoke the skill without understanding that it can trigger value-bearing actions or interact with wallets.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
}
}
// Rewrite file with all entries marked read
fs.writeFileSync(EVENTS_FILE, updated.join('\n') + '\n');
// Only print (and therefore only wake the LLM) if there's something to act on
The script performs a persistent file write that changes event state for all entries by marking them as read. While the header comment documents this behavior, there is no runtime disclosure, confirmation, or visible warning when the destructive state change occurs.
The usage text encourages passing the Solana private key on the command line, and the parser directly accepts --private-key. Command-line secrets are commonly exposed via shell history, process listings, job control logs, crash reports, or observability tooling, which can lead to full wallet compromise and theft of funds.
The skill description says it plays a betting game and manages the daemon, but this code also logs all chat, detects mentions, generates chat prompts, and enables outbound chat via a file-driven channel. That is a material behavioral expansion because it creates additional social/output capabilities and persistent collection of third-party messages that users may not expect from the published description.
The daemon persists full inbound chat messages to chat.jsonl for later agent consumption, creating a durable natural-language data store of third-party content. In this skill context, that increases privacy and prompt-injection risk because untrusted remote users can plant instructions or sensitive content that may later influence the agent or be exposed through logs.
On first startup, the player automatically sends agent identity data to a separate onboarding HTTPS service, but this outbound registration is not disclosed in the skill description. Hidden network egress to an additional endpoint is security-relevant because it expands data sharing and trust assumptions beyond the primary game WebSocket and RPC endpoints.
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.
"node": ">=18"
},
"optionalDependencies": {
"ws": "^8.18.0"
}
}
The manifest says the skill can start and stop a player daemon, so process control is partly declared, but this implementation achieves it by spawning a detached child process. Spawning subprocesses is a powerful capability that is not inherent to a betting-game skill itself and should be explicitly justified as part of lifecycle management.
Detected: suspicious.dangerous_exec, suspicious.exposed_secret_literal, suspicious.secret_argv_exposure