Kaspa Dev

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:37 AM UTC
• Version: 0.1.0

Overview

This Kaspa development skill is purpose-related but contains unsafe wallet, transaction, dependency, and node-operation guidance that could put funds or systems at risk if followed directly.

Review carefully before installing or using. Treat the included scripts and examples as unsafe for real funds unless revised: do not print or save private keys or mnemonics in plaintext, do not rely on the Python transaction builder for signing or submission, test only on testnet/devnet first, pin and verify all packages/images/binaries, and bind node RPC to localhost unless you have explicit authenticated remote-access controls.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (9)

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/generate-address.py:255

Finding

Wallet private keys and mnemonic phrases are exposed through plaintext output and files

Content

View full analysis

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/build-transaction.py:420

Finding

Transaction submission accepts private-key presence as proof of signing while returning an unsigned transaction

Content

View full analysis

Transaction: """Sign a transaction with a private key. Note: This is a placeholder. Real signing requires: 1. secp256k1 library for ECDSA signatures 2. Proper sighash calculation 3. Schnorr signature support (Kaspa uses Schnorr) For production use, use the official SDKs or a proper signing library. """ print("WARNING: Transaction signing not fully implemented in this script.") print("Please use official Kaspa SDKs for production signing:") print(" - JavaScript: kaspa-wasm") print(" - Rust: kaspa-wallet-core") print(" - Go: github.com/kaspanet/kaspad") # Return unsigned transaction return transaction ``` Submission nevertheless relies only on whether the argument was supplied: ```python if args.submit: if not args.private_key: print("\nError: Cannot submit unsigned transaction. Provide --private-key") sys.exit(1) print("\nSubmitting transaction...") tx_id = rpc.submit_transaction(transaction.to_dict()) print(f"Transaction submitted! ID: {tx_id}") ``` ### Technical Analysis `_sign_transaction()` does not parse or use the supplied WIF, calculate a signature hash, create a Schnorr signature, or populate any input's `signatureScript`. It explicitly returns the unchanged unsigned transaction. The submission gate checks only that `args.private_key` is non-empty. It therefore conflates possession of a string with successful cryptographic signing. This violates the transaction builder's stated behavior and creates an unsafe authorization state in which unsigned data is represented as ready for broadcast. ### Attack Path 1. A user in ...[truncated 870 chars]

Remediation

View remediation

T09 · Insecure Skill Coding Practices

Error

• Location: scripts/build-transaction.py:209

Finding

Fee is excluded from UTXO selection, allowing invalid transactions or unintended excessive fees

Content

View full analysis

self.DUST_THRESHOLD: sender_script = self._address_to_script(sender_address) outputs.append( TransactionOutput( amount=change, script_public_key=ScriptPublicKey( version=0, script=sender_script ) ) ) ``` ### Technical Analysis UTXOs are selected only until `total_input >= amount`. The fee is calculated afterward, and the code never verifies that `total_input >= amount + fee`. If the selected value covers the payment but not the payment plus fee, `change` becomes negative. Python permits the negative arithmetic, and the condition suppresses the change output. Once real signing is added, the effective transaction fee becomes the entire difference between all inputs and outputs, rather than the intended estimate. If the difference is insufficient under consensus ...[truncated 1033 chars]

Remediation

View remediation

= amount + final_fee`. - Enforce checked, non-negative arithmetic for all amounts. - Add a user-configurable absolute and percentage-based maximum fee. - Validate remote fee estimates against local minimum and maximum policy bounds. - Use the official SDK's mass and fee calculation instead of a simplified byte-size approximation. - Add tests for exact-balance wallets, high fee rates, dust change, multiple inputs, and malicious fee estimates. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: references/kaspa-go-sdk.md:420

Finding

Go transaction example can underflow change and signs against an unrelated output index

Content

View full analysis

