Back to skill

Security audit

Base 8004

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent onchain registration guide, but it needs review because it tells users to print a wallet private key and publish persistent public agent metadata.

Review before installing or following this skill. Do not print wallet private keys; generate and store them in a secure wallet, encrypted keystore, or secret manager, and rotate any key that has appeared in logs. Publish only intentionally public agent names, descriptions, images, and service endpoints because onchain metadata is public and persistent. Use pinned dependencies or a trusted lockfile when running the examples.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:35
Finding
Wallet Private Key Exposed Through Console Logging<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 35–40 **Vulnerability Type**: Sensitive information exposure through logging **Risk Level**: High ### Vulnerable Code ```typescript import { generatePrivateKey } from "viem/accounts"; const privateKey = generatePrivateKey(); console.log("Private key:", privateKey); ``` ### Technical Analysis The documented wallet-generation procedure writes the complete Ethereum private key to standard output. Private keys are bearer credentials: possession of the key grants control over the associated wallet without any additional authentication. Standard output may be retained in terminal history, CI/CD logs, agent execution transcripts, remote development sessions, shell recordings, monitoring systems, or screen-sharing captures. This instruction also directly conflicts with the document's later warning never to expose private keys in logs. ### Attack Path 1. A user or automated agent follows the documented wallet-generation procedure. 2. The generated private key is printed to standard output. 3. The output is captured by an execution transcript, CI logger, terminal recorder, remote session, or another process with access to the logs. 4. An unauthorized party retrieves the exposed key. 5. The party imports the key into an Ethereum-compatible wallet. 6. The party signs arbitrary transactions, transfers wallet funds, and may transfer or otherwise control the ERC-8004 identity associated with the wallet. ### Impact Assessment An attacker who obtains the logged private key receives the same blockchain authority as the legitimate wallet owner. The attacker can spend all assets controlled by the key, authorize transactions, manipulate registrations available to the wallet, and take control of the associated on-chain identity. Blockchain transactions are generally irreversible, so recovery may be impossible after funds or identity assets are transferred. ]]>
Remediation
<![CDATA[ ## Remediation Suggestions - Remove the `console.log` statement and never emit private keys through standard output, application logs, exceptions, telemetry, or debugging tools. - Generate and store the key directly in a dedicated secret manager, hardware-backed keystore, encrypted wallet, or permission-restricted environment file. - If a local secret file is necessary, create it with restrictive permissions such as owner read/write only and ensure it is excluded from version control. - Avoid generating wallet credentials in CI/CD jobs or agent environments that automatically retain execution output. - Add secret-scanning controls for repositories, build logs, and execution transcripts. - Explicitly instruct users to rotate the wallet immediately if its private key has ever appeared in captured output. - Prefer a documented workflow that displays only the derived public wallet address. ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:31
Finding
Unpinned Third-Party Dependency Installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 31 **Vulnerability Type**: Mutable and unverified dependency resolution **Risk Level**: Medium ### Vulnerable Code ```bash npm install viem ``` ### Technical Analysis The installation command does not pin `viem` to an exact reviewed version and does not require an integrity-controlled lockfile. Consequently, the installed code depends on the package version and dependency graph available from the configured npm registry when the command is executed. This creates a supply-chain exposure because later releases, transitive dependencies, registry compromise, or a modified registry configuration could cause users to install code that was not part of the audited Skill. npm installation can also invoke package lifecycle scripts unless those scripts are explicitly disabled. No evidence indicates that the legitimate `viem` package is malicious; the issue is the mutable and insufficiently constrained installation process. ### Attack Path 1. A user follows the Skill and runs the unpinned installation command. 2. npm resolves the package and its transitive dependencies using the registry configured on the user's system. 3. A compromised release, dependency, registry response, or maliciously configured registry supplies unreviewed code. 4. npm installs the resolved package and may execute applicable lifecycle scripts with the user's local permissions. 5. The installed code gains access to the project environment and may later execute alongside wallet-generation and transaction-signing operations. 6. Malicious code could read local secrets, including wallet credentials, or alter transaction-related behavior. ### Impact Assessment Successful exploitation would initially provide code execution with the permissions of the user running npm. The accessible scope could include project files, environment variables, npm credentials, local configuration, and other resources available to that account. Becau ...[truncated 210 chars]
Remediation
<![CDATA[ ## Remediation Suggestions - Pin `viem` to an exact version that has been reviewed rather than relying on the latest registry release. - Commit a trusted lockfile and use `npm ci` so installations reproduce the reviewed dependency graph. - Verify package provenance and lockfile integrity before installation. - Audit direct and transitive dependencies with appropriate supply-chain and vulnerability-scanning tools. - Use `npm ci --ignore-scripts` where lifecycle scripts are unnecessary and compatibility has been validated. - Document the expected npm registry and protect project configuration from registry substitution. - Perform wallet operations in a minimally privileged, isolated environment that does not expose unrelated credentials. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (3)

Credential Access

High
Category
Privilege Escalation
Content
Add `.env` to `.gitignore` if it isn't already:

```
echo ".env" >> .gitignore
```

### Step 5: Security rules
Confidence
60% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The skill encourages publishing agent metadata and service endpoints onchain but does not clearly warn that this information becomes publicly visible, widely indexed, and difficult or impossible to fully retract. This can expose operational details, internal endpoint structure, branding, or capability information that may aid targeting, enumeration, or unwanted long-term attribution.

Missing User Warnings

Medium
Confidence
97% confidence
Finding
The guide explicitly prints a newly generated private key to stdout, which can be captured by terminal scrollback, shell logging, CI logs, screen recordings, pair-programming sessions, or remote development environments. Because this key controls onchain assets and identity, any disclosure can immediately enable wallet takeover, theft of funds, and unauthorized updates to the registered agent identity.

Static analysis

No suspicious patterns detected.