Jubilee Skill, By Jubilee Labs

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:07 PM UTC
• Version: 0.1.0

Overview

This skill is a real-money treasury-management guide whose core functions are disclosed, but it under-scopes safeguards around private keys, irreversible transfers, and recurring donation automation.

Review carefully before installing or using with any funded wallet. Use only a limited-balance operational wallet or managed signer, verify all chain/token/amount/vault/recipient values independently, avoid copying the sample donation address, and do not run scheduled donation automation unless you add spending limits, recipient allowlists, alerts, and manual approval controls.

A.I.G

Vulnerability Patterns

• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:189
• Finding: Plaintext Private-Key Storage in a Predictable Wallet File<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:189-215` **Vulnerability Type**: Plaintext credential storage **Risk Level**: High ### Vulnerable Code ```markdown ### Environment Variables (.env) ```bash # RPC Providers (Optional - defaults to public) RPC_BASE=https://mainnet.base.org RPC_SOLANA=https://api.mainnet-beta.solana.com # Wallet (Managed by OpenClaw) WALLET_PATH=/path/to/custom/wallet.json # Default chain DEFAULT_CHAIN=base # Debug mode DEBUG=false ``` ### Wallet Setup Ensure wallet exists at: ``` ~/.openclaw/workspace/setup_wallet_dir_new/wallets/agent_wallet.json ``` **Format:** ```json { "privateKey": "0xYOUR_PRIVATE_KEY_HERE" } ``` ``` ### Technical Analysis The documented wallet design directs users to store a raw private key in an unencrypted JSON file at a predictable location. The instructions do not require restrictive file permissions, encryption at rest, a managed secret store, hardware-backed signing, or separation between wallet credentials and the agent workspace. A process or user capable of reading the workspace or home directory could copy the private key and import it into another wallet. Possession of the key would allow transactions to be signed independently of the Jubilee tooling, bypassing any application-level restrictions such as preserving principal or donating only yield. The artifact contains documentation only, so this audit does not establish that a real private key is currently present. The vulnerability lies in the insecure credential-storage practice prescribed by the Skill. ### Attack Path 1. A user follows the wallet setup instructions and writes a funded wallet's raw private key to the documented JSON file. 2. An attacker obtains local read access through another process, an exposed workspace, an insecure backup, overly broad file permissions, or an accidental repository commit. 3. The attacker reads `agent_wallet.json` and extracts the `privateKey` value. 4. The attacker imports the ...[truncated 666 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace raw-key JSON storage with a hardware wallet, managed signer, operating-system keychain, encrypted keystore, or dedicated secrets-management service. 2. Require transaction signing through an interface that never returns or exposes the private key to the agent workspace. 3. If a local encrypted keystore is unavoidable, use a strong key-derivation function and obtain its passphrase from a separate protected channel. 4. Require owner-only filesystem permissions, such as `0600` for the keystore and `0700` for its directory. 5. Store wallet material outside repositories and general-purpose workspaces, and provide explicit ignore rules for wallet and environment files. 6. Use a limited-balance operational wallet or constrained smart-account policy rather than giving unattended automation control of the primary treasury. 7. Document key rotation and emergency revocation procedures, including immediate migration of assets if local credential exposure is suspected. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:124
• Finding: Copyable Fund-Transfer Example Contains a Concrete Recipient Address<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:124-129` **Vulnerability Type**: Unsafe financial-operation example **Risk Level**: Medium ### Vulnerable Code ```markdown **Example:** ```bash npm run donate-yield 10 0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb base ``` ``` ### Technical Analysis The donation example contains a syntactically valid, concrete blockchain address rather than an unmistakable placeholder. The document does not identify the address owner, state that it is non-operational, or require users to replace and independently verify it. Documentation examples are frequently copied directly by users or autonomous agents. If the command is executed against a funded mainnet wallet, it may initiate an irreversible transfer to the embedded address. The use of the `base` chain further increases the risk because the document identifies Base as a live mainnet network. The audit does not establish ownership or malicious control of the listed address. The issue is that an unidentified concrete recipient is embedded in a copyable value-transfer command. ### Attack Path 1. A user or agent consults the Skill documentation to perform a yield donation. 2. The example is copied without replacing the embedded address. 3. The donation command withdraws the specified amount from the jUSDi vault, as described by the Skill. 4. The tooling submits a transfer to the concrete address shown in the example. 5. If the transaction is signed and confirmed, the recipient receives the funds and recovery depends entirely on that recipient's cooperation. ### Impact Assessment The direct impact is loss of the amount authorized in the copied command, plus transaction fees. If the example is incorporated into automation or repeatedly invoked, cumulative losses may exceed the single example amount. This issue does not itself grant system privileges, but it can cause unauthorized or unintended disposition of treasury assets. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Replace the concrete address with an explicit placeholder such as `<VERIFIED_RECIPIENT_ADDRESS>`. 2. Make example commands fail safely unless the placeholder is replaced. 3. Require the tooling to display the resolved chain, token, amount, recipient address, and estimated fees before signing. 4. Require explicit interactive confirmation for new recipients and high-value transfers. 5. Support recipient allowlists or address-book entries with human-readable identities. 6. Warn users that blockchain addresses must be verified through an independent trusted channel. 7. Add transaction simulation and validate the destination chain before requesting a signature. ]]>

T06 · System Persistence

Warning

• Location: SKILL.md:279
• Finding: Unattended Recurring Transfers Are Recommended Without Financial Safety Controls<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:279-287` **Vulnerability Type**: Persistent scheduled financial operation **Risk Level**: Medium ### Vulnerable Code ```markdown ### Automated Yield Harvesting Create a cron job or GitHub Action: ```bash # Daily yield check 0 9 * * * npm run war-room # Weekly yield donation 0 9 * * 0 npm run donate-yield 10 0xCHARITY_ADDRESS ``` ``` ### Technical Analysis The Skill recommends configuring cron or GitHub Actions to execute a recurring donation command. Such scheduling persists beyond the initiating session and requires unattended access to wallet-signing capabilities. The instructions do not specify recipient allowlisting, cumulative spending limits, multisignature approval, transaction simulation, independent confirmation, alerting, emergency cancellation, replay protection, or short-lived credentials. A compromised workflow, modified command, substituted recipient, or exposed signing credential could therefore turn the scheduled task into a recurring unauthorized-transfer mechanism. The snippet itself does not install a scheduled task, and `0xCHARITY_ADDRESS` is a placeholder. The risk arises when users implement the recommended persistent automation without additional controls. ### Attack Path 1. A user implements the documented cron job or GitHub Actions workflow and provides it with access to wallet-signing credentials. 2. An attacker compromises the workflow configuration, repository permissions, runner, environment secrets, or local crontab. 3. The attacker changes the donation recipient, amount, executable, or environment used by the scheduled command. 4. The scheduler executes the modified command without an interactive approval step. 5. Unauthorized transactions recur according to the schedule until the workflow is disabled, credentials are revoked, or the wallet is depleted. ### Impact Assessment Exploitation can authorize repeated transfers from the operational wallet within th ...[truncated 334 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not provide unattended scheduled jobs with an unrestricted treasury private key. 2. Use a constrained smart account, limited-purpose hot wallet, or policy-controlled signer with per-transaction and cumulative spending caps. 3. Require multisignature or manual approval before each value-transfer transaction. 4. Restrict recipients to an independently maintained allowlist and require a delay when adding or changing recipients. 5. Simulate each transaction and verify the chain, token, amount, recipient, vault state, and available yield before signing. 6. Use short-lived credentials for automation and protect CI/CD environments with least-privilege permissions and branch protection. 7. Emit immediate alerts for attempted and completed transfers, and provide a tested emergency pause mechanism. 8. Ensure failures do not trigger uncontrolled retries or duplicate donations. 9. Separate read-only reporting jobs from value-transfer jobs so routine health checks require no signing credentials. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (1)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: This skill describes real on-chain deposit, withdrawal, and transfer operations, including a donation flow to arbitrary recipient addresses, but it does not give a clear, prominent warning that blockchain transactions are irreversible and that mistakes in amount, chain, token, vault, or recipient address can permanently lose funds. In the context of treasury management, an agent or operator could follow these commands directly and send assets to the wrong address, wrong network, or withdraw principal unintentionally, making the omission materially dangerous rather than merely cosmetic.

Static analysis

No suspicious patterns detected.