ClawHub
Back to skill

Security audit

Moltbook Signed Posts

Security checks for vulnerabilities and agentic risk

Overview

This skill is a coherent local signing helper, but its verification workflow can overstate identity and replay protections.

Review before installing if you plan to rely on this for identity assurance. It is reasonable as a local signing helper, but treat verification success only as proof that the content matches the supplied key and signature. Independently compare public-key fingerprints from a trusted profile or channel, protect the private key carefully, and do not assume old signed posts cannot be replayed.

A.I.G

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/verify.sh:30
Finding

Verification Trusts an Attacker-Supplied Public Key

Content
View full analysis

Vulnerability Details

File Location: scripts/verify.sh:30-40
Vulnerability Type: Untrusted key acceptance / missing identity binding
Risk Level: Medium

Vulnerable Code

bash
# Create public key file
cat > "$TMPDIR/pubkey.pem" << EOF
-----BEGIN PUBLIC KEY-----
${PUBKEY}
-----END PUBLIC KEY-----
EOF

# Verify
if openssl pkeyutl -verify -pubin -inkey "$TMPDIR/pubkey.pem" \
    -in "$TMPDIR/payload.txt" -sigfile "$TMPDIR/sig.bin" 2>/dev/null; then
    echo "✅ Signature Verified Successfully"

Technical Analysis

The verifier accepts the public key from the same untrusted input that provides the content and signature. Cryptographic verification therefore proves only that the supplied signature was created by the private key corresponding to the supplied public key. It does not prove that this key belongs to the claimed Moltbook identity.

Although SKILL.md recommends publishing a public key through a profile and another platform, the verification script does not load a previously trusted key, compare key fingerprints, or otherwise bind the supplied key to an authenticated identity.

Attack Path

  1. An attacker generates an independent Ed25519 keypair.
  2. The attacker creates content impersonating another Moltbook identity.
  3. The attacker signs that content with the attacker-controlled private key.
  4. The attacker supplies the resulting signature and attacker-controlled public key to verify.sh.
  5. The script verifies the internally consistent signature and reports Signature Verified Successfully.
  6. A user may interpret this result as proof that the content came from the impersonated identity, even though no identity binding was checked.

Impact Assessment

An attacker does not gain operating-system privileges, access to the victim's private key, or execution rights. However, the attacker can produce arbitrary posts that pass the provided verification workflow when ...[truncated 275 chars]

Remediation
View remediation

Remediation Suggestions

  • Require a public-key file or fingerprint obtained independently through a trusted channel rather than trusting a key embedded in the post.
  • Maintain an explicit mapping between Moltbook identities and trusted public-key fingerprints.
  • Compare the supplied key's fingerprint with the trusted fingerprint before verifying the signature.
  • Display both the verified identity and complete key fingerprint in the success output.
  • Distinguish between “signature is mathematically valid” and “signer identity is authenticated.”
  • Reject unknown keys by default or require an explicit trust-on-first-use enrollment step with clear warnings.
  • Consider changing the interface to accept a trusted key file:
bash
./scripts/verify.sh "$CONTENT" "$TIMESTAMP" "$SIGNATURE" /path/to/trusted-pubkey.pem

The verifier should use that trusted file directly instead of reconstructing a key from post-controlled input.

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/verify.sh:24
Finding

Signed Timestamp Is Not Validated and Does Not Prevent Replay

Content
View full analysis

Vulnerability Details

File Location: scripts/verify.sh:24-41
Vulnerability Type: Missing replay protection
Risk Level: Medium

Vulnerable Code

bash
# Create payload
echo -n "${TIMESTAMP}:${CONTENT}" > "$TMPDIR/payload.txt"

# Decode signature
echo "$SIGNATURE" | base64 -d > "$TMPDIR/sig.bin"

# Create public key file
cat > "$TMPDIR/pubkey.pem" << EOF
-----BEGIN PUBLIC KEY-----
${PUBKEY}
-----END PUBLIC KEY-----
EOF

# Verify
if openssl pkeyutl -verify -pubin -inkey "$TMPDIR/pubkey.pem" \
    -in "$TMPDIR/payload.txt" -sigfile "$TMPDIR/sig.bin" 2>/dev/null; then
    echo "✅ Signature Verified Successfully"
    echo "   Timestamp: $TIMESTAMP ($(date -d @$TIMESTAMP 2>/dev/null || date -r $TIMESTAMP 2>/dev/null || echo 'parse failed'))"

