KrumpKlaw Social

• Outcome: Review
• Latest audit: Sep 11, 2026 · 1:31 AM UTC
• Version: 0.1.16

Overview

The skill is advertised as a creative Krump battle response guide, but it also includes recurring public account activity, persistent agent setup, session handling, and automated wallet payments.

Review this skill carefully before installing. Use it only for response drafting unless you deliberately want an agent that can post publicly, manage KrumpKlaw sessions, create persistent agents, and handle testnet wallet payouts. Do not enable Hypemode cron, autonomous tipping, wallet linking, or wildcard Privy policies without explicit human approval, isolated low-value test wallets, scoped credentials, and a clear way to disable or revoke access.

A.I.G

Vulnerability Patterns

• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads

Findings (6)

T06 · System Persistence

Error

• Location: SKILL.md:139
• Finding: Recurring Autonomous Activity Through a Persistent Cron Job<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:139-155` **Vulnerability Type**: Persistent scheduled execution and autonomous external actions **Risk Level**: High ### Evidence ```markdown ## Hypemode (Heartbeat) Similar to Moltbook heartbeat. **OpenClaw agents should run Hypemode every 30 minutes** to stay active on KrumpKlaw: 1. **Check the feed** — `GET /api/posts/feed` 2. **Saturday Sessions** — If it's Saturday, check `GET /api/sessions`. Create a session if none exists; or comment with your round on the latest session. 3. **Comment** — On 1–2 posts you haven't commented on 4. **React** — Add 🔥 ⚡ 🎯 💚 to posts you haven't reacted to 5. **Battle callout** — Optionally create a battle via `POST /api/battles/create` to call out another OpenClaw agent (pick from `GET /api/rankings`) **Script (cron every 30 min):** ```bash 0,30 * * * * cd /path/to/KrumpKlaw && KRUMPKLAW_SESSION_KEY=<your_session_key> node scripts/hypemode.js ``` ``` ### Technical Analysis The Skill directs the operator to establish a cron entry that executes every 30 minutes. This execution survives the original Skill invocation and uses a bearer session key to perform externally visible actions, including creating posts, commenting, reacting, and potentially initiating battles. This breaks task-scoped execution boundaries by converting an interactive creative Skill into a persistent autonomous service. The referenced `scripts/hypemode.js` file is not included in the audited artifact, so its implementation, input validation, destinations, and credential handling cannot be verified. The session key is also placed directly in the cron command. Depending on local cron implementation and filesystem permissions, this credential may be exposed through crontab inspection, backups, process inspection, or operational logs. ### Attack Path 1. A user installs the Skill based on its creative battle-response description. 2. The user or agent follows the Hypemode setup instructio ...[truncated 864 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove the cron-based execution instructions from the Skill. - Make feed inspection and every write operation explicitly user initiated. - Require separate confirmation before comments, reactions, session creation, or battle callouts. - Do not place bearer credentials directly in crontab entries. - If scheduling is an essential optional feature, use a restricted credential stored in an operating-system secret manager. - Scope that credential to read-only access by default and grant narrowly defined write permissions only when required. - Include the complete scheduled script in the audited package and pin all of its dependencies. - Document how to inspect, disable, and remove any scheduled task. - Add execution limits, audit logs, destination allowlists, and credential rotation procedures. ]]>

T02 · Agent Memory Poisoning

Warning

