Back to skill

Security audit

Devtopia Identity

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for wallet-backed identity, but it needs review because its private-key and authentication guidance could expose keys or produce insecure identity checks.

Review before installing or using this skill for real identities. Prefer encrypted keystore-file workflows and do not paste PEM private keys into command lines. Treat the challenge-proof examples as incomplete unless your verifier enforces fresh single-use challenges, expiration, audience/action binding, and clear token issuance. Confirm the external devtopia CLI and chain behavior before minting an identity because on-chain registration may be permanent.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (3)

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:62
Finding

Plaintext Private Keys May Be Exposed Through Command-Line Wallet Import

Content
View full analysis
``` ```text Accepts: - PEM-formatted private key: `-----BEGIN PRIVATE KEY-----...-----END PRIVATE KEY-----` - JSON keystore: `{"algorithm":"aes-256-gcm",...}` ``` ### Technical Analysis The documented wallet-import interface permits a PEM-formatted private key to be supplied directly as a command-line argument. Secrets passed this way may be exposed through: - Shell history files - Process listings and process-monitoring tools - Terminal session recording - CI/CD job logs - Command auditing and telemetry - Wrapper scripts that log their arguments The risk applies even if the imported key is subsequently encrypted because the key has already appeared in plaintext at the process invocation boundary. This behavior also conflicts with the statement at `SKILL.md:190` that the private key is “never exported in plaintext.” ### Attack Path 1. A user follows the documented syntax and passes a PEM private key directly to `devtopia id wallet import`. 2. The shell stores the command in history, or a local monitoring/logging system records the process arguments. 3. An attacker with access to the history, logs, process metadata, or recorded terminal session retrieves the plaintext key. 4. The attacker imports the key into another wallet or compatible signing tool. 5. The attacker signs proofs or transactions while impersonating the legitimate agent. ### Impact Assessment Disclosure of the private key grants the attacker the cryptographic authority associated with the wallet. Depending on how the identity is used, this may allow: - Agent identity impersonation - Forging challenge-response proofs - Unauthorized blockchain transaction signing - Unauthorized marketplace actions - Permanent compromise of the wallet-b ...[truncated 152 chars]
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Warning
Location
references/challenge-proofs.md:5
Finding

Challenge Proofs Are Incorrectly Described as Non-Replayable Without Verifier-Side Enforcement

Content
View full analysis
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Warning
Location
references/challenge-proofs.md:55
Finding

Documented P-256 Proofs Are Incompatible With the EVM ecrecover Verification Example

Content
View full analysis
", "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----" ); console.log(isValid ? "✅ Proof valid" : "❌ Proof invalid"); ``` ### Technical Analysis EVM `ecrecover` recovers addresses from secp256k1 ECDSA signatures. It does not verify signatures produced by the documented P-256/secp256r1 keys. Therefore, a valid proof generated according to the Skill cannot be verified by the shown Solidity code. The Solidity example also fails to define: - How the challenge becomes the required 32-byte digest - Whether a domain prefix is used - The signature encoding - Canonicality requirements - How the P-256 public key maps to an EVM address The JavaScript ...[truncated 1821 chars]
Remediation
View remediation
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Rogue AgentSelf-Modification, Session Persistence
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Findings (5)

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 · SKILL.md (reported line 19)May include surrounding context.

text

This will:
1. Create or load a local wallet (if one doesn't exist)
2. Generate your public/private key pair (ECDSA P-256)
3. Sign the identity registration transaction
4. Mint your identity on Base chain (Chain ID 8453)

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
97% confidence
Finding

The documentation makes a strong security claim that private keys are never exported in plaintext, yet elsewhere it explicitly supports importing raw PEM private keys. Even if this is an import rather than an export path, the claim is misleading and could cause users to handle highly sensitive key material less cautiously or paste plaintext keys into unsafe contexts.

Content

No source excerpt is available for this finding.

File System Enumeration

Medium
Category
Data Exfiltration
Confidence
60% confidence
Finding

Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.

Content

Scanner excerpt · SKILL.md (reported line 209)May include surrounding context.

"Keystore not found"

bash
# Check if it exists:
ls -la ~/.devtopia/identity-keystore.json

# If missing, restore from backup:
devtopia id wallet import <backup-file>

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
95% confidence
Finding

The documentation asserts that challenge proofs are non-replayable because challenges contain a nonce or timestamp, but the examples only show signing arbitrary static strings and do not define any enforcement, validation, or freshness requirements. In an identity/authentication skill, this can lead implementers to accept reusable signed challenges, enabling replay of previously captured proofs and weakening agent authentication guarantees.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The session authentication example instructs users to derive and later verify a token from the proof, but the documented proof format contains no token field or token issuance flow. This mismatch can cause insecure ad hoc implementations where developers invent unsound token extraction or treat signatures as bearer tokens without proper binding, expiration, or verification semantics.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.