SushiSwap SDK

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:50 AM UTC
• Version: 0.1.0

Overview

The skill is a coherent SushiSwap SDK guide, but it gives under-scoped guidance for signing mainnet swap transactions that can move real funds.

Review this skill carefully before installing. It is not showing hidden system behavior, but its examples can lead an agent or developer to sign and broadcast real SushiSwap transactions from a private key. Only use it with explicit user approval, decoded transaction review, chain/router/spender/amount/slippage checks, simulation that verifies asset changes, pinned dependencies, and preferably a low-balance or test wallet.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• 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

Findings (2)

T09 · Insecure Skill Coding Practices

Error

• Location: references/REFERENCE.md:34

Finding

Blind Signing of Remotely Generated Swap Transactions

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:47; references/REFERENCE.md:34-35, 42-79
Vulnerability Type: Insufficient validation of untrusted transaction data
Risk Level: High

The documentation instructs integrators to use transaction data returned by the SushiSwap API exactly as provided:

text

Use returned transaction data exactly as provided for simulation or execution

The reference implementation obtains transaction fields from the remote API and passes them directly to the wallet:

ts

const data = await getSwap({
  chainId: EvmChainId.ETHEREUM,
  tokenIn: '0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE',
  tokenOut: '0x6B3595068778DD592e39A122f4f5a5cF09C90fE2',
  sender: '0xYourAddressHere',
  amount: 1000000000000000000n,
  maxSlippage: 0.005,
})

if (data.status === 'Success') {
  const { tx } = data

  const callResult = await publicClient.call({
    account: tx.from,
    data: tx.data,
    to: tx.to,
    value: tx.value,
  })

  console.log('Simulated output:', callResult)

  const PRIVATE_KEY = process.env.PRIVATE_KEY as Hex
  const walletClient = createWalletClient({
    chain: mainnet,
    transport: http(),
  })

  const hash = await walletClient.sendTransaction({
    account: privateKeyToAccount(PRIVATE_KEY),
    data: tx.data,
    to: tx.to,
    value: tx.value,
  })
}

Technical Analysis

The transaction destination, calldata, and native-token value are controlled by a response from an external API. The example does not independently verify:

• That tx.to is an approved SushiSwap router for the selected chain.
• That decoded calldata performs the requested swap.
• That input and output tokens match the user's request.
• That the input amount and minimum output are within approved limits.
• That the transaction recipient is the intended account.
• That token approvals are limited to the required amount and spender.

...[truncated 1730 chars]

Remediation

View remediation

Remediation Suggestions

• Treat every API-generated transaction as untrusted input.
• Maintain an authenticated allowlist of expected router addresses for each supported chain and reject any other tx.to value.
• Decode tx.data using the expected router ABI and verify the function selector and all relevant arguments.
• Confirm the chain ID, sender, recipient, input token, output token, input amount, minimum output, deadline, slippage, and native-token value against the user's approved request.
• Validate that approvals use the intended spender and are limited to the minimum necessary amount and duration.
• Compare simulated asset and allowance changes against explicit invariants rather than relying only on successful execution.
• Display the decoded operation and expected asset changes to the user and require explicit confirmation before signing.
• Reject malformed, unexpected, or undecodable calldata.
• Use a wallet or policy engine capable of transaction simulation, human-readable decoding, contract allowlisting, and spending limits.
• Replace the instruction to use returned data “exactly as provided” with guidance requiring independent validation before execution.

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:26

Finding

Unpinned Third-Party Package Installation

Content

View full analysis

Vulnerability Details

File Location: SKILL.md:26-40
Vulnerability Type: Unpinned supply-chain dependencies
Risk Level: Medium

The installation instructions install the sushi and viem packages without exact versions or integrity constraints:

bash

pnpm add sushi viem

bash

npm add sushi viem

bash

yarn add sushi viem

bash

bun add sushi viem

Technical Analysis

These commands resolve mutable package versions from the configured package registry. The installed code can therefore vary depending on installation time, package-manager resolution rules, registry configuration, and newly published releases.

Because both packages participate in constructing or signing blockchain transactions, a compromised or unexpectedly changed release could alter transaction destinations or calldata, access process secrets, or execute package lifecycle scripts during installation. The reviewed project does not provide a lockfile, exact version requirements, package integrity hashes, or documented verification controls.

Attack Path

1. An attacker compromises a package maintainer, package registry account, publishing token, registry mirror, or dependency in the resolved package tree.
2. The attacker publishes a malicious release that remains compatible with the unpinned installation command.
3. A user follows the documented command after the malicious version becomes available.
4. The package manager resolves and installs the compromised release.
5. Malicious code executes through an installation lifecycle script or when the package is imported and used.
6. The malicious component can access data available to the application process or manipulate quote, transaction-generation, or signing behavior.

Impact Assessment

The potential scope is the privilege level of the user or build process running the package manager and the runtime application. Depending on the compro ...[truncated 428 chars]

Remediation

View remediation

Remediation Suggestions

• Specify reviewed, exact package versions rather than relying on mutable resolution.
• Commit and enforce a package-manager lockfile in consuming projects.
• Use deterministic or frozen-lockfile installation modes in CI and production.
• Verify registry provenance and package integrity metadata.
• Review transitive dependencies and package lifecycle scripts before upgrades.
• Disable installation scripts where practical, enabling only explicitly reviewed exceptions.
• Use automated dependency monitoring, but require security review and testing before accepting updates.
• Isolate dependency installation and builds from wallet keys, production credentials, and other sensitive environment variables.
• Consider generating and verifying a software bill of materials for release artifacts.

SkillSpector

Vulnerability Patterns

• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• 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 (3)

Missing User Warnings

Medium

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

Finding

The skill documents how to generate swap transaction data and explicitly instructs users to use returned transaction data exactly as provided, but it does not warn that getSwap() can produce executable calldata that may directly move user funds if signed. In a wallet or agent context, this omission increases the risk that integrators treat swap generation as a harmless quote operation and present or execute transactions without adequate review, simulation, or user consent.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

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

Finding

The documentation walks users through generating calldata and broadcasting an on-chain swap transaction with a private key, but it omits prominent warnings that this can spend real assets irreversibly and that API-provided transaction fields should be carefully validated. In SDK documentation, especially for financial transactions, lack of risk framing increases the chance that users will run the example against mainnet with real funds and insufficient review.

Content

No source excerpt is available for this finding.

Context-Inappropriate Capability

Medium

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

Finding

The manifest describes this skill as a typed SDK wrapper that requests quotes and swap transaction generation from the SushiSwap API. In this reference, the example additionally reads a private key from process.env and uses a wallet client to broadcast a transaction, which is a wallet-operation capability not justified as part of the SDK itself and goes beyond merely generating swap transaction data.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.