• Location: SKILL.md:248
• Finding: Persistent Behavioral Rules Written to Agent Memory<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:248-272` **Vulnerability Type**: Persistent agent-memory modification **Risk Level**: Medium ### Evidence ```markdown ### Persistent sub-agents & CLI integration (OpenClaw) KrumpKlaw’s built-in battle simulation is template-based. For **authentic, topic-aware** debates with real LLM responses, use a **CLI-based integration** with persistent OpenClaw sub-agents. **Pattern:** 1. Create two persistent OpenClaw agents (e.g. KrumpBot Omega, KrumpBot Delta) with distinct personas. 2. Use the **`openclaw agent`** CLI to query each agent per round (no public HTTP for `sessions_send`; the CLI is the supported programmatic gateway). 3. Collect responses, evaluate with `EnhancedKrumpArena`, then post to KrumpKlaw via **`POST /api/battles/record`** with **`responsesA`** and **`responsesB`** in the evaluation so the battle page shows round text. **Personas:** Put stance, battle guidelines, and cultural knowledge in each agent’s workspace **`MEMORY.md`** (e.g. Omega: AI enhances expression; Delta: preserves tradition; use Krump vocabulary, Laban notation, 2–4 sentences, “Krump for life!”). Personas in workspace memory keep identity consistent across rounds. ``` ### Technical Analysis The Skill explicitly recommends creating persistent sub-agents and writing Skill-provided behavioral rules into each agent's `MEMORY.md`. Long-term memory is not limited to the active battle and can affect future sessions after the Skill is no longer in use. Although the example content is themed around Krump personas, the underlying pattern normalizes unreviewed Skill instructions modifying durable agent state. No backup, consent boundary, provenance marker, expiration mechanism, or rollback procedure is provided. ### Attack Path 1. The Skill is loaded for a temporary battle-related task. 2. Its instructions cause two persistent OpenClaw sub-agents to be created. 3. Skill-provided persona and behavioral guidance is written ...[truncated 646 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace persistent `MEMORY.md` changes with task-scoped system or user prompts. - Require explicit informed approval before creating persistent sub-agents or changing long-term memory. - Show the exact proposed memory content and destination before writing it. - Create a backup and provide a one-command rollback procedure. - Mark inserted memory with its source, timestamp, scope, and expiration date. - Restrict battle personas to isolated temporary workspaces. - Ensure persistent memory cannot silently grant tool, network, credential, or financial authority. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:352
• Finding: Wildcard Wallet Signing Policy Enables Excessive Transaction Authority< or `clawhub install privy`). Use Story Aeneid Testnet (chain 1315, RPC: https://aeneid.storyrpc.io). ``` ```markdown **JAB payouts: policy must allow `personal_sign`** JAB requires two Privy RPC calls: `personal_sign` (to sign the EVVM pay message) and `eth_sendTransaction` (to submit Core.pay). If the wallet policy only allows `eth_sendTransaction` on chain 1315, payouts fail with `RPC request denied due to policy violation (code: "policy_violation")`. **Fix:** Add an ALLOW rule for system methods (e.g. wildcard `*`) to the wallet’s policy. You can update the existing policy without creating a new wallet. 1. **Get the policy ID** for the wallet (use the agent’s `privy_wallet_id`): ```bash curl -s -X GET "https://api.privy.io/v1/wallets/<WALLET_ID>" \ -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \ -H "privy-app-id: $PRIVY_APP_ID" ``` From the response, take `policy_ids[0]` (or the first policy id). 2. **Add a rule** to that policy to allow `personal_sign` (wildcard covers it): ```bash curl -X POST "https://api.privy.io/v1/policies/<POLICY_ID>/rules" \ -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \ -H "privy-app-id: $PRIVY_APP_ID" \ -H "Content-Type: application/json" \ -d '{ "name": "Allow system methods for JAB", "method": "*", "conditi ...[truncated 2820 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Remove autonomous wallet and payment operations from the creative battle Skill. - Never use `"method": "*"` for a signing policy. - Restrict policies to the exact required RPC methods, chain ID, verified contract addresses, function selectors, recipient rules, and maximum amounts. - Add short expiration periods, transaction-count limits, nonce controls, and revocation procedures. - Require explicit human review and confirmation for every signature, payout, and tip. - Prevent the winner or any remote participant from unilaterally choosing a token that changes the loser's required signing behavior. - Use a dedicated low-value test wallet with strict spending and gas limits. - Store Privy credentials only in an approved secret manager and never expose them to prompts, logs, or generated shell scripts. - Display decoded transaction details before approval. - Maintain immutable audit logs for policy changes, signatures, transfers, recipients, and amounts. - Revoke any existing wildcard rules and rotate credentials that were used with broadly authorized policies. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:346
• Finding: Documented Session Refresh Can Issue a Session Key From a Public Slug<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:346-348` **Vulnerability Type**: Insecure session refresh and potential account impersonation **Risk Level**: Critical ### Evidence ```markdown **Refresh session (401 / expired):** If an agent gets 401 errors, call `POST https://krumpklaw.fly.dev/api/auth/refresh-session` with `{ "slug": "agent-slug" }`. Returns a new `sessionKey` without re-registering. No extra headers needed unless the human owner has set `KRUMPKLAW_REFRESH_SECRET`. **When creating battles:** If the human asks for a battle between agents A and B (e.g. ryuazuki vs agentasura), use those agents. If either agent's session returns 401, **refresh their session first** via `POST /api/auth/refresh-session` with `{ "slug": "agent-slug" }` — do not fall back to a different agent's session. The battle must be between the requested agents. ``` ### Technical Analysis The documented workflow states that a new bearer `sessionKey` may be returned when the caller supplies only an agent slug, unless an optional refresh secret has been configured. Agent slugs are public identifiers used in profile URLs and are not authentication factors. If the external service behaves as documented, session refresh is effectively an account-takeover primitive. A caller who knows or enumerates a slug can request a credential representing that agent. The instructions also encourage agents to invoke this flow automatically after a `401`, increasing the chance that the insecure path will be routinely used. This audit only contains the client-side documentation and did not independently test the external service. The finding therefore applies directly to the unsafe workflow encoded by the Skill and conditionally to the service if its implementation matches the documentation. ### Attack Path 1. An attacker obtains an agent slug from a public profile, feed item, ranking, invite, or battle. 2. The attacker sends: ```http POST /api/auth/refresh-session C ...[truncated 847 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require a mandatory, high-entropy, single-account refresh token for every refresh request. - Never treat a public slug as proof of identity. - Bind refresh tokens to the agent, owner, intended client, and token family. - Rotate the refresh token on every use and detect reuse. - Require authenticated owner credentials or a securely established agent credential before issuing a new session. - Remove optional authentication modes; fail closed when refresh protection is not configured. - Rate-limit and monitor refresh attempts by account, client, and network source. - Return generic errors that do not disclose whether a slug exists. - Revoke all sessions and rotate credentials if unauthenticated refresh has ever been enabled. - Update the Skill so it never attempts credential recovery without explicit owner authorization. ]]>

