Element NFT Trader

• Outcome: Review
• Latest audit: May 29, 2026, 9:30 PM
• Version:
  1.0.5

Overview

This looks like a real Element NFT trading skill, but it can automatically grant broad token approvals from a private-key wallet, so it needs careful review before use.

Install only with a dedicated low-value wallet. Before any sell, offer, buy, or accept-offer flow, check whether the skill will submit an approval transaction, what token or collection is being approved, the approved spender/operator address, and whether the approval is unlimited or collection-wide. Revoke approvals after use if they are no longer needed.

SkillSpector

By NVIDIA

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (27)

Description-Behavior Mismatch

High

• Confidence: 98% confidence
• Finding: This ABI for a user-facing NFT trading skill exposes owner and upgrade-style administrative methods such as extend, registerMethods, rollback, migrate, transferOwnership, and owner. Even though an ABI alone does not execute anything, including these capabilities in a skill materially broadens what an agent could be induced to call, enabling proxy reconfiguration, ownership changes, or migration operations that are far outside the declared trading purpose.

Description-Behavior Mismatch

Medium

• Confidence: 90% confidence
• Finding: The ABI includes broad transfer primitives such as transferERC721s, transferERC721sEx, transferItems, and transferItemsEx that are not necessary for a narrowly scoped Element order-trading skill. In an agent setting, these generic transfer methods increase the risk of direct asset movement unrelated to the user's intended marketplace action, which could enable wallet draining or unauthorized transfers if approvals exist.

Context-Inappropriate Capability

High

• Confidence: 97% confidence
• Finding: Administrative proxy and ownership controls are unjustified in the context of a skill described as buying, selling, querying, and cancelling NFT orders. The skill context makes this more dangerous, not less, because users would reasonably expect limited marketplace interactions; exposing admin selectors creates a severe scope mismatch that could let an agent perform privileged contract management actions if connected to a capable signer.

Description-Behavior Mismatch

Medium

• Confidence: 95% confidence
• Finding: The SDK exposes direct `transferERC721` and `transferERC1155` methods that move NFTs independently of Element order creation/fill flows described in the skill metadata. In an agent setting, this expands authority from marketplace trading into arbitrary asset transfer, which could enable exfiltration of user NFTs if the skill is invoked or composed incorrectly.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: Direct asset transfer capability is not justified by the stated purpose of buying, selling, bidding, querying, and cancelling Element marketplace orders. Because these methods send blockchain transactions that irreversibly transfer NFTs to arbitrary addresses, they materially increase the blast radius of the skill beyond its declared trading scope.

Description-Behavior Mismatch

Medium

• Confidence: 92% confidence
• Finding: This utility exposes direct ERC-721 and ERC-1155 transfer primitives that can move user assets to arbitrary addresses, which exceeds the declared Element marketplace scope of trading and order management. In an agent skill context, broad transfer capability is especially risky because a compromised prompt flow, bad parameter routing, or misuse by higher-level code could turn a marketplace action into a generic asset exfiltration operation.

Context-Inappropriate Capability

Medium

• Confidence: 91% confidence
• Finding: The code implements a general NFT transfer capability unrelated to the stated purpose of querying orders, placing/canceling offers, and marketplace trading on Element. Scope mismatch matters here because users and integrators may trust the skill for marketplace actions, while the presence of arbitrary transfer functions increases the blast radius to full wallet asset movement.

Description-Behavior Mismatch

Medium

• Confidence: 90% confidence
• Finding: The ABI includes helper methods for non-Element marketplaces and naming services, materially expanding the callable surface beyond the skill's declared Element NFT trading purpose. In an agent setting, this scope mismatch can enable unintended data access, policy bypass, or future misuse if higher-level routing trusts the manifest description more than the actual exposed interface.

Context-Inappropriate Capability

Medium

• Confidence: 94% confidence
• Finding: ENS and SpaceId query functions are unrelated to the stated Element NFT trading workflow and introduce unnecessary capability for identity and domain-resolution lookups. In a tool-using agent, unnecessary auxiliary functions increase the chance of overreach, privacy leakage, or prompt-driven misuse because the model may invoke whatever is available, not just what was intended.

Context-Inappropriate Capability

Medium

• Confidence: 93% confidence
• Finding: LooksRare, Seaport, and X2Y2 inspection helpers are outside the documented Element-only scope, creating a capability mismatch between advertised behavior and actual available functionality. Even though these methods are view-only, they still broaden the agent's operational and data-retrieval surface and may let prompts steer the skill into unsupported third-party marketplace interactions.

Description-Behavior Mismatch

High

• Confidence: 95% confidence
• Finding: This ABI exposes owner/admin and upgrade-style methods such as extend, registerMethods, rollback, migrate, transferOwnership, and owner, which are far outside the stated NFT trading/order-management scope of the skill. In an agent skill that may construct transactions from ABI definitions, including these selectors expands the attack surface to privileged contract operations and could enable catastrophic misuse if routing, prompting, or policy checks fail.

Description-Behavior Mismatch

Medium

