Back to skill

Security audit

MegaETH AI Developer

Security checks for vulnerabilities and agentic risk

Overview

The skill is a coherent MegaETH developer guide, but it gives high-impact mainnet wallet, swap, approval, bridge, and deployment instructions with insufficient guardrails for irreversible financial actions.

Review this skill before installing and treat it as high-risk operational guidance. Do not let an agent automatically send, swap, approve, bridge, or deploy on mainnet from these examples. Pin installation sources, use testnet or small amounts first, avoid unlimited approvals, verify chain IDs, addresses, calldata, slippage, gas, and value, and require explicit confirmation before every funds-moving or contract-broadcast step.

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 (4)

T03 · Remote Payload Retrieval and Execution

Error
Location
README.md:20
Finding
Unpinned Remote Dependencies Are Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Locations**: - `README.md:20-28` - `README.md:33-34` - `resources.md:27-31` - `resources.md:40-49` - `testing.md:7-12` - `testing.md:36-42` - `smart-contracts.md:366-375` **Vulnerability Type**: Unpinned remote code retrieval and supply-chain exposure **Risk Level**: High ### Vulnerable Code `README.md:20-28`: ```bash npx skills add 0xBreadguy/megaeth-ai-developer-skills ``` ```bash git clone https://github.com/0xBreadguy/megaeth-ai-developer-skills # Copy to your agent's skills directory ``` `README.md:33-34`: ```bash clawdhub install megaeth-developer ``` `resources.md:27-31`: ```markdown - **Skill**: https://clawdhub.ai/planetai87/warren-deploy - **Website**: https://megawarren.xyz - **Install**: `clawdhub install warren-deploy` ``` `resources.md:40-49` and `testing.md:7-12,36-42`: ```bash git clone https://github.com/megaeth-labs/mega-evm cd mega-evm/bin/mega-evme cargo build --release ``` ```bash python scripts/trace_opcode_gas.py trace.json ``` ```markdown **Script:** https://github.com/megaeth-labs/mega-evm/blob/main/scripts/trace_opcode_gas.py ``` `smart-contracts.md:366-375`: ```bash forge install vectorized/solady ``` ```solidity import {ERC6909} from "solady/src/tokens/ERC6909.sol"; ``` ### Technical Analysis The documented installation workflows retrieve mutable content from package registries, Skill repositories, and GitHub branches without pinning an audited version or commit. They also provide no checksum, signature, lockfile, or provenance-verification procedure. The `git clone` and profiler URL alone do not automatically execute code. The risk becomes exploitable when the cloned Rust project is compiled, the Python profiler is run, or an installer such as `npx`, `clawdhub`, or Foundry processes the retrieved package. Build scripts, package lifecycle hooks, procedural macros, transitive dependencies, or Skill installation behavior may then execute under the invoking user's account. The G ...[truncated 1345 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Pin every Git repository to an audited full commit hash rather than the default branch. 2. Pin package and Skill versions; avoid unversioned `npx`, `clawdhub install`, and `forge install` commands. 3. Publish and verify SHA-256 checksums or signed release artifacts. 4. Use lockfiles and review all transitive dependency changes. 5. Prefer release archives from verified organization accounts over mutable source links. 6. Inspect package lifecycle scripts, Rust build scripts, procedural macros, and Skill manifests before execution. 7. Build untrusted tools in an isolated container or sandbox with: - No wallet files mounted - No SSH agent - No cloud or CI credentials - A read-only project mount where possible - Restricted network access 8. Document the exact audited revision of `trace_opcode_gas.py` and invoke that local pinned copy. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
wallet-operations.md:187
Finding
Unvalidated Aggregator Calldata Combined with Unlimited Token Approval<![CDATA[ ## Vulnerability Details **File Locations**: - `wallet-operations.md:187-194` - `wallet-operations.md:204-237` **Vulnerability Type**: Blind signing of third-party transaction data and excessive token allowance **Risk Level**: High ### Vulnerable Code `wallet-operations.md:187-194`: ```typescript const hash = await walletClient.writeContract({ address: tokenAddress, abi: erc20Abi, functionName: 'approve', args: [spenderAddress, maxUint256] }); ``` `wallet-operations.md:204-237`: ```typescript const KYBER_API = 'https://aggregator-api.kyberswap.com/megaeth/api/v1'; // Get quote const quoteRes = await fetch( `${KYBER_API}/routes?` + new URLSearchParams({ tokenIn: '0x...', // or 'ETH' for native tokenOut: '0x...', amountIn: amount.toString(), gasInclude: 'true' }) ); const quote = await quoteRes.json(); // Build transaction 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 transaction builder accepts `routerAddress`, calldata, ETH value, and gas directly from a remote API response. It does not independently verify: - The active chain ID - The router against an allowlist of audited contracts - The calldata selector and decoded arguments - Input and output token addresses - Sender and recipient - Input amount and ETH value - Minimum output - Slippage and deadline - Whether the calldata grants an approval or performs an unrelated call - Whether the transaction simulation matches the displayed quote The separate approval example recommends `ma ...[truncated 1334 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Maintain an allowlist of verified router addresses keyed by chain ID and protocol version. 2. Decode returned calldata locally and verify the function selector and every security-relevant argument. 3. Confirm that the decoded sender, recipient, input token, output token, amount, minimum output, deadline, and value match the user's displayed intent. 4. Obtain token and router addresses from authenticated, versioned sources. 5. Use exact or tightly bounded approvals instead of `maxUint256`. 6. Prefer permit-style approvals with explicit amount and expiration where supported. 7. Revoke residual allowance after execution when a persistent allowance is unnecessary. 8. Simulate the exact built transaction through a trusted MegaETH-compatible endpoint before requesting a signature. 9. Display decoded transaction details and require explicit user confirmation. 10. Reject stale quotes, excessive price impact, unexpected native value, unknown selectors, or mismatched chain IDs. 11. Validate HTTP status codes and response schemas before accessing `quote.data` or `data`. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
smart-contracts.md:103
Finding
Mainnet Broadcast Guidance Disables Preflight Simulation<![CDATA[ ## Vulnerability Details **File Locations**: - `SKILL.md:53-57` - `SKILL.md:72-76` - `smart-contracts.md:103-118` - `testing.md:52-59` - `gas-model.md:69-73` - `resources.md:198-200` **Vulnerability Type**: Unsafe deployment workflow and contradictory security controls **Risk Level**: High ### Vulnerable Code `SKILL.md:53-57`: ```markdown ### 5. Gas: skip estimation when possible - Base fee stable at 0.001 gwei, no EIP-1559 adjustment - Ignore `eth_maxPriorityFeePerGas` (returns 0) - Hardcode gas limits to save round-trip - Always use remote `eth_estimateGas` (MegaEVM costs differ from standard EVM) ``` `SKILL.md:72-76`: ```markdown ### 2. Pick the right patterns - Frontend: single WebSocket → broadcast to users (not per-user connections) - Transactions: sign locally → `eth_sendRawTransactionSync` → done - Contracts: check SSTORE patterns, avoid volatile data access limits - Testing: use mega-evme for replay, Foundry with `--skip-simulation` ``` `smart-contracts.md:103-118`: ```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 ``` `testing.md:52-59`: ```bash # Foundry: skip local simulation forge script Deploy.s.sol --gas-limit 5000000 --skip-simulation # Or use higher hardcoded limit ``` `gas-model.md:69-73`: ```bash # Skip local simulation, use remote forge script Deploy.s.sol --gas-limit 5000000 --skip-simulation ``` `resources.md:198-200`: ```bash # Deploy with Foundry forge script Deploy.s.sol --rpc-url https://mainnet.megaeth.com/rpc --broadcast --skip-simulation ``` ### Technical Analysis The project correctly notes that local standard-EVM gas accounting may differ from MegaEVM. However, it treats this gas-model incompatibility as a reason to bypass the complete Foundry simulation phase, including in a command that broadcasts to mainnet. Gas estimation and semantic transaction validation are ...[truncated 1586 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove `--skip-simulation` from general deployment and mainnet quick-reference commands. 2. Use a MegaEVM-compatible fork, remote `eth_call`, or supported remote simulation service. 3. Separate semantic simulation from gas estimation: - Simulate transaction behavior. - Obtain MegaEVM gas values remotely. - Apply a documented, bounded safety margin. 4. Require explicit verification of chain ID, deployer address, target contracts, calldata, ETH value, nonce, and expected created addresses. 5. Generate and review a transaction manifest before broadcasting. 6. Require a separate explicit confirmation step for `--broadcast`. 7. Test deployment scripts on testnet with the same bytecode and configuration before mainnet use. 8. Reconcile the contradictory instructions so all files consistently require preflight validation before signing. 9. Use a low-value, least-privileged deployment account where possible. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
smart-contracts.md:327
Finding
ERC-6909 Example Permits Unrestricted Public Minting<![CDATA[ ## Vulnerability Details **File Location**: `smart-contracts.md:327-344` **Vulnerability Type**: Missing access control on a supply-critical function **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 check, role check, signature authorization, supply cap, token-ID restriction, or amount limit. Consequently, every address is authorized to mint arbitrary quantities of every token ID to any recipient. Because this is presented as a basic implementation and lacks an explicit warning that access control has intentionally been omitted, developers or agents may copy it into deployable code. The inherited internal `_mint` function does not provide application-specific authorization automatically. ### Attack Path 1. A developer copies the example into a project and deploys it without adding authorization. 2. An attacker identifies the public `mint(address,uint256,uint256)` function. 3. The attacker calls `mint` with an attacker-controlled recipient, any token ID, and an arbitrary amount. 4. The contract creates the requested supply because no authorization check executes. 5. The attacker repeats the call for any token ID or quantity desired. ### Impact Assessment Any network participant obtains the effective privilege to create unlimited token supply. ...[truncated 296 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Add explicit authorization using a reviewed ownership or role-based access-control implementation. 2. Restrict minting to a dedicated `MINTER_ROLE` or immutable trusted controller. 3. Apply per-token and global supply caps where the economic design requires scarcity. 4. Validate recipient, token ID, and amount. 5. Emit and monitor minting events. 6. Add tests proving that unauthorized callers revert. 7. Test role transfer, role revocation, cap enforcement, and zero-address handling. 8. If the snippet is intentionally incomplete, label it prominently as non-production code and include the required access-control placeholder. Example hardened structure: ```solidity import {ERC6909} from "solady/src/tokens/ERC6909.sol"; import {Ownable} from "solady/src/auth/Ownable.sol"; contract MultiToken is ERC6909, Ownable { constructor(address initialOwner) { _initializeOwner(initialOwner); } function mint( address to, uint256 id, uint256 amount ) external onlyOwner { require(to != address(0), "Invalid recipient"); _mint(to, id, amount); } } ``` ]]>
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (13)

Rp1

Medium
Category
MCP Rug Pull
Confidence
92% confidence
Finding
The README instructs users to run `npx skills add ...` without pinning a specific package version or commit, which can cause installation of whatever package version is current at execution time. If the upstream package or resolution path is compromised, users may execute unreviewed code during install, creating a supply-chain risk.

Missing User Warnings

Medium
Confidence
93% confidence
Finding
The skill explicitly encourages wallet setup, transfers, swaps, and bridging, but the examples do not warn that these actions can move real user funds and should require explicit user confirmation and review of addresses, amounts, and networks. In an AI-agent skill context, this increases the chance that an agent will autonomously prepare or initiate high-risk financial operations without adequate safeguards.

Missing User Warnings

Medium
Confidence
94% confidence
Finding
This skill directly covers high-risk financial actions such as wallet management, transaction submission, token swaps, and bridging, but it does not prominently warn about irreversible on-chain actions, mainnet asset loss, or the need for explicit user confirmation before moving funds. In an agent context, that omission increases the chance that users or downstream automations will treat operational guidance as safe-by-default and execute destructive or costly actions without adequate friction.

Missing User Warnings

Medium
Confidence
91% confidence
Finding
The quick-reference section includes live transaction and deployment commands (`cast send` and `forge script ... --broadcast --skip-simulation`) against a mainnet RPC without any warning that they perform irreversible on-chain actions. In a developer skill, users may copy-paste these commands directly, which increases the risk of unintended fund transfers, accidental mainnet deployment, or bypassing simulation safeguards.

Missing User Warnings

Medium
Confidence
86% confidence
Finding
This markdown includes concrete examples for `eth_sendRawTransactionSync` and `realtime_sendRawTransaction` against the mainnet RPC, which would broadcast a signed transaction if copied literally. The document explains mechanics and performance but does not warn that these examples can spend funds or have irreversible on-chain effects.

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
60% 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
80% confidence
Finding
The latency section encourages pre-signing and nonce pipelining for speed, but omits guardrails around stale nonces, accidental replay of queued transactions, and unintended fund movement if pre-signed payloads are reused or sent under changed conditions. In a wallet/developer skill focused on transaction handling, this can lead users to adopt unsafe operational patterns that cause real financial loss or transaction-ordering mistakes.

Intent-Code Divergence

Medium
Confidence
94% confidence
Finding
The example presents a Solana-style `blockhash` freshness/retry flow inside a MegaETH/EVM security guide, which can mislead developers into implementing incorrect transaction handling assumptions. In a development playbook, contradictory chain semantics are security-relevant because they may cause failed submissions, broken retry logic, or unsafe signing/broadcast workflows based on the wrong threat model.

Intent-Code Divergence

Medium
Confidence
90% confidence
Finding
Referring to 'CPI targets' in an EVM/MegaETH audit checklist imports Solana terminology that does not match the surrounding platform model, increasing the chance that reviewers misunderstand what should actually be checked. While not an exploit primitive by itself, this kind of cross-ecosystem confusion in security guidance can cause audits to miss real risks around arbitrary external calls and call target validation.

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 approves `maxUint256` without warning about the risks of unlimited ERC20 allowances. If the spender contract is compromised, upgraded maliciously, or incorrectly specified, it can drain all approved tokens from the wallet, and a wallet-operations guide makes this pattern especially likely to be copied directly into production scripts.

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.

Static analysis

No suspicious patterns detected.