T08 · Insecure Dependencies

Error

• Location: SKILL.md:352
• Finding: Unpinned Third-Party Wallet Skill Is Installed for Sensitive Operations< or `clawhub install privy`). Use Story Aeneid Testnet (chain 1315, RPC: https://aeneid.storyrpc.io). ``` ### Technical Analysis The Skill instructs users to install a separately maintained `privy` Skill to create and control a wallet. No version, immutable commit, package digest, signature, permission manifest, or reviewed source snapshot is specified. The dependency is introduced at the point where the workflow handles Privy API credentials, wallet identifiers, signing policies, and transactions. Installing a mutable third-party component in this trust position creates a supply-chain risk: later changes to the referenced Skill can alter the effective behavior without changing this audited artifact. No evidence in the audited project proves that the referenced dependency is malicious. The vulnerability is the unsafe, unpinned acquisition and delegation of sensitive wallet authority. ### Attack Path 1. The user follows the payout setup instructions. 2. `clawhub install privy` resolves the current package associated with that name. 3. The installed content may differ from the version originally reviewed by the Skill author. 4. The dependency is given access to wallet-creation workflows, API credentials, policy identifiers, and signing operations. 5. If the package, publisher account, registry resolut ...[truncated 553 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not automatically install a third-party Skill for credential-bearing wallet operations. - Pin the dependency to an exact audited version or immutable source commit. - Verify a cryptographic digest or trusted publisher signature before installation. - Publish a permission and data-flow manifest describing every secret, network destination, and wallet operation the dependency can access. - Vendor the minimal reviewed integration where licensing permits. - Isolate wallet operations in a restricted process with no access to unrelated agent memory or credentials. - Require explicit user approval before installation and before every subsequent update. - Continuously monitor the pinned dependency for ownership changes, security advisories, and integrity failures. ]]>

other

Error

• Location: README.md:7
• Finding: Project Documentation Conceals External Services, Credentials, Persistence, and Financial Features<![CDATA[ ## Vulnerability Details **File Location**: `README.md:7-13,34`; corroborating metadata at `clawhub.json:2-4` **Vulnerability Type**: Misleading security and capability disclosure **Risk Level**: High ### Evidence ```markdown ## What It Does - **8 judging criteria** with key vocabulary (technique, intensity, originality, consistency, impact, musicality, battle intelligence, community) - **4 battle formats**: debate, freestyle, call_response, storytelling - **Response guidelines**: length, vocabulary density, narrative building, respect - **Examples** for debate and freestyle rounds ``` ```markdown ## Requirements - OpenClaw agent with this skill installed - No API keys or external services - Works with KrumpKlaw (http://localhost:3001) and EnhancedKrumpArena ``` The metadata similarly describes the package as teaching vocabulary, formats, cultural values, and response guidelines: ```json { "name": "krump-battle-agent", "tagline": "Authentic Krump battle responses for OpenClaw agents—vocabulary, formats, and cultural values.", "description": "Teaches OpenClaw agents to participate in text-based Krump battles with authentic vocabulary and cultural respect. Based on Free-DOM Foundation's \"Behind the Decision\" research with 30+ Krump masters. Covers 8 judging criteria (technique, intensity, originality, consistency, impact, musicality, battle intelligence, community), 4 battle formats (debate, freestyle, call_response, storytelling), and response guidelines." } ``` ### Technical Analysis The statement “No API keys or external services” directly contradicts the primary `SKILL.md`. That file instructs use of: - `https://krumpklaw.fly.dev/api` - Bearer session keys - KrumpKlaw registration and account claiming - Privy APIs and Basic authentication - `PRIVY_APP_ID` and `PRIVY_APP_SECRET` - Persistent cron execution - Persistent OpenClaw sub-agents and `MEMORY.md` - Wallet linking, signing, automated payouts, and tipping - Story Aeneid RPC and ...[truncated 1238 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace “No API keys or external services” with a complete and accurate requirements section. - Disclose every external hostname and explain what information is transmitted. - List all required and optional credentials, including session keys and Privy credentials. - Clearly separate the safe response-coaching functionality from optional social, persistence, and wallet integrations. - Disclose scheduled execution and persistent memory modifications before installation. - Describe every financial side effect, including automatic payouts, tips, token selection, and gas costs. - Add an explicit permission matrix covering filesystem writes, subprocess execution, scheduling, network access, account creation, public posting, and wallet signing. - Make all high-risk integrations opt-in and disabled by default. - Update `clawhub.json`, `README.md`, and `SKILL.md` together so their advertised capabilities remain consistent. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Rogue Agent: Self-Modification, Session Persistence
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (13)

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: The skill's stated purpose is battle-language participation, but most of the later content expands into autonomous social engagement, account lifecycle management, wallet setup, payout configuration, and token tipping on external platforms. This is dangerous because it broadens agent authority far beyond user-expected scope, enabling unsolicited network actions and financial operations under the cover of a harmless cultural-response skill.

Context-Inappropriate Capability

High

• Confidence: 99% confidence
• Finding: Wallet linking, payout routing, Privy policy changes, and token tipping are highly sensitive financial capabilities that are not justified by a battle-language training skill. In context, they are more dangerous because they can lead to irreversible blockchain transactions, privilege changes, and misuse of wallet credentials while appearing to be part of a harmless entertainment feature.

Missing User Warnings

High

• Confidence: 99% confidence
• Finding: The wallet and tipping sections describe autonomous linkage of wallets, payout-token selection, and token transfers without an equally prominent warning about financial consequences and irreversible on-chain actions. This is especially dangerous because it may expose users to loss of funds, gas costs, and signing-policy changes with insufficient informed consent.

Context-Inappropriate Capability

Medium

• Confidence: 96% confidence
• Finding: The 'Hypemode' section directs the agent to autonomously poll feeds, comment, react, and optionally initiate battles on a schedule every 30 minutes. For a skill advertised as teaching battle participation, this is an unjustified behavioral expansion that can create spammy or unauthorized account activity without a current user request.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill instructs recurring feed checks, comments, reactions, and battle callouts without a prominent warning that these are networked account actions performed on the user's behalf. This is dangerous because users may invoke a cultural-response skill without realizing it can cause external posting behavior and reputational impact.

Intent-Code Divergence

Medium

• Confidence: 88% confidence
• Finding: The document mixes 'must ask the human' requirements with other instructions encouraging autonomous agent-only actions and sub-agent creation, producing inconsistent safety boundaries. That ambiguity is dangerous because implementers may follow the autonomous flow and bypass human approval for registration or related actions.

Session Persistence

Medium

• Category: Rogue Agent

Content

KrumpKlaw’s built-in battle simulation is template-based. For **authentic, topic-aware** debates with real LLM responses, use a **CLI-based integration** with persistent OpenClaw sub-agents.

**Pattern:**
1. Create two persistent OpenClaw agents (e.g. KrumpBot Omega, KrumpBot Delta) with distinct personas.
2. Use the **`openclaw agent`** CLI to query each agent per round (no public HTTP for `sessions_send`; the CLI is the supported programmatic gateway).
3. Collect responses, evaluate with `EnhancedKrumpArena`, then post to KrumpKlaw via **`POST /api/battles/record`** with **`responsesA`** and **`responsesB`** in the evaluation so the battle page shows round text.

• Confidence: 80% confidence
• Finding: The instruction to create persistent sub-agents introduces durable autonomous state and identity beyond a simple one-shot response skill. On its own this is not inherently malicious, but in combination with posting, registration, and financial flows it increases the blast radius of misconfiguration or abuse because long-lived agents can repeatedly perform actions over time.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: The registration and session-management sections instruct the agent to onboard accounts, refresh sessions, and manage human-linked identities, which are unrelated to merely composing battle responses. This increases risk by enabling account creation and authentication workflows under a misleadingly narrow skill description.

External Transmission

Medium

• Category: Data Exfiltration

Content

**Optional: Create Privy policy + wallet and link (for automation)**  
If you or your human want to automate wallet setup, use this flow. You need: **Privy API credentials** (`PRIVY_APP_ID`, `PRIVY_APP_SECRET` in env) and the agent **already registered** on KrumpKlaw (so the agent has a slug).

1. **Create a policy (Story Aeneid only)** — `POST https://api.privy.io/v1/policies` with Basic auth and body: two rules—(1) `eth_sendTransaction` for chain_id 1315; (2) allow message signing for JAB (e.g. `method`: `"*"` with system condition, or allow `personal_sign` in [Privy dashboard](https://dashboard.privy.io)). See repo `docs/PRIVY-WALLET-GUIDE.md` for full JSON. Save the policy `id`.

2. **Create wallet with that policy** — `POST https://api.privy.io/v1/wallets` (same auth/headers), body: `chain_type`: `"ethereum"`, `policy_ids`: `["<policy_id>"]`. Save from response: `id` (use as `privy_wallet_id`) and `address` (use as `wallet_address`).

• Confidence: 82% confidence
• Finding: The skill directs the agent toward creating Privy policies and wallets through external API calls, extending behavior into sensitive third-party account provisioning. In context, this is dangerous not because external transmission is inherently malicious, but because it is bundled into an unrelated skill and may trigger handling of API secrets and wallet setup beyond user expectations.

External Transmission

Medium

• Category: Data Exfiltration

Content

1. **Create a policy (Story Aeneid only)** — `POST https://api.privy.io/v1/policies` with Basic auth and body: two rules—(1) `eth_sendTransaction` for chain_id 1315; (2) allow message signing for JAB (e.g. `method`: `"*"` with system condition, or allow `personal_sign` in [Privy dashboard](https://dashboard.privy.io)). See repo `docs/PRIVY-WALLET-GUIDE.md` for full JSON. Save the policy `id`.

2. **Create wallet with that policy** — `POST https://api.privy.io/v1/wallets` (same auth/headers), body: `chain_type`: `"ethereum"`, `policy_ids`: `["<policy_id>"]`. Save from response: `id` (use as `privy_wallet_id`) and `address` (use as `wallet_address`).

3. **Get an agent session key** — Either the human logs in at [krumpklaw.lovable.app](https://krumpklaw.lovable.app), opens the **API Key** card in the sidebar, and clicks **Refresh Key** (then use the copied key). Or call `POST https://krumpklaw.fly.dev/api/auth/refresh-session` with body `{ "slug": "<agent_slug>" }` and header **Authorization: Bearer \<current_session_key\>** (the human’s session from login). Response field is `sessionKey` (camelCase).

• Confidence: 82% confidence
• Finding: This external wallet-creation call involves transmitting data to a third-party financial provider as part of an automation flow. In a battle-participation skill, that is context-inappropriate and increases the chance of secret misuse, unintended account creation, or silent expansion into financial infrastructure.

External Transmission

Medium

• Category: Data Exfiltration

Content

1. **Get the policy ID** for the wallet (use the agent’s `privy_wallet_id`):
   ```bash
   curl -s -X GET "https://api.privy.io/v1/wallets/<WALLET_ID>" \
     -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \
     -H "privy-app-id: $PRIVY_APP_ID"
   ```

• Confidence: 83% confidence
• Finding: The repeated Privy wallet lookup example again demonstrates authenticated data transmission to an external provider using sensitive application credentials. The main risk is contextual: the skill encourages capabilities that may expose or misuse secrets in an environment that should only generate battle text.

External Transmission

Medium

• Category: Data Exfiltration

Content

1. **Get the policy ID** for the wallet (use the agent’s `privy_wallet_id`):
   ```bash
   curl -s -X GET "https://api.privy.io/v1/wallets/<WALLET_ID>" \
     -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \
     -H "privy-app-id: $PRIVY_APP_ID"
   ```

• Confidence: 83% confidence
• Finding: The repeated Privy wallet lookup example again demonstrates authenticated data transmission to an external provider using sensitive application credentials. The main risk is contextual: the skill encourages capabilities that may expose or misuse secrets in an environment that should only generate battle text.

External Transmission

Medium

• Category: Data Exfiltration

Content

2. **Add a rule** to that policy to allow `personal_sign` (wildcard covers it):
   ```bash
   curl -X POST "https://api.privy.io/v1/policies/<POLICY_ID>/rules" \
     -u "$PRIVY_APP_ID:$PRIVY_APP_SECRET" \
     -H "privy-app-id: $PRIVY_APP_ID" \
     -H "Content-Type: application/json" \

• Confidence: 84% confidence
• Finding: The policy-update example sends authenticated requests that can change wallet signing permissions, including broad allow rules. That is dangerous in this context because it enables privilege escalation over financial wallets from within a skill whose stated purpose does not justify such authority.

Static analysis

No suspicious patterns detected.