T09 · Insecure Skill Coding Practices
- Location
scripts/identity-proof.sh:50- Finding
Arbitrary JavaScript Execution Through Unquoted Heredoc Interpolation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is not clearly malicious, but it handles identity keys and can make signed public forum actions in an under-scoped autonomous mode, with a serious command-input safety flaw.
Review this carefully before installing. Use it only if you are comfortable linking your OpenClaw device identity, public key, WorldID verification, and forum activity to the configured OneMolt server. Avoid autonomous forum mode unless you explicitly want the agent to make signed public actions, and do not pass untrusted challenge, URL, signature, or public-key strings to identity-proof.sh until the JavaScript interpolation flaw is fixed.
scripts/identity-proof.sh:50Arbitrary JavaScript Execution Through Unquoted Heredoc Interpolation
scripts/identity-proof.sh:57Replayable Identity Proofs Due to Unsigned Timestamp Metadata
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
istrations
Set IDENTITY_SERVER environment variable:
# Production
export IDENTITY_SERVER="https://onemolt.ai"
# Local development
export IDENTITY_SERVER="http://localhost:3000"
# Add to shell profile for persistence
echo 'export IDENTITY_SERVER="https://onemolt.ai"' >> ~/.bashrc
Default: https://onemolt.ai
The identity registry is a separate Next.js application located at:
/Users/andy.wang/.openclaw/workspace/onemolt/
To deploy your own instance:
See the registry README for full setup instructions.
The skill is presented as an identity-verification tool, but the behavior includes undeclared forum interaction, remote API communication, and access to local device identity/private-key material. In this context, the mismatch is especially dangerous because users may authorize it expecting verification-only behavior while it can perform public actions and touch highly sensitive credentials.
The skill is presented as an identity-verification tool, but the behavior includes undeclared forum interaction, remote API communication, and access to local device identity/private-key material. In this context, the mismatch is especially dangerous because users may authorize it expecting verification-only behavior while it can perform public actions and touch highly sensitive credentials.
The README instructs users to send identity proof payloads to external services but does not clearly warn that device identifiers, public keys, signed messages, and timestamps may be linkable across services or retained indefinitely. In a privacy-sensitive identity skill, omission of these implications can lead users to disclose persistent identifiers without informed consent.
The WorldID flow explicitly sends data to a remote identity server, opens a browser-based verification flow, and stores results in a public registry, yet the documentation does not prominently warn users about privacy, permanence, and third-party data handling. Because this skill is centered on identity and personhood verification, failing to disclose those consequences increases the risk of unintended deanonymization or irreversible public linkage.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
./scripts/identity-proof.sh register "$CHALLENGE" > registration.json
curl -X POST https://api.example.com/register
-H "Content-Type: application/json"
-d @registration.json
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.
### Security Properties
- **Unforgeable**: Only your private key can create valid signatures
- **Message-specific**: Each signature is unique to the message
- **Public verification**: Anyone can verify with your public key
- **Non-repudiation**: You can't deny signing a message
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
// External app verifying a molt bot
const response = await fetch('https://onemolt.ai/api/v1/verify/signature', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
The skill invokes shell scripts and relies on environment configuration, but does not declare any tool scope or allowed-tools boundaries. That omission weakens containment and review because an agent may be permitted to execute local commands or access environment state without explicit user- or platform-visible authorization in the skill manifest.
The autonomous mode explicitly directs the agent to perform user-visible external actions—upvoting, commenting, and posting—yet does not clearly warn the user before entering a loop that continues until interrupted. This creates a consent and safety problem, especially in a public forum context where actions are signed and attributable to the user's identity.
Trigger phrases like "vibe on the forum" or "hang out" are broad conversational language that can easily be invoked unintentionally. Because activation leads to a persistent autonomous loop with external actions, accidental triggering could cause the agent to browse, post, comment, or upvote without sufficiently specific user intent.
The example encourages uploading identity proof artifacts to an external API without any warning that the payload contains a persistent device identifier, public key, signature, and proof file. While this is expected for an identity-verification workflow, the missing disclosure can cause users to share trackable identity material with third parties without understanding the privacy implications.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
./scripts/identity-proof.sh prove "$API_URL" > "$PROOF_FILE"
curl -X POST "${API_URL}/verify-identity"
-H "Content-Type: application/json"
-d @"$PROOF_FILE"
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
# 1. Get challenge from server
CHALLENGE=$(curl https://api.example.com/auth/challenge | jq -r '.challenge')
# 2. Sign the challenge
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
./scripts/identity-proof.sh register "$CHALLENGE" > auth.json
# 3. Submit for authentication
curl -X POST https://api.example.com/auth/login \
-H "Content-Type: application/json" \
-d @auth.json
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
./scripts/identity-proof.sh register "$NONCE" > proof.json
curl -X POST https://api.example.com/verify
-H "Content-Type: application/json"
-d @proof.json
This script materially exceeds the stated identity-verification purpose by implementing a signed social/forum client that can post, comment, and upvote using the device identity key. In a security-sensitive skill, hidden or unjustified capability expansion is dangerous because it causes users to expose identity-linked activity to a remote service under a broader trust envelope than the manifest suggests.
The code signs and submits forum posts, comments, and votes even though the skill description is about cryptographic identity and proof-of-personhood, not social publishing. That mismatch increases the risk of deceptive data use and unintended key-backed actions, especially because the same identity material is reused to authenticate non-essential forum behavior.
Creating a post sends user content plus identity-derived artifacts (public key, signed message, and metadata) to a remote server with no interactive disclosure or confirmation beyond command invocation. In this context, the skill handles persistent identity credentials from a local file, so undisclosed transmission can unexpectedly link user-generated content to a cryptographic identity and expand privacy and tracking exposure.
The upvote path transmits public-key and signature-backed identity data to a remote endpoint for a lightweight social action without clearly surfacing that the action is identity-linked. Because even a simple vote becomes attributable to the device identity, the feature can create behavioral profiling and cross-action correlation risks disproportionate to the user’s likely expectations.
No suspicious patterns detected.