546 { senderScript, err := txscript.PayToAddrScript(senderAddress) if err != nil { return nil, err } outputs = append(outputs, &externalapi.DomainTransactionOutput{ Value: change, ScriptPublicKey: senderScript, }) } ``` The signing example then indexes the new transaction's outputs using the spent outpoint index: ```go func signTransaction(tx *externalapi.DomainTransaction, privateKey *btcec.PrivateKey) (*externalapi.DomainTransaction, error) { for i := range tx.Inputs { // Calculate signature hash sighash, err := txscript.CalcSignatureHash( tx.Outputs[tx.Inputs[i].PreviousOutpoint.Index].ScriptPublicKey, txscript.SigHashAll, tx, i, ) if err != nil { return nil, err } signature, err := privateKey.Sign(sighash[:]) if err != nil { return nil, err } sigScript, err := txscript.NewScriptBuilder(). AddData(append(signature.Serialize(), byte(txscript.SigHashAll))). AddData(privateKey.PubKey().SerializeCompressed()). Script() if err != nil { return nil, err } tx.Inputs[i].SignatureScript = sigScri ...[truncated 1584 chars]

Remediation

View remediation

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/node-operations.md:82

Finding

Recommended node configurations expose the RPC service on all network interfaces

Content

View full analysis

kaspad --utxoindex --rpclisten=0.0.0.0:16110 --listen=0.0.0.0:16111 --acceptance-index ``` The persistent service similarly exposes RPC: ```ini ExecStart=/usr/local/bin/kaspad --utxoindex --rpclisten=0.0.0.0:16110 --listen=0.0.0.0:16111 --acceptance-index ``` ### Technical Analysis Binding RPC to `0.0.0.0` makes it reachable through every host interface. Publishing Docker port `16110` exposes it beyond the container as well. The primary examples omit RPC authentication, TLS, reverse-proxy controls, and source-IP restrictions. Although the guide later warns about external RPC access and includes firewall examples, users following the basic or “recommended” configurations receive an insecure default. RPC access is not necessary from arbitrary remote hosts for normal local node operation, so this exceeds minimum required exposure. ### Attack Path 1. A user copies the basic Docker, recommended Compose, or systemd configuration. 2. Port 16110 becomes reachable from a local network or the internet, depending on host firewall and routing. 3. An attacker scans for the exposed Kaspa RPC endpoint. 4. The attacker invokes available RPC methods, performs expensive repeated queries, inspects node dat ...[truncated 610 chars]

Remediation

View remediation

T08 · Insecure Dependencies

Error

• Location: references/node-operations.md:213

Finding

Downloaded executables are installed with root privileges without checksum or signature verification

Content

View full analysis

Remediation

View remediation

T08 · Insecure Dependencies

Warning

• Location: references/node-operations.md:95

Finding

Mutable latest container tags permit unreviewed code changes in persistent services

Content

View full analysis

kaspad --utxoindex --rpclisten=0.0.0.0:16110 --listen=0.0.0.0:16111 --acceptance-index ``` Other monitoring examples use: ```yaml image: prom/prometheus:latest image: grafana/grafana:latest ``` ### Technical Analysis The `latest` tag is mutable: it can resolve to different image content over time without any configuration change or code review. The services use `restart: unless-stopped`, and the guide recommends pulling updates with `docker-compose pull`, allowing newly resolved images to become persistent runtime components. A compromised registry account, malicious upstream publication, or unexpected breaking release can therefore alter executable behavior after the Skill itself has been audited. ### Attack Path 1. An attacker compromises an upstream image publisher or registry account. 2. The attacker moves the `latest` tag to a malicious image. 3. An operator runs the documented pull and restart procedure, or an automated updater fetches the tag. 4. The malicious image starts with access to published ports and mounted persistent volumes. 5. It can read or modify the corresponding service data and communicate over the network. ### Impact Assessment A malicious `kaspad` image would gain access to the node's mounted data and network interfaces. Compromised Prometheus or Grafana images could access their own persistent data, monitoring credentials, and reachable internal services. Container escape is not established, but host impact may increase if Dock ...[truncated 68 chars]

Remediation

View remediation

`. - Maintain a controlled update process that reviews release notes and image provenance. - Enable container-signature or provenance verification where supported. - Scan images before deployment and retain a known-good digest for rollback. - Do not combine mutable tags with unattended update tools for wallet or node infrastructure. - Run containers as non-root, use read-only filesystems where possible, drop unnecessary capabilities, and restrict outbound connectivity. ]]>

T08 · Insecure Dependencies

Error

• Location: references/kaspa-wasm-sdk.md:577

Finding

Wallet-sensitive browser code imports a mutable module directly from a third-party CDN

Content

View full analysis

import * as kaspa from 'https://unpkg.com/kaspa-wasm@latest/kaspa_wasm.js'; const privateKey = kaspa.PrivateKey.random(kaspa.NetworkType.Mainnet); console.log(privateKey.toPublicKey().toAddress(kaspa.NetworkType.Mainnet).toString()); ``` ### Technical Analysis The browser fetches and executes JavaScript directly from `unpkg.com` at page load. The `@latest` selector is mutable, so the effective code can change without any modification to the application. The module is used in a context that creates private keys and may sign transactions. Native module imports do not provide an integrity attribute equivalent to a pinned Subresource Integrity hash in this form. Compromise of the NPM package, CDN, publisher account, or mutable release could therefore execute attacker-controlled JavaScript in the application's origin. ### Attack Path 1. The package publisher, NPM account, or CDN delivery path is compromised. 2. The `latest` version is changed to malicious JavaScript. 3. A user opens an application built from the documented example. 4. The browser downloads and executes the changed module with the page's privileges. 5. The module reads generated keys, changes recipient addresses, modifies transaction amounts, or exfiltrates signing material to an attacker-controlled server. ### Impact Assessment The injected module would execute in the wallet application's browser context. It could access keys handled by the page, alter transactions before signing, impersonate the user in message-signing flows, and steal all funds controlled by exposed keys. The impact is limited by browser-origin isolation but is critical within the affected application. ]]>

Remediation

View remediation

T08 · Insecure Dependencies

Warning

• Location: references/kaspa-python-sdk.md:1

Finding

Unpinned unofficial Python package is recommended for wallet-related operations

Content

View full analysis

=2.28.0 bech32>=1.2.0 secp256k1>=0.14.0 ``` ### Technical Analysis The guide explicitly states that the Python implementation is unofficial but provides only a package name, without a verified publisher identity, source repository, exact version, or hash. The broad dependency constraints allow future releases to be installed without review. Wallet libraries process private keys, mnemonic seeds, addresses, and transactions. A malicious or compromised package can execute during installation or import and has direct access to these assets. No evidence establishes that the named package is currently malicious; the issue is the unsafe acquisition and pinning practice. ### Attack Path 1. A developer follows the guide and installs `kaspa-python` without confirming its publisher or source. 2. The package is compromised, transferred to a malicious maintainer, or replaced by a future malicious release. 3. `pip` resolves and installs the new release because no exact version or hash is required. 4. Package installation or import executes attacker-controlled code. 5. The code reads environment variables, wallet material, project files, or transaction data and sends them to an attacker. ### Impact Assessment The package executes with the developer or application account's privileges. It may read all files and environment secrets available to that account, alter generated addresses ...[truncated 190 chars]

Remediation

View remediation

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• MCP Least Privilege: Underdeclared Capability, Wildcard Permission, Missing Permission Declaration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection

Findings (57)

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 96% confidence

Finding

The description substantially overstates the functionality present in the supplied code. The actual code is limited to a Python command-line utility for constructing simple Kaspa transfer transactions and KRC20 payload transactions using a hosted API for UTXO lookup, fee estimation, and submission. It does not provide the broad multi-language blockchain development toolkit described, nor wallet management, address generation, dApp/block explorer tooling, integration helpers, node setup, or SDK coverage. Most importantly, the script advertises building and signing transactions in comments/docstring, but its signing function is a placeholder that returns the transaction unsigned after printing warnings. While transaction building, KRC20 handling, and optional broadcast do align with a subset of the declared purpose, the overall description does not accurately represent this code chunk’s real scope or implemented capabilities.

Content

No source excerpt is available for this finding.

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The example prints the raw private key to stdout, which is a full wallet secret. Console output is commonly captured in shell history, logs, notebooks, CI systems, or screenshots; disclosure would let an attacker immediately take control of the associated funds.

Content

No source excerpt is available for this finding.

Missing User Warnings

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The complete example prints the mnemonic phrase, which grants full recovery of the wallet and all derived accounts. In a blockchain SDK guide, users are likely to copy-paste and run examples verbatim; exposing the mnemonic to terminal output or logs creates immediate account-compromise risk.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The file header and usage text claim the script 'builds and signs' Kaspa transactions, but _sign_transaction is only a placeholder that emits warnings and returns the transaction unchanged. In a blockchain tooling context, this can mislead operators into believing a transaction has been signed and is ready for submission, causing failed transfers, broken automation, or unsafe downstream handling based on false assumptions about transaction state.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

The submit path checks only for the presence of --private-key before calling submit_transaction, even though providing a private key does not actually sign the transaction in this script. This creates a dangerous trust boundary error: callers and automation may interpret private-key presence as proof of signing, leading to submission of invalid transactions and possible operational or financial disruption.

Content

No source excerpt is available for this finding.

Undeclared Tool Scope

Medium

• Category: MCP Least Privilege
• Confidence: 87% confidence

Finding

The skill documents behaviors that imply network access and file-writing related workflows, but it does not declare any explicit tool scope or permissions boundary. In an agent ecosystem, this can cause capability ambiguity: a caller may authorize or execute the skill with broader-than-expected privileges, increasing the chance of unintended network actions or file modifications.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The skill includes wallet/address generation and transaction broadcasting examples, including printing a private key and connecting to a mainnet RPC endpoint, without prominent warnings about secret handling, irreversible transfers, and real-funds risk. In a blockchain context, users may copy these examples directly into production or client-side environments, leading to key exposure, accidental fund loss, or unsafe signing flows.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

The markdown describes submitting a signed transaction to the network, which can affect user funds and is generally irreversible once propagated, but it does not include any cautionary note. For markdown files, safety-relevant behavior that can affect user data or system integrity should be accompanied by a clear warning.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 70% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · references/api-reference.md (reported line 695)May include surrounding context.

md

# Get balance
def get_balance(address):
    response = requests.post(
        f'{BASE_URL}/api/v1/rpc/get-balance-by-address',
        json={'address': address},
        headers=HEADERS

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 93% confidence

Finding

The example includes a complete mainnet fund-transfer flow, including UTXO selection, signing, and SubmitTransaction, but does not warn that copying it as-is can create and broadcast real transactions that move assets. In a developer skill focused on blockchain integration, users may paste examples directly into production code, so the absence of an explicit safety warning increases the chance of accidental mainnet transfers or unintended loss through testing mistakes.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 92% confidence

Finding

The file exposes a direct transaction submission method without a prominent warning that broadcasting blockchain transactions can be irreversible and may transfer real funds. In this skill context, which is aimed at wallet and transaction development, omission of such warnings increases the chance of accidental mainnet broadcasts during experimentation.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

• Category: Not specified by scanner
• Confidence: 97% confidence

Finding

The function signature and docstring imply the private key is used to build a usable transaction, but the code never signs inputs and leaves signature_script empty. In a blockchain-development skill, this is dangerous because developers may assume the output is ready for submission, causing failed transactions, unsafe downstream workarounds, or accidental integration of insecure signing logic.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

• Category: Not specified by scanner
• Confidence: 98% confidence

Finding

The document presents a BIP39 mnemonic generator while explicitly using an incomplete word list, yet indexes it as though all 2048 entries exist. This can produce runtime errors or, worse, non-standard mnemonics that users may believe are valid backups, leading to irreversible wallet loss when funds are stored against keys derived from incompatible seed material.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 90% confidence

Finding

The document includes wallet/private key handling and transaction construction examples without an explicit warning that private keys, mnemonics, WIFs, and signed transactions are highly sensitive and that broadcasting transactions can irreversibly transfer funds. In a blockchain development skill, users are likely to copy example code directly into real environments, which increases the chance of secret exposure or unintended mainnet transfers.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 91% confidence

Finding

This markdown file includes a complete sendKaspa example that signs and submits a transaction to Mainnet, which can move real funds irreversibly. Although the file includes general best practices, it does not clearly warn users near the example that running it may broadcast a real transaction and spend assets.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 95% confidence

Finding

The file includes instructions and an example for burning tokens, and explicitly states this will 'Permanently destroy tokens.' However, the documentation does not provide a clear cautionary warning to users about the irreversibility and risk of accidental loss when performing this operation. For markdown files, destructive behaviors affecting user assets should be accompanied by an explicit warning.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 50% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · references/krc20-tokens.md (reported line 397)May include surrounding context.

md

"""Get KRC20 token balance for an address."""
    
    response = requests.get(
        f"https://api.kaspa.org/api/v1/addresses/{address}/tokens",
        headers={"Authorization": f"Bearer {api_key}"}
    )

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 75% confidence

Finding

Docker image references without a specific tag (:latest is implicit) or digest (@sha256:...) can be silently replaced by a malicious image.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 93% confidence

Finding

The Docker example uses kaspanet/kaspad:latest, a mutable tag that can silently change over time. This harms reproducibility and can cause operators to deploy an unexpected or compromised image if the upstream tag is replaced or updated.

Content

No source excerpt is available for this finding.

Session Persistence

Medium

• Category: Rogue Agent
• Confidence: 60% confidence

Finding

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.

Content

Scanner excerpt · references/node-operations.md (reported line 94)May include surrounding context.

Docker Compose (Recommended)

Create docker-compose.yml:

yaml

version: '3.8'

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

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

Content

Scanner excerpt · references/node-operations.md (reported line 220)May include surrounding context.

2. Extract and install:

bash

unzip kaspad-v0.12.18-linux-amd64.zip
sudo mv kaspad kaspactl kaspaminer /usr/local/bin/
sudo chmod +x /usr/local/bin/kasp*

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

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

Content

Scanner excerpt · references/node-operations.md (reported line 221)May include surrounding context.

2. Extract and install:

bash

unzip kaspad-v0.12.18-linux-amd64.zip
sudo mv kaspad kaspactl kaspaminer /usr/local/bin/
sudo chmod +x /usr/local/bin/kasp*

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

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

Content

Scanner excerpt · references/node-operations.md (reported line 234)May include surrounding context.

2. Extract and install:

bash

unzip kaspad-v0.12.18-linux-amd64.zip
sudo mv kaspad kaspactl kaspaminer /usr/local/bin/
sudo chmod +x /usr/local/bin/kasp*

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

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

Content

Scanner excerpt · references/node-operations.md (reported line 235)May include surrounding context.

2. Extract and install:

bash

unzip kaspad-v0.12.18-linux-amd64.zip
sudo mv kaspad kaspactl kaspaminer /usr/local/bin/
sudo chmod +x /usr/local/bin/kasp*

Sudo/Root Execution

Medium

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

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

Content

Scanner excerpt · references/node-operations.md (reported line 274)May include surrounding context.

2. Extract and install:

bash

unzip kaspad-v0.12.18-linux-amd64.zip
sudo mv kaspad kaspactl kaspaminer /usr/local/bin/
sudo chmod +x /usr/local/bin/kasp*

Static analysis

No suspicious patterns detected.