Most URL, hidden-directory, Git ignore, and Markdown fence detections are benign documentation. Confirmed risks involve plaintext wallet-key handling and transmitting prompts and payment signatures to BlockRun. Additional risks include an unpinned executable dependency with key access and paid requests without approval or spending limits.
The template directs users to provide a raw EVM private key for a wallet holding USDC. Compromise of that plaintext credential can cause financial loss.
The setup creates a plaintext .env file that the next instruction populates with a wallet private key. Local exposure of that file can compromise funds.
The skill installs the latest blockrun-llm package, then runs it while a wallet private key is available. The audited files cannot verify the package's local-signing assurance.
The package command has no version constraint, and the documented client runs with the configured wallet key. No package implementation is present in the audited files.
1. Your request goes to BlockRun API (https://blockrun.ai)
The documented workflow sends user prompts to the BlockRun API and later sends a payment signature. This is expected but real external data transmission.
The audit found no prompt injection text, but the skill has real high-impact secret and payment risks. Several static hits were Markdown or license false positives, while private-key setup, .env usage, external SDK execution, and paid BlockRun API calls remain confirmed concerns.
The template explicitly asks for an EVM wallet private key. No real key is present, but the required setup handles a secret that can authorize spending.
The line is a safety claim, but it confirms the skill depends on handling a wallet private key. The secret-handling risk remains even without evidence of exfiltration.
The line is a security assurance, but it confirms private-key handling is part of the workflow. The risk is secret exposure or misuse by the SDK or local environment.
The skill can let an AI assistant trigger paid image generation through a wallet-backed x402 flow. Without explicit confirmations or spend limits, repeated requests could consume user funds.
The README says Claude will use the skill automatically, and both README and SKILL.md describe paid signing and image generation. This directly supports the spending-risk assessment.
The setup installs blockrun-llm without a version pin or hash verification. That package controls image requests and local payment signing, so supply-chain compromise has higher impact.
Both setup sections use pip install blockrun-llm without a version or hash. The same files explain that the SDK signs payment data locally.
Capability review items (5)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
The static label is imprecise, but the fenced block instructs users or agents to run pip install blockrun-llm. Installing an unpinned package is external code execution risk.
1. Your request goes to BlockRun API (https://blockrun.ai)
The skill explicitly routes user image prompts to the BlockRun API. That is intended behavior, but it is real external network disclosure of prompt content and payment metadata.
Confirmed findings center on wallet private-key handling, broad .env loading, external paid network generation, and local image file writes. Markdown code-fence findings were false positives, and the bundled PNG was manually reviewed as benign. No prompt injection attempt was found in the reviewed text files.
The README instructs users to create a .env file for configuration. The surrounding setup stores a wallet private key there, making this sensitive secret handling.
This line acknowledges that the skill handles a wallet private key. Even with local signing claims, the key remains highly sensitive material used by the skill.
# Parse arguments first to get output_dir for .env loading
The comment describes using output_dir for .env loading, which is implemented later in the script. In context, that .env can provide the wallet private key.
The script loads .env from output_dir before checking BLOCKRUN_WALLET_KEY. A user-selected directory controlling secret loading is a high-risk configuration pattern.
The script loads .env from the current working directory before reading the wallet key. This can unintentionally consume plaintext secrets from a project directory.
The script lets output_dir come from arguments or OUTPUT_DIR, then loads .env from that directory before reading BLOCKRUN_WALLET_KEY. A prompt or wrapper that changes the output path could change which wallet key is used.
The code path is direct: output_dir is selected on line 21, .env is loaded from it on line 24, and the wallet key is read on line 29.
Setup instructions install blockrun-llm without a pinned version or hash. This increases supply-chain risk because the package handles wallet signing material.
Both setup sections show an unversioned pip install command, and the runtime passes a private key into the installed SDK.
Paid Generation Can Spend User Funds Without Script Confirmation
The skill presents image generation as an automatic action and the script calls client.generate directly. It does not show a local confirmation step with model price before making a paid request.
The documentation describes pay-per-request usage and the script invokes generation after printing the selected model, with no explicit confirmation gate.
Capability review items (14)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
The script loads a .env file from output_dir before reading the wallet key. Because output_dir can be user-selected, this is sensitive configuration loading.
The script loads .env from the skill directory before reading the wallet key. Storing wallet credentials beside the skill creates sensitive local secret exposure.
The loader reads .env from output_dir, which is controlled by an argument or environment variable. This can alter which wallet key the paid request uses.
The script writes generated PNG bytes to output_dir, which can come from an argument or environment variable. This intended behavior is still a filesystem side effect with overwrite and path-placement risk.
output_dir = sys.argv[3] if len(sys.argv) > 3 else os.environ.get("OUTPUT_DIR", os.getcwd())
The script reads OUTPUT_DIR from the environment, and that value controls both file output and the first .env lookup path. This can affect where secrets are loaded from.
The setup directs users to an external bridge service to obtain funds. This is a user-facing financial network dependency, though it is not hidden behavior.
Static critical heuristics are not confirmed as malicious, and no prompt injection attempt was found. However, the skill requires a wallet private key, loads .env files, signs paid x402 requests, and uses network calls through a third-party SDK. This is high risk for a community marketplace skill and should not be published without stronger review and user warnings.
4
Files scanned
471
Lines analyzed
12
Review items
2
False positives ignored
Capability review items (7)
These are real local capabilities that may be expected for this skill, so they require review but are not counted as confirmed malicious behavior.
The skill instructs users to place a private wallet key in .env or BLOCKRUN_WALLET_KEY, then passes that key into the BlockRun ImageClient. This is a true positive for credential access because compromise or misuse of this value can authorize crypto payments.
The documentation and script directly require BLOCKRUN_WALLET_KEY and instantiate ImageClient with it. The local-signing claim reduces exfiltration certainty but does not remove the credential handling risk.
Network Payment Flow Uses Third-Party SDK and Signatures
The skill sends generation requests to BlockRun and documents that a payment signature is sent to the server. This is a true positive for network plus credential-adjacent behavior because the workflow spends USDC through signed x402 requests.
The files explicitly describe API calls, HTTP 402 payment handling, local signing, and signature transmission. No evidence proves malicious exfiltration, but the paid network flow is confirmed.
Multiple .env Files Are Loaded from Variable Locations
The script loads .env from the requested output directory, current working directory, and skill directory before reading BLOCKRUN_WALLET_KEY. This can unintentionally select a wallet key from a directory chosen by the caller.
The output directory can come from an argument or environment variable, and load_dotenv is called on that path. The behavior is clear, but impact depends on how users run the skill.
Generated Files Are Written to Caller-Controlled Paths
The script writes decoded PNG bytes into output_dir using predictable filenames. This is legitimate image generation behavior, but it can overwrite existing generated_image files in the selected directory.
The file write is directly present and uses output_dir. The likely purpose is benign, but the overwrite and path-control behavior remains relevant.
The skill metadata allows Bash execution for python, python3, pip, and pip3. This is expected for a script-based skill, but it increases risk because the skill can install packages and execute local Python code.
The allowed-tools declaration and installation commands are explicit. This is not malicious by itself, but it expands the execution surface for a community skill.
Hardcoded URL findings point to documentation links for Base, BlockRun, PyPI, x402, and the Apache License. These references are expected for setup and attribution.
The URLs are visible documentation links and not hidden endpoints. The actual network risk comes from the SDK request flow, not these links.
The base64 decode finding is used to save data:image PNG results returned by the image generation API. This appears to be normal handling of image data, not obfuscation.
The code checks for a PNG data URL and writes decoded bytes as an image file. This is a legitimate image-output pattern.
Static false positives ignored (2)
These static matches were dismissed by semantic review or matched schema-only tokens, so they are shown for transparency but do not drive the quality score.
Markdown Code Fences Misclassified as Ruby Backticks
The external command findings in README.md and SKILL.md largely point to Markdown fenced examples for installation and usage. They are documentation examples, not Ruby backtick execution in code.
The cited lines are Markdown code blocks and normal shell examples. The static label does not match executable Ruby code.
Apache License Text Misclassified as Weak Cryptography
The weak cryptography findings in LICENSE and SKILL.md do not identify cryptographic implementation code. The LICENSE lines are standard Apache License text, and SKILL.md only names the Nano Banana product.
No hashing, encryption, or signature algorithm implementation appears at these locations. The matches are false positives from ordinary license and description text.
Legitimate image generation skill using x402 micropayments. Private keys are used only for local EIP-712 signing with signatures transmitted, not keys. No obfuscation or exfiltration patterns detected.
Legitimate image generation skill using x402 micropayments. Private keys are used only for local EIP-712 signing with signatures transmitted, not keys. No obfuscation or exfiltration patterns detected.
Legitimate image generation skill using x402 micropayments. Private keys are used only for local EIP-712 signing with signatures transmitted, not keys. No obfuscation or exfiltration patterns detected.