Back to skill

Security audit

Chia WalletConnect - Telegram Verification

Security checks for vulnerabilities and agentic risk

Overview

This skill is purpose-aligned for wallet verification, but its current implementation has serious authentication and privacy weaknesses in a security-sensitive wallet-to-Telegram binding flow.

Review this before installing or deploying. It should not be used for access control, airdrops, voting, or identity binding until challenges are generated and stored server-side, Telegram Web App initData is verified, nonces are single-use, future timestamps are rejected, status endpoints are authenticated, sensitive logging is removed, remote scripts are bundled or integrity-pinned, and dependency issues are updated. Users should also be told clearly that their Telegram identity may be linked with their wallet address and signature data and that MintGarden receives verification material.

Vulnerability Patterns
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (5)

T09 · Insecure Skill Coding Practices

Error
Location
webapp/app.js:183
Finding
Replayable Wallet Challenges and Untrusted Telegram Identity Binding<![CDATA[ ## Vulnerability Details **File Location**: `webapp/app.js:183-244`, `server/index.js:28-59`, `lib/challenge.js:23-32` **Vulnerability Type**: Replay attack and broken identity binding **Risk Level**: High ### Vulnerable Code ```javascript // webapp/app.js:183-199 function generateChallenge() { const timestamp = Date.now(); const nonce = Math.random().toString(36).substring(2, 15); const userId = tg.initDataUnsafe?.user?.id || 'telegram_user'; const message = `Verify ownership of Chia wallet:\n${currentAddress}\n\nTimestamp: ${timestamp}\nNonce: ${nonce}\nUser: ${userId}`; challengeData = { message, nonce, timestamp, address: currentAddress, userId }; elements.challengeMessage.textContent = message; elements.challengeSection.classList.remove('hidden'); console.log('📝 Challenge generated:', challengeData); } ``` ```javascript // webapp/app.js:233-244 const verificationData = { address: currentAddress, message: challengeData.message, signature: signature, publicKey: currentPublicKey, userId: challengeData.userId, timestamp: challengeData.timestamp }; // Send data back to Telegram bot tg.sendData(JSON.stringify(verificationData)); ``` ```javascript // server/index.js:28-59 const { address, message, signature, publicKey, userId, timestamp } = req.body; // Validate request if (!address || !message || !signature) { return res.status(400).json({ success: false, error: 'Missing required fields: address, message, signature' }); } // Validate timestamp (challenge must be recent) if (!validateChallengeTimestamp(timestamp)) { return res.status(400).json({ success: false, error: 'Challenge expired. Please generate a new one.' }); } const result = await verifySignature(address, message, signature, publicKey); if (result.verified) { pendingVerifications.set(userId, { address, verified: true, timestamp: Date.now() }); } ``` ```javascript // lib/challenge.js:23-32 f ...[truncated 2301 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Generate challenges exclusively on the trusted server using `crypto.randomBytes()` or `crypto.randomUUID()`. 2. Store each challenge with its nonce, expected Telegram user ID, expected wallet address, issuance time, expiration time, and unused/used state. 3. Validate Telegram Web App `initData` using Telegram's documented HMAC procedure. Do not authorize users based on `initDataUnsafe`. 4. Reconstruct the expected message on the server rather than accepting an arbitrary client-provided message. 5. Require an exact identity match between the verified Telegram user and the user bound to the stored challenge. 6. Enforce both timestamp bounds: ```javascript const age = Date.now() - issuedAt; const valid = age >= 0 && age <= FIVE_MINUTES; ``` 7. Atomically mark the nonce as consumed after successful verification and reject all subsequent attempts. 8. Expire and remove unused challenges after a short interval. 9. Ensure bot-side handlers bind successful verification to `msg.from.id`, not a `userId` supplied in Web App payload data. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
server/index.js:98
Finding
Unauthenticated Wallet Status Disclosure with Unrestricted CORS<![CDATA[ ## Vulnerability Details **File Location**: `server/index.js:12`, `server/index.js:98-113` **Vulnerability Type**: Missing authorization and privacy exposure **Risk Level**: Medium ### Vulnerable Code ```javascript // server/index.js:12 app.use(cors()); ``` ```javascript // server/index.js:98-113 app.get('/api/status/:userId', (req, res) => { const { userId } = req.params; const verification = pendingVerifications.get(userId); if (verification) { res.json({ success: true, ...verification }); } else { res.json({ success: false, verified: false, message: 'No verification found for this user' }); } }); ``` ### Technical Analysis Calling `cors()` without an origin policy permits browser scripts from arbitrary origins to read endpoint responses. The status endpoint has no authentication or authorization and accepts a user identifier directly from the URL. A successful response includes the stored Chia address, verification state, and timestamp. The different responses for present and absent identifiers also create an enumeration oracle. CORS is not itself an authentication mechanism. Restricting CORS would reduce browser-based exploitation, but the endpoint must independently authenticate and authorize every request. ### Attack Path 1. An attacker prepares a web page or script that iterates over candidate Telegram user identifiers. 2. The script requests `/api/status/{userId}` for each candidate. 3. Unrestricted CORS allows a hostile browser origin to read each response. 4. Different responses reveal which identifiers have verification records. 5. Successful responses disclose the linked wallet address and verification timestamp. 6. The attacker correlates Telegram identities with public blockchain activity or uses the data for profiling and targeted attacks. ### Impact Assessment The vulnerability exposes identity-linked wallet information to unauthenticated parties. It may enable user en ...[truncated 250 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Require authentication for the status endpoint. 2. Authorize callers so a user can retrieve only their own status, unless a specifically authorized bot or administrator is making the request. 3. Do not use an enumerable Telegram identifier as an unrestricted URL lookup key. 4. Return only the minimum data required; avoid exposing full wallet addresses and exact timestamps unless necessary. 5. Configure CORS with an explicit allowlist: ```javascript app.use(cors({ origin: ['https://trusted-mini-app.example'], methods: ['GET', 'POST'], credentials: true })); ``` 6. Apply rate limiting and enumeration detection to status requests. 7. Use uniform responses where practical to avoid revealing whether arbitrary identifiers exist. 8. Place privileged bot-to-server endpoints behind service authentication rather than relying on browser-origin restrictions. ]]>

T03 · Remote Payload Retrieval and Execution

Error
Location
webapp/index.html:6
Finding
Remote Wallet-Handling Scripts Execute Without Integrity Protection<![CDATA[ ## Vulnerability Details **File Location**: `webapp/index.html:6-7` **Vulnerability Type**: Mutable remote code execution through third-party browser dependencies **Risk Level**: High ### Vulnerable Code ```html <script src="https://telegram.org/js/telegram-web-app.js"></script> <script src="https://unpkg.com/@walletconnect/sign-client@2.11.0/dist/index.umd.js"></script> ``` ### Technical Analysis The Mini App loads executable JavaScript directly from third-party hosts. No Subresource Integrity hashes are provided, and no restrictive Content Security Policy is defined in the audited application. The unpkg-hosted WalletConnect component executes with the same browser-origin privileges as the application. It participates in the wallet connection and signature workflow and can access DOM state and application globals. Although the URL includes a package version, the application still trusts remote delivery at runtime. A compromised CDN, package publication, DNS/TLS endpoint, or delivery path could change the effective code after the Skill itself has been reviewed. ### Attack Path 1. An attacker compromises a package release, CDN account, CDN infrastructure, or another part of the remote delivery chain. 2. The Mini App loads the modified JavaScript when a user opens the verification page. 3. The remote code executes in the application's origin. 4. It observes or modifies WalletConnect session setup and signature requests. 5. It can exfiltrate addresses, public keys, challenges, signatures, session metadata, or Telegram Web App data. 6. It may also alter the message presented for signing or redirect wallet interactions to attacker-controlled services. ### Impact Assessment Compromised remote code can control the browser-side wallet verification flow and access sensitive identity-linked cryptographic proof material. It may deceive users about what they are signing, undermine verification integrity, and transmit wallet or Telegram data to unauthoriz ...[truncated 187 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Bundle reviewed WalletConnect code into the application build and serve it from the same controlled origin. 2. Pin dependencies to exact versions and review lockfile changes before deployment. 3. If remote scripts are unavoidable, use Subresource Integrity with immutable resources where supported: ```html <script src="https://cdn.example/library.min.js" integrity="sha384-..." crossorigin="anonymous"></script> ``` 4. Deploy a restrictive Content Security Policy that limits `script-src`, `connect-src`, `frame-src`, and other relevant directives to required hosts. 5. Avoid generic package-CDN URLs for production security-critical applications. 6. Maintain an inventory of WalletConnect relay and Telegram endpoints required by the application and deny unnecessary network destinations. 7. Perform dependency vulnerability and provenance checks as part of the release process. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
webapp/app.js:103
Finding
WalletConnect Session and Cryptographic Proof Data Logged to Browser Console<![CDATA[ ## Vulnerability Details **File Location**: `webapp/app.js:103-103`, `webapp/app.js:131-131`, `webapp/app.js:159-177`, `webapp/app.js:199-199`, `webapp/app.js:227-227` **Vulnerability Type**: Sensitive data exposure through logging **Risk Level**: Medium ### Vulnerable Code ```javascript // webapp/app.js:103 console.log('🔗 WalletConnect URI:', uri); ``` ```javascript // webapp/app.js:131 console.log('✅ Session approved:', session); ``` ```javascript // webapp/app.js:159-177 console.log('💼 Wallet address:', currentAddress); // Get public key using CHIP-0002 try { const pubKeyResult = await signClient.request({ topic: session.topic, chainId: CHIA_CHAIN, request: { method: 'chip0002_getPublicKeys', params: { limit: 1, offset: 0 } } }); if (pubKeyResult && pubKeyResult.length > 0) { currentPublicKey = pubKeyResult[0]; console.log('🔑 Public key:', currentPublicKey); } } ``` ```javascript // webapp/app.js:199 console.log('📝 Challenge generated:', challengeData); ``` ```javascript // webapp/app.js:227 console.log('✍️ Signature received:', signature); ``` ### Technical Analysis The application writes the WalletConnect URI, complete approved session object, wallet address, public key, challenge object, Telegram-linked user identifier, and resulting signature to the browser console. Console data may be retained in remote debugging sessions, support screenshots, browser diagnostic exports, embedded WebView logs, or third-party telemetry. The WalletConnect URI and session object are especially sensitive during connection establishment, while signed proofs become more dangerous because replay controls are inadequate. This behavior also conflicts with the project's own documentation, which states that signatures and public keys should not be logged. ### Attack Path 1. A user performs wallet verification on a shared or remotely debugged device. 2. The application logs session and proo ...[truncated 808 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove production logging of WalletConnect URIs, sessions, addresses, public keys, full challenges, user identifiers, and signatures. 2. Introduce a development-only logger that is disabled in production builds. 3. Redact values when diagnostics are essential: ```javascript console.debug('Wallet connected', { addressSuffix: currentAddress?.slice(-6) }); ``` 4. Never send these values to analytics or error-reporting services without explicit necessity, consent, retention controls, and field-level redaction. 5. Document a short retention policy for any server-side verification logs. 6. Invalidate or expire WalletConnect pairing/session material promptly when it is no longer required. 7. Correct the replay and nonce-consumption weaknesses so exposed proofs cannot be reused. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
server/index.js:24
Finding
Public Verification Endpoint Can Be Abused to Exhaust Server and Upstream Resources<![CDATA[ ## Vulnerability Details **File Location**: `server/index.js:24-89`, `lib/verify.js:14-42` **Vulnerability Type**: Missing rate limits, strict validation, and outbound request timeout **Risk Level**: Medium ### Vulnerable Code ```javascript // server/index.js:24-89 app.post('/api/verify', async (req, res) => { try { const { address, message, signature, publicKey, userId, timestamp } = req.body; // Validate request if (!address || !message || !signature) { return res.status(400).json({ success: false, error: 'Missing required fields: address, message, signature' }); } // Validate timestamp (challenge must be recent) if (!validateChallengeTimestamp(timestamp)) { return res.status(400).json({ success: false, error: 'Challenge expired. Please generate a new one.' }); } console.log(`🔐 Verifying signature for ${address}...`); // Verify signature with MintGarden API const result = await verifySignature(address, message, signature, publicKey); if (result.verified) { pendingVerifications.set(userId, { address, verified: true, timestamp: Date.now() }); return res.json({ success: true, verified: true, address, userId, message: 'Wallet ownership verified successfully!' }); } else { return res.status(400).json({ success: false, verified: false, error: result.error || 'Signature verification failed' }); } } catch (error) { console.error('❌ Verification endpoint error:', error); res.status(500).json({ success: false, error: error.message || 'Internal server error' }); } }); ``` ```javascript // lib/verify.js:14-42 async function verifySignature(address, message, signature, publicKey) { try { const response = await fetch(`${MINTGARDEN_API}/address/verify_signature`, { method: 'POST', ...[truncated 2406 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Apply rate limits per IP, authenticated user, Telegram identity, and wallet address. 2. Require a valid server-issued challenge before making any upstream verification request. 3. Enforce a strict JSON schema, including expected types, formats, and maximum lengths for every field. 4. Validate Chia addresses and signature/public-key encodings locally before contacting MintGarden. 5. Add an outbound timeout using `AbortController` or an equivalent mechanism. 6. Limit concurrent MintGarden requests and use bounded queues or circuit breakers. 7. Return generic client-facing errors while logging sanitized internal diagnostics. 8. Add monitoring for request spikes, timeout rates, upstream throttling, and repeated invalid proofs. 9. Configure explicit body limits appropriate for the small verification payload. 10. Consider authenticated service-to-service verification through the Telegram bot rather than exposing a broadly callable public endpoint. ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
  • Memory PoisoningPersistent Context Injection, Context Window Stuffing, Memory Manipulation
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
Findings (41)

Known Vulnerable Dependency: elliptic==6.5.7 — 3 advisory(ies): CVE-2025-14505 (Elliptic Uses a Cryptographic Primitive with a Risky Implementation); CVE-2024-48948 (Valid ECDSA signatures erroneously rejected in Elliptic); GHSA-vjh7-7g9h-fjfh (Elliptic's private key extraction in ECDSA upon signing a malformed input (e.g. )

Critical
Category
Supply Chain
Confidence
98% confidence
Finding
The lockfile includes elliptic 6.5.7, which has multiple advisories including a critical issue involving potential ECDSA private key extraction on malformed signing input. Even as a transitive dependency, this is highly concerning in a wallet-connect and signature-centric application because signing and key handling are core security functions.

Tp4

High
Category
MCP Tool Poisoning
Confidence
97% confidence
Finding
The documentation presents the skill as performing wallet verification via MintGarden, but the described app flow actually collects wallet identifiers, signatures, public keys, timestamps, and Telegram-linked data and sends them back to the bot backend for processing. That mismatch is dangerous because integrators and users may trust the skill as a narrow verifier while it functions as a data collection and relay component, increasing privacy risk and the chance of unsafe downstream handling.

Ae1

High
Category
analysis-evasion
Content
4. Update in `webapp/app.js`
Confidence
100% confidence
Finding
Referenced artifact was not completely inspected

Known Vulnerable Dependency: defu==6.1.4 — 1 advisory(ies): CVE-2026-35209 (defu: Prototype pollution via `__proto__` key in defaults argument)

High
Category
Supply Chain
Confidence
86% confidence
Finding
defu 6.1.4 is affected by prototype pollution via __proto__ in defaults-merging logic. If attacker-controlled objects can be merged anywhere in the dependency chain, this can alter object behavior globally and may enable logic corruption, authorization bypass, or secondary exploitation.

Known Vulnerable Dependency: h3==1.15.5 — 4 advisory(ies): CVE-2026-33128 (h3 has a Server-Sent Events Injection via Unsanitized Newlines in Event Stream F); CVE-2026-86252 (h3: SSE Event Injection via Unsanitized Carriage Return (`\r`) in EventStream Da); CVE-2026-86251 (h3: Double Decoding in `serveStatic` Bypasses `resolveDotSegments` Path Traversa) +1 more

High
Category
Supply Chain
Confidence
85% confidence
Finding
h3 1.15.5 is affected by multiple advisories including SSE injection and path traversal-related issues. Although likely transitive via unstorage rather than directly exposed, these bug classes can become serious if any embedded server, static serving, or event-stream functionality is reachable in the deployed environment.

Known Vulnerable Dependency: path-to-regexp==0.1.12 — 1 advisory(ies): CVE-2024-45296 (path-to-regexp vulnerable to Regular Expression Denial of Service via multiple r)

High
Category
Supply Chain
Confidence
84% confidence
Finding
path-to-regexp 0.1.12 is vulnerable to ReDoS via crafted route patterns or path input. Express relies on this package, and although exploitation depends on route definitions and traffic patterns, a public-facing web app can suffer request-processing slowdown or denial of service from pathological inputs.

Known Vulnerable Dependency: picomatch==2.3.1 — 2 advisory(ies): CVE-2026-33672 (Picomatch: Method Injection in POSIX Character Classes causes incorrect Glob Mat); CVE-2026-33671 (Picomatch has a ReDoS vulnerability via extglob quantifiers)

High
Category
Supply Chain
Confidence
80% confidence
Finding
picomatch 2.3.1 is flagged for method-injection and ReDoS issues in glob matching. This is likely reachable only if the application or its dependencies process attacker-controlled glob patterns, but if exposed, crafted patterns can cause heavy CPU use or incorrect matching behavior.

Known Vulnerable Dependency: ws==7.5.10 — 1 advisory(ies): CVE-2026-48779 (ws: Memory exhaustion DoS from tiny fragments and data chunks)

High
Category
Supply Chain
Confidence
90% confidence
Finding
ws 7.5.10 is flagged for memory-exhaustion denial of service through fragmented websocket frames. WalletConnect relies heavily on websocket-style transport, so this dependency is more dangerous here than in a non-realtime app because attacker-controlled peers may be able to drive resource exhaustion on connection-handling paths.

Memory Manipulation

High
Category
Memory Poisoning
Content
});
  }
  
  // Reset state
  currentSession = null;
  currentAddress = null;
  currentPublicKey = null;
Confidence
80% confidence
Finding
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The architecture explicitly sends wallet address, signed message, signature, and optional public key through Telegram web_app_data and then to the MintGarden verification API, but the README does not prominently warn that this shares wallet-linked identity data with Telegram infrastructure and a third party. Users and integrators may assume verification is local, creating an avoidable privacy risk through correlation of Telegram identity with blockchain addresses.

Lp3

Medium
Category
MCP Least Privilege
Confidence
94% confidence
Finding
The skill declares no explicit tool scope or permission boundaries even though it clearly relies on environment variables and external network access. In an agent ecosystem, missing scope declarations weaken least-privilege controls and make it harder for operators to understand or restrict what the skill can access at runtime.

Missing User Warnings

Medium
Confidence
96% confidence
Finding
The skill lacks a clear warning that wallet address, signed challenge, public key, and Telegram-associated verification data are transmitted to both the bot backend and third-party services. Even if the transfer is part of the intended feature, failing to disclose it undermines informed consent and can expose users to privacy leakage, correlation of wallet and Telegram identities, and unexpected third-party processing.

External Transmission

Medium
Category
Data Exfiltration
Content
### MintGarden Signature Verification

**Endpoint:** `POST https://api.mintgarden.io/address/verify_signature`

```json
{
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
### MintGarden Signature Verification

**Endpoint:** `POST https://api.mintgarden.io/address/verify_signature`

```json
{
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
### MintGarden Signature Verification

**Endpoint:** `POST https://api.mintgarden.io/address/verify_signature`

```json
{
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
### MintGarden Signature Verification

**Endpoint:** `POST https://api.mintgarden.io/address/verify_signature`

```json
{
Confidence
50% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
This function transmits user-supplied wallet address, signed message, signature, and public key to a third-party service (MintGarden) for verification. Even if the data is not secret in the cryptographic sense, it is wallet-linked identity data and message content that may be sensitive or deanonymizing; the code shows no minimization, consent flow, or indication that verification is delegated off-platform.

Autonomous Decision Making

Medium
Category
Excessive Agency
Content
res.json({
      success: false,
      verified: false,
      message: 'No verification found for this user'
    });
  }
});
Confidence
75% confidence
Finding
Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Description-Behavior Mismatch

Medium
Confidence
98% confidence
Finding
The code and comments state that signatures are verified via MintGarden API, but no such verification occurs in the web app. Instead, the app sends the signed message and related identity data to the Telegram bot and immediately shows a success state, which can mislead users and downstream systems into treating an unverified signature as trustworthy.

Intent-Code Divergence

Medium
Confidence
99% confidence
Finding
The inline comment claims verification is done via MintGarden API, but the implementation only calls tg.sendData() to forward the payload to a Telegram bot. This discrepancy is security-relevant because it masks where trust decisions actually occur and may cause reviewers or users to believe verification has already happened when it has not.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The app transmits wallet address, signature, public key, Telegram user ID, and timestamp to the Telegram bot without an explicit user-facing disclosure at the point of submission. In a wallet-verification context, this combines blockchain identity with platform identity, increasing privacy and tracking risk if users are not clearly informed and given meaningful consent.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
This UI initiates wallet connection and message signing for ownership verification but does not present a clear, explicit warning that the user's wallet address/public key will be exposed and that they are approving a cryptographic signature. In a Telegram Web App handling wallet verification, users may mistake the flow as low-risk authentication and approve signatures without understanding the privacy and trust implications, increasing phishing and consent risks.

Missing User Warnings

Low
Confidence
81% confidence
Finding
The markdown exposes a concrete project identifier in the sample environment configuration and only later notes that users should replace it for production. Because configuration values may affect service ownership, quotas, or attribution, the lack of an immediate warning in the example can lead users to deploy with shared credentials unintentionally.

Intent-Code Divergence

Low
Confidence
90% confidence
Finding
The README's security notes explicitly instruct operators not to log signatures/public keys, yet the provided bot handler example logs receipt of a signature event with the user's wallet address at L200. While the logged field is the address rather than the raw signature/public key, this still contradicts the nearby guidance's intent to minimize sensitive verification data in logs.

Known Vulnerable Dependency: @stablelib/ed25519==1.0.3 — 1 advisory(ies): GHSA-x3ff-w252-2g7j (StableLib Ed25519 Signature Malleability via Missing S < L Check)

Low
Category
Supply Chain
Confidence
91% confidence
Finding
The lockfile includes @stablelib/ed25519 1.0.3, which is affected by a signature malleability issue due to missing validation of the S < L constraint. In a wallet-verification skill, signature verification correctness is security-relevant because malformed but accepted signatures can weaken trust in proof-of-ownership flows, even if exploitation is narrower than remote code execution.

Static analysis

No suspicious patterns detected.