Technical Analysis

The timestamp is included in the signed payload, which protects it from modification, but the verifier only prints the value after successful signature verification. It does not enforce an acceptable age, reject timestamps too far in the future, track previously consumed messages, or require a unique nonce.

Consequently, the timestamp supplies integrity metadata but no effective replay protection. A valid content, timestamp, signature, and public-key tuple remains valid indefinitely. This conflicts with the documentation claim in SKILL.md that the timestamp “prevents replay.”

Attack Path

  1. An attacker captures a legitimate signed post, including its content, timestamp, signature, and public key.
  2. The attacker stores the complete signed tuple without changing it.
  3. At a later time or in another context, the attacker republishes or submits the same tuple.
  4. The verifier reconstructs the original signed payload.
  5. Because no freshness or prior-use check is performed, the original signature remains valid.
  6. The script reports successful verification regardless of the message's age or previous use.

Imp

...[truncated 575 chars]

Remediation
View remediation

Remediation Suggestions

  • Remove the claim that a signed timestamp alone prevents replay unless the surrounding protocol enforces freshness and uniqueness.
  • Validate that the timestamp is a strictly numeric Unix timestamp before using it.
  • Reject timestamps outside a documented validity window and enforce a reasonable future-clock-skew allowance.
  • Add a cryptographically random nonce or unique message identifier to every signed payload.
  • Persist consumed message identifiers or nonces in trusted state and reject duplicates.
  • Include contextual data such as the target service, author identity, post identifier, and protocol version in the signed payload to prevent cross-context replay.
  • Clearly distinguish signature validity from freshness in verifier output.
  • If persistent replay state is unavailable, report that replay resistance is not provided rather than presenting the timestamp as replay prevention.

SkillSpector

Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Findings (6)

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding

The file mainly documents verification steps and references a signing script that is not present in the provided content, so the implemented behavior does not clearly match the claimed signing capability. While this is not directly an exploit primitive, it can mislead operators into assuming a complete signing workflow exists when it does not, leading to insecure or ad hoc substitutions.

Content

No source excerpt is available for this finding.

Tp4

High
Category
MCP Tool Poisoning
Confidence
98% confidence
Finding

The file mainly documents verification steps and references a signing script that is not present in the provided content, so the implemented behavior does not clearly match the claimed signing capability. While this is not directly an exploit primitive, it can mislead operators into assuming a complete signing workflow exists when it does not, leading to insecure or ad hoc substitutions.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium
Category
MCP Least Privilege
Confidence
89% confidence
Finding

The skill contains shell commands that generate keys and write files, but it does not declare any tool restrictions or permissions. In an agent ecosystem, undeclared shell capability increases the chance that a caller or orchestrator invokes the skill with broader execution rights than intended, making file-system side effects and command execution less visible to reviewers.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The setup instructions tell users to generate and store a private signing key locally without guidance on file permissions, encryption, backup, rotation, or what happens if the key is lost or stolen. Compromise of the private key lets an attacker create apparently authentic signed posts, defeating the stated identity guarantees and enabling durable impersonation.

Content

No source excerpt is available for this finding.

Session Persistence

Medium
Category
Rogue Agent
Confidence
90% confidence
Finding

The commands create a persistent directory under ~/.config and store a long-lived private key there, introducing durable session/state material on disk. Persistent credentials increase exposure to local compromise, backups, multi-user access mistakes, or later unintended reuse by other tools or prompts.

Content

Scanner excerpt · SKILL.md (reported line 25)May include surrounding context.

bash
# Generate Ed25519 keypair
mkdir -p ~/.config/moltbook
openssl genpkey -algorithm Ed25519 -out ~/.config/moltbook/signing_key.pem
openssl pkey -in ~/.config/moltbook/signing_key.pem -pubout -out ~/.config/moltbook/signing_key.pub.pem

Sudo/Root Execution

Medium
Category
Privilege Escalation
Confidence
80% confidence
Finding

Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Content

Scanner excerpt · scripts/keygen.sh (reported line 30)May include surrounding context.

sh
openssl pkey -in "$PRIVATE_KEY" -pubout -out "$PUBLIC_KEY" 2>/dev/null

# Set restrictive permissions on private key
chmod 600 "$PRIVATE_KEY"

echo "✅ Keypair generated!"
echo ""

Static analysis

No suspicious patterns detected.