NexusWeb3 Safety & Compliance

• Outcome: Review
• Latest audit: Sep 12, 2026 · 4:20 AM UTC
• Version: 1.0.3

Overview

The skill is documentation-only, but it is labeled read-only while giving detailed instructions for on-chain actions that can move funds, change permissions, and create persistent token approvals.

Review this as a transaction-capable blockchain reference, not a purely read-only skill. Do not let an agent follow the write examples without explicit user confirmation, verified contract addresses, exact bounded approval amounts, and a clear understanding of irreversible or persistent on-chain effects. Avoid unlimited USDC approvals unless you intentionally accept that ongoing allowance risk.

A.I.G

Vulnerability Patterns

• 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
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:429

Finding

Unsafe Recommendation for Unlimited USDC Token Approval

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:429
Vulnerability Type: Excessive ERC-20 token allowance
Risk Level: Medium

Vulnerable Code Snippet:

text

**"ERC20InsufficientAllowance"** — Call `USDC.approve(protocolAddress, amount)` before any USDC-denominated transaction. Use `type(uint256).max` for unlimited approval if preferred.

Technical Analysis

The skill recommends using type(uint256).max when approving a protocol contract to spend USDC. This creates an effectively unlimited and persistent ERC-20 allowance rather than limiting the spender to the amount required for the current operation.

ERC-20 allowances authorize the approved spender to invoke transferFrom without additional approval from the token holder. An unlimited allowance generally remains active until explicitly revoked. It can therefore expose both the wallet's current USDC balance and USDC deposited into the wallet later.

The risk becomes exploitable if the approved protocol address is incorrect, malicious, compromised, upgradeable to malicious logic, or contains a vulnerability permitting unauthorized token transfers. The project contains no executable transaction logic itself, but agents or users following this instruction could create the unsafe authorization on Base Mainnet.

Attack Path

1. A user or agent attempts a USDC-denominated protocol transaction and receives an allowance error.
2. Following the documented guidance, it calls USDC.approve(protocolAddress, type(uint256).max).
3. The protocol address receives a persistent allowance covering the wallet's entire current and future USDC balance.
4. The spender contract is compromised, behaves maliciously, is replaced through an upgrade mechanism, or exposes a function that can misuse its transfer authority.
5. The spender invokes USDC.transferFrom(wallet, attacker, amount) for up to the wallet's available balance.
6. The attacker can repeat the transfer ...[truncated 593 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove the recommendation to use type(uint256).max.
2. Recommend approving only the exact amount required for each operation:

   solidity

   USDC.approve(protocolAddress, requiredAmount);
   

3. Require verification of the Base Mainnet chain ID and exact spender address before requesting approval.
4. Advise users to reset any residual allowance to zero after the operation completes.
5. Explain explicitly that ERC-20 approval authorizes the spender to withdraw tokens through transferFrom; it is not merely a transaction prerequisite.
6. Where supported, use single-transaction authorization mechanisms such as permit-based approvals with bounded amounts, deadlines, and nonces.
7. Require explicit user confirmation before creating any token allowance, especially when the requested amount exceeds the immediate transaction requirement.
8. Add a warning that contract compromise, upgradeability, address substitution, or application defects can turn an excessive allowance into direct token loss.

SkillSpector

Vulnerability Patterns

• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Description-Behavior Mismatch

High

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

Finding

The skill is marketed as a read-only API reference, but the body contains extensive state-changing instructions such as registering agents, posting bounties, creating subscriptions, transferring royalties, and declaring insolvency. This mismatch can mislead users or downstream agents into treating the skill as safe for passive inspection when it actually facilitates fund-moving and permission-changing transactions, increasing the chance of unauthorized or risky on-chain actions.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

High

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

Finding

The document explicitly says write operations belong in another skill, but then immediately provides detailed invocation examples for write functions in this file. That contradiction undermines trust boundaries and can cause an agent, user, or orchestrator to invoke dangerous state-changing methods under the false assumption that this skill is non-transactional, especially because many examples involve payments, approvals, ownership actions, and irreversible protocol changes.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.