Megaeth Developer

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:33 AM UTC
• Version: 0.1.0

Overview

This is a coherent MegaETH developer guide, but it gives high-impact mainnet wallet, swap, approval, bridge, and deployment instructions with several unsafe or inconsistent examples that could cause real fund loss if copied.

Review this skill carefully before installing. Use it only with explicit human confirmation for every approval, swap, bridge, transfer, signed transaction, and deployment; prefer testnet first; verify chain ID, RPC endpoint, contract/token addresses, spender/router addresses, amounts, slippage, calldata, and simulation results from authoritative sources; and pin any external repositories or dependencies before building or installing them.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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

Findings (6)

T08 · Insecure Dependencies

Warning

• Location: testing.md:9
• Finding: Unpinned External Repositories and Skills Create Supply-Chain Exposure<![CDATA[ ## Vulnerability Details **File Locations**: - `testing.md:9-12` - `resources.md:27-31` - `resources.md:41-44` - `smart-contracts.md:367-368` **Vulnerability Type**: Unpinned external dependencies and third-party Skill installation **Risk Level**: Medium ### Vulnerable Code ```bash git clone https://github.com/megaeth-labs/mega-evm cd mega-evm/bin/mega-evme cargo build --release ``` ```markdown - **Skill**: https://clawdhub.ai/planetai87/warren-deploy - **Website**: https://megawarren.xyz - **Install**: `clawdhub install warren-deploy` ``` ```bash forge install vectorized/solady ``` ### Technical Analysis These instructions retrieve mutable upstream content without pinning an audited commit, immutable release, package version, or checksum. The Cargo build can also process transitive dependencies and build scripts. The external Warren Deploy Skill is maintained separately and may introduce additional instructions or executable behavior outside this audited project. The profiler URL in `testing.md:42` and `resources.md:49` is only a source reference and does not itself download or execute the script. The confirmed concern is the unpinned repository cloning, compilation, dependency installation, and third-party Skill installation. This is a supply-chain weakness rather than evidence that the current upstream projects are malicious. ### Attack Path 1. An attacker compromises an upstream repository, dependency, release process, or publisher account. 2. The attacker modifies the default branch, package content, or published Skill. 3. A user follows the unpinned installation instructions. 4. The changed source, build logic, dependency, or Skill is downloaded. 5. During compilation, installation, or later invocation, attacker-controlled behavior executes with the user's local permissions. ### Impact Assessment A successful upstream compromise could obtain the same local privileges as the user performing the installation or build. Depending on the ma ...[truncated 215 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin repositories to reviewed commit hashes or signed immutable release tags. - Use a command such as `git checkout <reviewed-commit>` before compilation. - Install Solady using an explicit reviewed commit, for example `forge install vectorized/solady@<commit>`. - Commit and verify dependency lockfiles where supported. - Verify release signatures or published checksums before building binaries. - Review Cargo build scripts and transitive dependencies before compilation. - Audit external Skills independently before installation and pin a specific reviewed release when the platform supports it. - Document that external installation must not occur automatically or without user approval. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: wallet-operations.md:216
• Finding: Remote Aggregator Response Is Submitted as a Wallet Transaction Without Validation<![CDATA[ ## Vulnerability Details **File Location**: `wallet-operations.md:216-236` **Vulnerability Type**: Blind signing of remotely generated transaction data **Risk Level**: High ### Vulnerable Code ```typescript const buildRes = await fetch(`${KYBER_API}/route/build`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ routeSummary: quote.data.routeSummary, sender: walletAddress, recipient: walletAddress, slippageTolerance: 50 // 0.5% = 50 bips }) }); const { data } = await buildRes.json(); // Execute swap const hash = await walletClient.sendTransaction({ to: data.routerAddress, data: data.data, value: data.value, gas: BigInt(data.gas) }); ``` ### Technical Analysis The example trusts `routerAddress`, calldata, native value, and gas returned by the remote Kyber build endpoint and submits them directly to the wallet. It does not independently verify: - The active chain ID. - Whether the router is an approved chain-specific contract. - The calldata function selector and decoded arguments. - Input and output token addresses. - Input amount and minimum output. - Recipient and refund addresses. - Native currency value. - Quote deadline or freshness. - Allowance target. - Simulated state changes. TLS protects transport in normal circumstances but does not protect against a compromised API, provider account, server-side defect, or malicious response generated by an otherwise reachable endpoint. ### Attack Path 1. An attacker compromises the aggregator service, its infrastructure, or a relevant integration path. 2. The build endpoint returns an attacker-selected router address and calldata. 3. The application accepts the response without decoding or validating it. 4. The wallet presents or signs the opaque transaction. 5. The transaction transfers native currency, invokes a malicious contract, or grants token authority. 6. The attacker receives assets or obtains permissions that can be e ...[truncated 441 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Verify the wallet's chain ID before requesting or submitting a route. - Maintain an authoritative allowlist of router addresses for each chain. - Decode the returned calldata and verify the function selector and every security-sensitive argument. - Bind the transaction to the requested input token, output token, amount, recipient, slippage, and deadline. - Reject unexpected native value, approval targets, callback addresses, and arbitrary-call payloads. - Independently simulate the exact transaction and inspect asset and allowance changes. - Display decoded transaction effects to the user and require explicit confirmation. - Validate HTTP status codes and response schemas before processing the response. - Re-fetch or reject stale quotes rather than submitting expired transaction data. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: wallet-operations.md:187
• Finding: Unlimited ERC-20 Approval Grants Excessive Long-Term Authority<![CDATA[ ## Vulnerability Details **File Location**: `wallet-operations.md:187-194` **Vulnerability Type**: Excessive token allowance **Risk Level**: High ### Vulnerable Code ```typescript const hash = await walletClient.writeContract({ address: tokenAddress, abi: erc20Abi, functionName: 'approve', args: [spenderAddress, maxUint256] }); ``` ### Technical Analysis The example grants the spender the maximum possible ERC-20 allowance. It does not verify the spender, restrict the allowance to the required amount, provide an expiration mechanism, or instruct the user to revoke the allowance after use. An unlimited allowance persists independently of the current wallet balance. Consequently, tokens received after the approval can also become accessible to the spender. The approval exceeds the minimum authority needed for a single transfer or swap. ### Attack Path 1. A user follows the example and approves `maxUint256` for a spender. 2. The spender is malicious, is incorrectly configured, or is compromised later. 3. The spender invokes `transferFrom` against the user's token balance. 4. Because the allowance is effectively unlimited, the spender transfers the available balance. 5. The same approval may be reused against tokens subsequently deposited into the wallet until revoked. ### Impact Assessment The spender can transfer up to the wallet's available balance of the approved ERC-20 token, subject to the remaining allowance. The impact is limited to the approved token contract but can persist indefinitely and affect future balances. ]]>
• Remediation: <![CDATA[ ## Remediation Suggestions - Approve only the exact amount required for the immediate operation. - Verify the spender against a chain-specific authoritative allowlist. - Display the token, spender, amount, and chain before requesting approval. - Revoke residual allowance after the operation where practical. - Prefer bounded permit mechanisms with explicit amounts, nonces, and deadlines when supported. - For tokens requiring allowance reset, set the allowance to zero before assigning a new nonzero value. - Clearly label unlimited approvals as exceptional high-risk behavior rather than a default pattern. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: smart-contracts.md:327
• Finding: Example Multi-Token Contract Allows Unrestricted Public Minting<![CDATA[ ## Vulnerability Details **File Location**: `smart-contracts.md:327-344` **Vulnerability Type**: Missing authorization on privileged mint operation **Risk Level**: Critical ### Vulnerable Code ```solidity // Using Solady's ERC6909 (gas-optimized) import {ERC6909} from "solady/src/tokens/ERC6909.sol"; contract MultiToken is ERC6909 { function name(uint256 id) public view override returns (string memory) { // Return name for token ID } function symbol(uint256 id) public view override returns (string memory) { // Return symbol for token ID } function tokenURI(uint256 id) public view override returns (string memory) { // Return metadata URI for token ID } function mint(address to, uint256 id, uint256 amount) external { _mint(to, id, amount); } } ``` ### Technical Analysis The externally callable `mint` function has no owner, role, signature, allowlist, supply-cap, or other authorization check. Any address can mint any token ID in any amount to any recipient. Although this is presented as a basic example, it is not marked as intentionally insecure or incomplete. A developer copying it into a deployable implementation would expose an unrestricted privileged operation. ### Attack Path 1. A developer adopts or deploys the example without adding authorization. 2. An attacker identifies the public `mint` function. 3. The attacker calls `mint(attacker, id, amount)` with an arbitrary amount. 4. The contract credits the attacker with newly created tokens. 5. The attacker sells, transfers, redeems, votes with, or otherwise uses the unauthorized supply in connected systems. ### Impact Assessment An attacker can create unlimited supply for every token ID supported by the contract. This destroys supply integrity and may enable theft from liquidity pools, unauthorized redemption, governance manipulation, accounting corruption, or economic insolvency in systems that trust these balances. The att ...[truncated 102 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Restrict `mint` with an owner or role-based access-control modifier. - Use a dedicated minter role that follows least privilege. - Add per-token and global supply caps where the token model permits them. - If minting is signature-authorized, bind signatures to the chain, contract, recipient, token ID, amount, nonce, and deadline. - Add tests proving unauthorized callers cannot mint. - Emit appropriate minting and role-administration events. - Protect privileged role transfers with multisignature or delayed administration for production deployments. - Mark simplified documentation examples as non-production code and explicitly show the required authorization check. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: smart-contracts.md:103
• Finding: Deployment Guidance Broadcasts Transactions While Skipping Simulation<![CDATA[ ## Vulnerability Details **File Locations**: - `smart-contracts.md:103-118` - `resources.md:198-200` **Vulnerability Type**: Unsafe transaction deployment workflow **Risk Level**: Medium ### Vulnerable Code ```markdown ## Gas Estimation Always use remote estimation: ```solidity // foundry.toml [profile.default] # Don't rely on local simulation ``` ```bash # Deploy with explicit gas, skip simulation forge script Deploy.s.sol \ --rpc-url https://mainnet.megaeth.com/rpc \ --gas-limit 5000000 \ --skip-simulation \ --broadcast ``` ``` The same unsafe combination is repeated in `resources.md`: ```bash forge script Deploy.s.sol --rpc-url https://mainnet.megaeth.com/rpc --broadcast --skip-simulation ``` ### Technical Analysis The guidance explicitly combines `--skip-simulation` with `--broadcast`. Remote gas estimation can identify some gas-related failures, but it does not replace review of the complete deployment script's semantic effects, addresses, values, ownership assignments, approvals, and post-deployment calls. This also conflicts with `security.md:116`, which states that transactions should always be simulated before signing. The differing MegaEVM gas schedule may justify avoiding an incompatible local gas model, but it does not justify broadcasting without a compatible remote simulation or equivalent dry run. ### Attack Path 1. A deployment script contains an incorrect address, value, constructor argument, permission assignment, or unintended call. 2. Alternatively, a dependency or script is modified before deployment. 3. The user follows the documented command with simulation disabled. 4. Foundry broadcasts the transaction sequence to mainnet. 5. The incorrect deployment or transfer becomes irreversible before its effects are reviewed. ### Impact Assessment The scope is the authority and assets of the deployment signer. Potential consequences include loss of deployment funds, transfer of native currency or tokens, deplo ...[truncated 249 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not present `--skip-simulation --broadcast` as the default deployment workflow. - Use a MegaEVM-compatible remote fork or supported remote simulation before broadcasting. - Separate simulation and broadcast into distinct commands and require review between them. - Inspect traces, state changes, deployed addresses, values, and role assignments. - Verify the chain ID and RPC endpoint before signing. - Require explicit user confirmation for mainnet broadcasts. - Pin and review deployment dependencies before simulation. - Reconcile the deployment documentation with the “always simulate before signing” requirement in `security.md`. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: wallet-operations.md:160
• Finding: Conflicting MEGA Token Addresses Can Redirect Asset Operations<![CDATA[ ## Vulnerability Details **File Locations**: - `wallet-operations.md:160-166` - `resources.md:158-163` **Vulnerability Type**: Inconsistent security-sensitive contract configuration **Risk Level**: High ### Vulnerable Code `wallet-operations.md` identifies the MEGA token as: ```markdown | Token | Address | |-------|---------| | WETH | `0x4200000000000000000000000000000000000006` | | MEGA | `0x28B7E77f82B25B95953825F1E3eA0E36c1c29861` | | USDM | `0xFAfDdbb3FC7688494971a79cc65DCa3EF82079E7` | ``` `resources.md` identifies the same token differently: ```markdown | Contract | Address | |----------|---------| | WETH9 | `0x4200000000000000000000000000000000000006` | | Multicall3 | `0xcA11bde05977b3631167028862bE2a173976CA11` | | High-Precision Timestamp | `0x6342000000000000000000000000000000000002` | | MEGA Token | `0x28B7E77f82B25B95953825F1E2eA0E36c1c29861` | ``` The two addresses differ at one character: ```text 0x28B7E77f82B25B95953825F1E3eA0E36c1c29861 0x28B7E77f82B25B95953825F1E2eA0E36c1c29861 ``` ### Technical Analysis Contract addresses are security-sensitive identifiers. Supplying two different addresses for the same token prevents users from reliably determining which contract is authoritative. Address similarity makes the discrepancy difficult to notice during manual review. The audit establishes the inconsistency but does not independently determine which address is canonical. Therefore, neither value should be trusted until verified against an authoritative, chain-specific source. ### Attack Path 1. A user copies one of the conflicting addresses from the Skill. 2. The application treats that address as the MEGA token contract. 3. The user transfers tokens, requests approval, builds a swap, or queries balances against the unintended contract. 4. If the unintended address contains a malicious or unrelated contract, it can receive assets or token authority. 5. Blockchain transactions are irreversible after confirmation. ### Impact Asse ...[truncated 358 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not use either conflicting value until the canonical address is independently verified. - Use one pinned, authoritative, chain-specific token registry as the source of truth. - Generate documentation from the registry instead of duplicating addresses manually. - Validate the active chain ID before resolving any token address. - Verify deployed bytecode, token metadata, and authoritative explorer or project records. - Add automated tests that detect inconsistent duplicate addresses across documentation. - Display checksum-formatted addresses and require confirmation for high-value operations. ]]>

SkillSpector

Vulnerability Patterns

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

Findings (12)

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The skill covers wallet management, transaction submission, swaps, and bridging, but it does not include prominent warnings that these actions are irreversible and can directly move or lose funds. In this context, omission of user-safety messaging increases the risk that an agent will proceed with high-impact on-chain actions without confirmation, network verification, slippage review, or destination-address checks.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The gas guidance is internally contradictory: it tells users to 'skip estimation when possible' and to 'always use remote eth_estimateGas'. In a skill that guides real transaction submission, this ambiguity can cause an agent or developer to choose unsafe defaults, leading to failed transactions, underprovisioned gas, or unintended fund loss through repeated retries and bad transaction handling.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The quick-reference section includes ready-to-run commands that interact with the live mainnet RPC, including sending value and broadcasting deployments, without any warning that these actions can create irreversible real transactions and spend funds. In a developer skill focused on wallet operations and deployment, users may copy-paste commands directly, which increases the chance of accidental mainnet execution, especially with flags like --broadcast and --skip-simulation.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The examples show how to submit signed transactions directly to a mainnet RPC endpoint without an explicit warning that doing so will broadcast a live transaction. In a developer skill focused on wallet operations and transaction handling, this omission increases the chance of accidental on-chain submission, fund movement, or unintended contract interaction by users copying examples verbatim.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Both work identically:
curl -X POST https://mainnet.megaeth.com/rpc \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",

• Confidence: 86% confidence
• Finding: This snippet demonstrates sending a signed raw transaction to an external mainnet endpoint, which is inherently a state-changing, irreversible action once used with a real signed payload. While expected in blockchain documentation, presenting it without strong safety framing can cause accidental transmission of valid signed transactions to production infrastructure.

Intent-Code Divergence

Medium

• Confidence: 96% confidence
• Finding: This section mixes MegaETH/EVM guidance with concepts and APIs that appear inconsistent with the rest of the document, such as Solana-style blockhash handling and transaction retry semantics. In a developer security guide, inaccurate chain-specific advice can cause operators to implement the wrong safety controls, miss real failure modes, or trust invalid assumptions during transaction submission and incident response.

Intent-Code Divergence

Medium

• Confidence: 98% confidence
• Finding: The audit recommendation to 'Verify CPI targets' is inconsistent with the EVM/MegaETH context, where CPI is not standard terminology and suggests copy-pasted guidance from another ecosystem. In a security playbook, this kind of cross-chain confusion can mislead developers and auditors into checking the wrong interaction model, leaving actual external-call risks insufficiently reviewed.

External Transmission

Medium

• Category: Data Exfiltration

Content

```bash
# Detailed timing breakdown
curl -i -X POST https://mainnet.megaeth.com/rpc \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  -w "dns: %{time_namelookup} | connect: %{time_connect} | total: %{time_total}\n"

• Confidence: 60% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

```bash
# Generate wallet (one-time)
node src/setup.js --json
# Stores key at ~/.evm-wallet.json (chmod 600)
```

## Check Balance

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The example uses `approve(spenderAddress, maxUint256)`, which grants an unlimited ERC-20 allowance. If the spender contract is compromised, upgraded maliciously, or the address is incorrect, the wallet's entire token balance can be drained without further user approval. In a wallet-operations skill, omitting an inline warning makes this more dangerous because readers may copy the pattern directly into production flows.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

## Security Notes

1. **Never expose private keys** — store at `~/.evm-wallet.json` with chmod 600
2. **Confirm before sending** — always show recipient, amount, gas before execution
3. **Use hardware wallets** for large amounts
4. **Verify contract addresses** — check explorer before interacting

• Confidence: 80% confidence
• Finding: Commands invoke sudo or root privileges. Verify this elevated access is necessary and justified.

Missing User Warnings

Low

• Confidence: 85% confidence
• Finding: This markdown instructs implementers to call `eth_chainId` or `eth_blockNumber` during app initialization, wallet connection, or network switch. That is user-affecting network behavior, but the documentation presents it purely as a performance optimization and does not disclose that it triggers outbound requests before the user explicitly performs a transaction.

Static analysis

No suspicious patterns detected.