• Confidence: 88% confidence
• Finding: The ABI includes generic transfer functions like transferERC721s, transferERC721sEx, transferItems, and transferItemsEx, which permit moving assets outside the narrow buy/sell/cancel workflow described for the skill. In an agentic trading context, these functions can be abused to request broad token transfers that look adjacent to legitimate trading activity, increasing the risk of unauthorized asset movement.

Context-Inappropriate Capability

High

• Confidence: 96% confidence
• Finding: Upgrade and migration capabilities are especially dangerous in this skill context because the skill is supposed to trade NFTs on Element, not administer marketplace infrastructure. Exposing migration and proxy-management functions in a user-facing trading skill creates a severe mismatch between declared purpose and executable capability, making prompt-injection, misconfiguration, or approval bypass far more damaging.

Description-Behavior Mismatch

Medium

• Confidence: 96% confidence
• Finding: The SDK exposes `transferERC721` and `transferERC1155`, which can move user NFTs directly to an arbitrary address without going through Element order creation, fulfillment, or cancellation flows. That capability exceeds the declared trading/order-management scope and materially increases the blast radius: an agent using this skill could transfer assets outright rather than only listing, buying, or cancelling orders.

Context-Inappropriate Capability

Medium

• Confidence: 95% confidence
• Finding: Direct ERC721/ERC1155 transfer functionality is not justified by the skill description, which is limited to Element marketplace trading and order management. In an agent setting, this mismatch is dangerous because users may authorize a trading skill expecting listings or fills, while the implementation also contains a primitive that can irreversibly send NFTs away from the wallet.

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The guidance notes internally that the SDK may perform an NFT approval before the final trade, but it does not explicitly instruct the agent to warn the user that accepting an offer can trigger one or more separate on-chain approval transactions. In an NFT trading skill, this omission is security-relevant because users may unknowingly authorize marketplace/operator access or incur gas costs before the sale executes, increasing the chance of unintended approvals or confusion-driven consent.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The code automatically submits an ERC721 approval transaction to grant the Element exchange operator access to the user's NFTs when approval is missing, but it provides only console logging and no explicit user-facing warning about the scope of that authorization. In an NFT trading skill, operator approval is highly sensitive because it can enable transfer of all tokens from that collection by the approved contract, so users may unknowingly grant broad permissions beyond a single sale.

Missing User Warnings

Medium

• Confidence: 89% confidence
• Finding: The transfer methods submit asset-moving on-chain transactions without any visible user-warning, confirmation, or disclosure in this file. In a wallet-connected agent workflow, lack of explicit disclosure can cause users to approve what they believe is a trade-related operation when it is actually an unconditional NFT transfer.

Missing User Warnings

High

• Confidence: 95% confidence
• Finding: The approval helpers can grant powerful token permissions, including ERC20 approval defaulting to MaxInt256 and ERC721/ERC1155 setApprovalForAll, which enables broad asset access by the specified spender/operator. In an NFT trading skill, these helpers are especially sensitive because a compromised, malicious, or misconfigured operator address could obtain ongoing transfer authority over user assets beyond a single trade.

Missing User Warnings

Medium

• Confidence: 84% confidence
• Finding: approveERC20 can submit an approval transaction with no user-facing disclosure in this code, despite approvals granting a third-party contract spending power over tokens. In trading contexts approvals may be expected, but silent or poorly surfaced approvals are dangerous because users may not realize they are authorizing future token movement beyond a single immediate action.

Missing User Warnings

High

• Confidence: 95% confidence
• Finding: setApproveForAll can grant the Element exchange contract operator control over all of the user's NFTs from a collection, and this occurs without any warning or disclosure in the shown code. Operator approval is particularly sensitive because it is broad, persistent, and can enable later transfer of all eligible assets if the approved operator is misused, compromised, or incorrectly configured.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The code constructs and submits batch order-cancellation transactions directly via `ethSend` with no explicit confirmation hook, policy gate, or user-facing warning in this layer. In a trading skill context, cancelling orders is a destructive state-changing action that can invalidate live listings or bids unexpectedly if invoked by an agent or upstream automation.

Missing User Warnings

High

• Confidence: 98% confidence
• Finding: `cancelAllOrders` sends `incrementHashNonce()` directly, which globally invalidates all existing orders for the account. Because this is a high-impact destructive action and this code path contains no explicit confirmation or safety interlock, an agent misuse, prompt injection upstream, or accidental invocation could wipe all outstanding marketplace orders at once.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: When approval checks fail, the code automatically submits ERC721/ERC1155 approval transactions and only emits console logs, which are not meaningful user consent controls. NFT approvals can grant the marketplace contract transfer rights over assets, so automatic approval in an agent-driven trading skill increases the risk of unintended asset exposure or surprise wallet operations.

Missing User Warnings

Medium

• Confidence: 96% confidence
• Finding: The buy-order path automatically calls `approveERC20Proxy` when allowance is insufficient, again without a user-facing warning or explicit consent mechanism in this code. ERC20 approvals can expose significant token balances to spender risk, and in an automated skill handling trades this behavior is more dangerous because users may not realize a second state-changing transaction is being broadcast.

VirusTotal

66/66 vendors flagged this skill as clean.