solidity-argus 0.2.0 → 0.3.2

package/skills/case-studies/rari-fuse/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: rari-fuse
+description: "Case study of the 2022 Rari Fuse exploit: reentrancy in Compound fork draining ~$80M"
+category: reference
+source_url: "https://rekt.news/rari-fuse-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'CEther|CToken'
+    severity: "Medium"
+    description: "Detects usage of Compound-style lending tokens. Forks must ensure reentrancy guards are applied to all sensitive functions."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Rari Fuse (2022)
+
+## Overview
+In April 2022, several Rari Fuse lending pools were exploited for approximately $80 million. The attack targeted a reentrancy vulnerability in the protocol's `CEther` contract, which was a fork of Compound. The attacker was able to borrow assets against their collateral and then re-enter the contract to withdraw the collateral before the borrow was recorded.
+
+## Root Cause
+The vulnerability was a classic reentrancy bug in the `exitMarket` function of the `Comptroller` or the `redeem` function of the `CEther` contract. When a user withdrew ETH, the contract made an external call to the user's address before updating the internal state. Because Rari's fork of Compound did not have a reentrancy guard on these specific functions (or the guard was bypassed), the attacker could recursively call the contract to drain funds.
+
+## Attack Flow
+1. Attacker deposited collateral into a Rari Fuse pool.
+2. Attacker initiated a withdrawal of their collateral (ETH).
+3. The `CEther` contract sent ETH to the attacker's malicious contract via a low-level call.
+4. The attacker's fallback function triggered a call to borrow other assets from the same pool.
+5. Because the collateral withdrawal was not yet finalized in the state, the protocol still saw the attacker as having full collateral, allowing the borrow to succeed.
+6. The attacker effectively withdrew their collateral AND borrowed assets against it, leaving the pool with bad debt.
+
+## Impact
+- **Loss**: ~$80M
+- **Protocol**: Rari Capital (Fuse)
+- **Chain**: Ethereum
+- **Date**: 2022-04-30
+
+## Key Transactions
+- Attack tx: `0xab4860125185a341599c543974807217b3911714771725567b746761632a2939`
+
+## Detection Heuristics
+- Pattern 1: Compound forks that lack reentrancy guards on `redeem`, `borrow`, or `exitMarket` functions.
+- Pattern 2: External calls (especially ETH transfers) made before state updates in lending protocols.
+
+## Remediation
+- Fix 1: Apply the `nonReentrant` modifier to all functions that involve external calls or state changes.
+- Fix 2: Use the Checks-Effects-Interactions pattern to ensure state is updated before any external interaction.
+
+## References
+- [rekt.news/rari-fuse-rekt/](https://rekt.news/rari-fuse-rekt/)
+- [twitter.com/BlockSecTeam/status/1520351351111651328](https://twitter.com/BlockSecTeam/status/1520351351111651328)

package/skills/case-studies/ronin-bridge/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: ronin-bridge
+description: "Case study of the 2022 Ronin Bridge exploit: compromised validator keys draining ~$625M"
+category: reference
+source_url: "https://rekt.news/ronin-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'onlyValidator'
+    severity: "Low"
+    description: "Detects validator-only functions. While not a bug, it highlights the critical trust points in the system."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Ronin Bridge (2022)
+
+## Overview
+In March 2022, the Ronin Network, an Ethereum-linked sidechain for the Axie Infinity game, was exploited for 173,600 ETH and 25.5M USDC (worth ~$625M). This was not a smart contract bug but a social engineering attack that led to the compromise of 5 out of 9 validator private keys.
+
+## Root Cause
+The Ronin bridge required 5 out of 9 validator signatures to authorize withdrawals. The attacker (Lazarus Group) used a fake job offer to compromise a developer's computer, gaining access to 4 validator keys held by Sky Mavis. They also gained access to a 5th validator key held by the Axie DAO, which had been granted a temporary "allowance" to sign on behalf of Sky Mavis during a period of high traffic and was never revoked.
+
+## Attack Flow
+1. Attacker used social engineering (fake job interview/PDF) to plant malware on a Sky Mavis engineer's laptop.
+2. Attacker extracted 4 validator private keys from Sky Mavis infrastructure.
+3. Attacker discovered an RPC backdoor to the Axie DAO validator, which had been authorized to sign for Sky Mavis months earlier.
+4. With 5 keys, the attacker had the supermajority needed to sign withdrawal transactions.
+5. Attacker submitted two withdrawal transactions to the Ronin bridge on Ethereum, draining the funds.
+
+## Impact
+- **Loss**: ~$625M
+- **Protocol**: Ronin Bridge (Sky Mavis)
+- **Chain**: Ronin / Ethereum
+- **Date**: 2022-03-23 (Discovered 2022-03-29)
+
+## Key Transactions
+- Withdrawal tx 1: `0xc28fad5e8d5e0ce6a2eaf67b6687be5d58113e16be590824d6cfa1a691f6d7b3`
+- Withdrawal tx 2: `0xed2c1225a57b6811c570930c7e9996a8a18b19a472f5502013f80f53c7a32730`
+
+## Detection Heuristics
+- Pattern 1: Low validator count (centralization risk).
+- Pattern 2: Long-standing "temporary" permissions or allowances in governance/bridge contracts.
+
+## Remediation
+- Fix 1: Increase the number of validators and the threshold for consensus (Ronin moved to 21 validators).
+- Fix 2: Implement strict security protocols for validator key management (HSMs, multi-party computation).
+- Fix 3: Regular audits of off-chain infrastructure and social engineering training for employees.
+
+## References
+- [rekt.news/ronin-rekt/](https://rekt.news/ronin-rekt/)
+- [roninchain.com/blog/posts/community-alert-ronin-bridge-exploit-post-mortem](https://roninchain.com/blog/posts/community-alert-ronin-bridge-exploit-post-mortem)

package/skills/case-studies/wormhole-bridge/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: wormhole-bridge
+description: "Case study of the 2022 Wormhole Bridge exploit: missing signature validation draining ~$320M"
+category: reference
+source_url: "https://rekt.news/wormhole-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'load_instruction_at'
+    severity: "High"
+    description: "Detects usage of deprecated or dangerous instruction loading in Solana programs which can be used to spoof sysvars."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Wormhole Bridge (2022)
+
+## Overview
+In February 2022, the Wormhole bridge was exploited for 120,000 wETH (worth ~$320M) on the Solana side. The attacker was able to bypass the signature verification process and mint wETH without providing any collateral on the Ethereum side.
+
+## Root Cause
+The vulnerability existed in the Wormhole's Solana program. Specifically, the `verify_signatures` function used a deprecated Solana system function `load_instruction_at` to verify the `instructions` sysvar. The attacker provided a spoofed sysvar account that mimicked the real sysvar but contained fake data, allowing them to bypass the signature check.
+
+## Attack Flow
+1. Attacker identified that the `verify_signatures` function did not properly validate the `instructions` sysvar account.
+2. Attacker created a malicious account that mimicked the `instructions` sysvar.
+3. Attacker called `post_vaa` with the spoofed sysvar, which made the program believe the signatures were valid.
+4. Attacker then called `complete_wrapped_eth` to mint 120,000 wETH on Solana.
+5. Attacker bridged some of the wETH back to Ethereum and swapped the rest on Solana.
+
+## Impact
+- **Loss**: ~$320M
+- **Protocol**: Wormhole Bridge
+- **Chain**: Solana / Ethereum
+- **Date**: 2022-02-02
+
+## Key Transactions
+- Solana Attack tx: `2thJ77y986Yfs4S6996Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9` (Example representation)
+- Mint tx: `399986Yfs4S6996Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9`
+
+## Detection Heuristics
+- Pattern 1: Use of `load_instruction_at` or other deprecated sysvar loading methods in Solana without proper account validation.
+- Pattern 2: Missing checks to ensure that system accounts (like `sysvar::instructions`) are actually the official system accounts.
+
+## Remediation
+- Fix 1: Use the modern `get_instruction_relative` or properly validate the sysvar account address.
+- Fix 2: Ensure all system accounts passed to the program are checked against their known addresses.
+
+## References
+- [rekt.news/wormhole-rekt/](https://rekt.news/wormhole-rekt/)
+- [jumpcrypto.com/wormhole-exploit-post-mortem/](https://jumpcrypto.com/wormhole-exploit-post-mortem/)

package/skills/manifests/smartbugs.json

@@ -5,7 +5,5 @@
   "license": "Apache-2.0",
   "updateCadence": "per-release",
   "lastVerified": "2026-02-19",
-  "files": [
-    "references/smartbugs-examples/SKILL.md"
-  ]
+  "files": ["references/smartbugs-examples/SKILL.md"]
 }

package/skills/manifests/sunweb3sec.json

@@ -5,7 +5,5 @@
   "license": "reference-only",
   "updateCadence": "per-release",
   "lastVerified": "2026-02-19",
-  "files": [
-    "references/exploit-reference/SKILL.md"
-  ]
+  "files": ["references/exploit-reference/SKILL.md"]
 }

package/skills/vulnerability-patterns/access-control/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: access-control
 description: Access-control exploit patterns and secure authorization approaches for privileged Solidity functions.
+pattern_category: access-control
 source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
 source_license: MIT
 imported_at: "2025-01-15T00:00:00Z"
@@ -14,6 +15,19 @@ detection_rules:
     confidence: Medium
     swc: SWC-105
     description: Inline sender authorization check on sensitive paths
+  - regex: 'function\s+initialize'
+    severity: Critical
+    confidence: High
+    description: Initializer function detected — if missing initializer modifier, anyone can take ownership
+  - regex: 'selfdestruct\(|suicide\('
+    severity: High
+    confidence: High
+    description: Contract uses selfdestruct — can destroy contract and send ETH to arbitrary address
+  - regex: 'function\s+\w+\s*\([^)]*\)\s+(external|public)'
+    severity: High
+    confidence: Low
+    swc: SWC-105
+    description: External/public function — verify appropriate access control modifiers are applied
 ---
 
 <!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->

package/skills/vulnerability-patterns/arbitrary-storage-location/SKILL.md

@@ -1,6 +1,18 @@
 ---
 name: arbitrary-storage-location
-description: - Contract has a dynamic array in storage
+description: '- Contract has a dynamic array in storage'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'assembly\s*\{'
+    severity: Medium
+    confidence: Low
+    swc: SWC-124
+    description: Inline assembly context where arbitrary storage writes may occur
+  - regex: 'sstore\('
+    severity: High
+    confidence: Low
+    swc: SWC-124
+    description: Direct storage slot writes require strict slot provenance checks
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/assert-violation/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: assert-violation
-description: - Contract uses `assert()` statements
+description: '- Contract uses `assert()` statements'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'assert\('
+    severity: Low
+    confidence: Medium
+    swc: SWC-110
+    description: assert used in code path that may be user reachable
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/asserting-contract-from-code-size/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: asserting-contract-from-code-size
-description: - Contract uses `extcodesize` or `address.code.length` to check whether an address is an EOA vs. a contract
+description: '- Contract uses `extcodesize` or `address.code.length` to check whether an address is an EOA vs. a contract'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'extcodesize'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-113
+    description: extcodesize-based contract detection can be bypassed in constructors
+  - regex: 'isContract\('
+    severity: Medium
+    confidence: Medium
+    description: isContract helper usage should not gate security decisions
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/authorization-txorigin/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: authorization-txorigin
-description: - Contract uses `tx.origin` for authorization or access control checks (e.g., `require(tx.origin == owner)`)
+description: "Contract uses tx.origin for authorization or access control checks (e.g., require(tx.origin == owner))"
+pattern_category: access-control
 detection_rules:
   - regex: 'tx\.origin'
     severity: High

package/skills/vulnerability-patterns/cross-chain-bridge-vulnerabilities/SKILL.md

@@ -0,0 +1,217 @@
+---
+name: cross-chain-bridge-vulnerabilities
+description: Cross-chain bridge vulnerabilities including missing chain ID validation, cross-chain replay attacks, unverified bridge messages, and hardcoded bridge addresses
+category: vulnerability-pattern
+pattern_category: logic-error
+detection_rules:
+  - regex: '(abi\.encodePacked|keccak256)\s*\([^)]*(?!.*\b(block\.chainid|chainId)\b)[^)]*\)'
+    severity: High
+    confidence: Medium
+    description: Cross-chain message hash constructed without chain ID - signatures or proofs can be replayed on other chains where the contract is deployed at the same address
+  - regex: 'ecrecover\s*\([^)]*(?!.*\b(chainId|block\.chainid)\b)[^)]*\)'
+    severity: High
+    confidence: Medium
+    description: Signature recovery without chain-specific binding - ecrecover call does not reference chainId, allowing signed messages to be replayed across chain forks or L2 deployments
+  - regex: '(onMessageReceived|_processMessage|receiveMessage|handleBridgeMessage)\s*\('
+    severity: Critical
+    confidence: High
+    description: Bridge message receiver function detected - verify the caller is the authorized bridge contract and the source chain/sender are validated before processing
+  - regex: 'address\s+(constant|immutable)\s+\w*(bridge|Bridge|BRIDGE|relay|Relay|messenger|Messenger)\w*\s*='
+    severity: Medium
+    confidence: High
+    description: Hardcoded bridge or relay address - if the bridge contract is upgraded or redeployed, this contract cannot adapt without redeployment
+---
+
+# Cross-Chain Bridge Vulnerability Patterns
+
+## Overview
+
+Bridge systems expand trust boundaries across chains, consensus assumptions, and message formats. A single validation error in message authentication can mint unbacked assets, unlock escrowed collateral, or allow arbitrary calls on destination chains. Because bridges often custody large TVL, exploit impact is frequently catastrophic.
+
+Two themes dominate bridge incidents: insufficient domain separation and weak message authenticity checks. Domain separation prevents a proof or signature from one context (chain, contract, epoch) from being reused in another. Authenticity checks ensure only approved bridge infrastructure and source identities can trigger state transitions.
+
+Bridge security review should treat every inbound message as adversarial by default. Validation must bind the message to source chain, source sender, destination chain, destination contract, nonce, and replay state. Any omitted field becomes a likely replay or forgery surface.
+
+## Key Attack Vectors
+
+- Message hash construction that omits `chainId` or equivalent domain fields.
+- Signature verification via `ecrecover` without chain-specific binding.
+- Receiver handlers that trust `msg.sender` without verifying authorized bridge endpoint.
+- Missing validation of source chain and source application address.
+- Replayable messages due to absent nonce consumption or idempotency checks.
+- Hardcoded bridge addresses that become stale after upgrades or migrations.
+- Weak upgrade controls on bridge config, relayers, and validator sets.
+- Message parsers that decode calldata but do not enforce strict schema/version.
+
+### Typical Replay Attack Flow
+
+1. Attacker observes a valid signed bridge message on Chain A -> Chain B.
+2. Message does not include robust domain separation fields.
+3. Attacker replays the same payload on another deployment or fork.
+4. Destination contract accepts the message as valid.
+5. Funds are minted or released multiple times.
+6. Accounting diverges from source-chain lock state.
+
+### Typical Authentication Bypass Flow
+
+1. Bridge receiver exposes `handleBridgeMessage` style function.
+2. Function checks payload structure but not trusted caller/source identity.
+3. Attacker calls function directly with crafted message.
+4. Contract executes privileged state change (mint, transfer, config update).
+5. Attack completes without compromising bridge validators.
+
+## Detection Heuristics
+
+### Domain Separation Checks
+
+- Search message hash construction for inclusion of `block.chainid` or canonical `chainId` field.
+- Confirm hash binds destination contract address and source chain identifiers.
+- Verify signatures use EIP-712 domain separators with `chainId` and `verifyingContract`.
+- Flag ad-hoc `abi.encodePacked` payloads with ambiguous or incomplete fields.
+
+### Signature Verification Checks
+
+- Review `ecrecover` call sites for explicit domain-bound message digests.
+- Ensure recovered signer is validated against current authorized signer set.
+- Check for malleability handling and strict `s` value constraints where needed.
+- Confirm nonce or message ID is consumed exactly once.
+
+### Receiver Authorization Checks
+
+- Require `msg.sender == trustedBridge` or equivalent allowlist enforcement.
+- Validate source chain ID and source sender embedded in payload.
+- Confirm message ordering and replay protection against duplicate IDs.
+- Ensure receiver functions are `nonReentrant` if they trigger external calls.
+
+### Configuration and Upgrade Checks
+
+- Flag immutable or constant bridge addresses for systems that expect migrations.
+- Validate admin setter functions are timelocked and role-gated.
+- Check event emissions for all config changes (bridge, relayer, validator set).
+- Review emergency pause controls and recovery workflows.
+
+### Concrete Code Smells
+
+```solidity
+bytes32 digest = keccak256(abi.encodePacked(amount, recipient, nonce));
+address signer = ecrecover(digest, v, r, s); // no chain binding
+```
+
+```solidity
+function handleBridgeMessage(bytes calldata payload) external {
+    // missing require(msg.sender == trustedBridge)
+    _process(payload);
+}
+```
+
+```solidity
+address immutable bridgeMessenger = 0x1234...; // no upgrade path
+```
+
+### Audit Checklist
+
+- Is message identity globally unique across chains and contracts?
+- Can the same proof be replayed on forks or sibling deployments?
+- Are source app addresses validated against chain-scoped allowlists?
+- Is every successful message marked consumed atomically?
+- Can governance safely rotate bridge endpoints and signer sets?
+
+## Prevention
+
+### Message Schema Hardening
+
+- Use typed message structs with explicit fields: source chain, destination chain, source app, destination app, nonce, payload hash.
+- Hash using EIP-712 domain separation when signatures are involved.
+- Reject unknown schema versions to avoid parsing ambiguity.
+- Enforce strict decoding with size and range checks.
+
+### Authentication and Replay Controls
+
+- Verify caller is the designated bridge endpoint contract.
+- Validate source chain ID and sender against immutable or governable allowlists.
+- Consume message IDs in a replay map before external side effects.
+- Make message execution idempotent where practical.
+
+### Configurability with Safety
+
+- Prefer configurable bridge addresses over hardcoded constants.
+- Protect config updates with timelock and multi-sig governance.
+- Emit detailed events on every trust-boundary change.
+- Add two-step ownership transfer for bridge admin roles.
+
+### Hardened Receiver Example
+
+```solidity
+function handleBridgeMessage(
+    uint256 sourceChainId,
+    address sourceApp,
+    uint256 nonce,
+    bytes calldata payload,
+    bytes calldata proof
+) external nonReentrant {
+    require(msg.sender == trustedBridge, "Unauthorized bridge caller");
+    require(allowedSourceChains[sourceChainId], "Unsupported source chain");
+    require(allowedSourceApps[sourceChainId][sourceApp], "Unsupported source app");
+
+    bytes32 messageId = keccak256(
+        abi.encode(
+            block.chainid,
+            sourceChainId,
+            sourceApp,
+            address(this),
+            nonce,
+            keccak256(payload)
+        )
+    );
+
+    require(!consumed[messageId], "Replay");
+    require(verifyProof(messageId, proof), "Invalid proof");
+
+    consumed[messageId] = true;
+    _executePayload(payload);
+}
+```
+
+### Operational Defenses
+
+- Continuously monitor duplicate message IDs across chains.
+- Run chaos tests with forked deployments and stale bridge configs.
+- Maintain emergency pause for inbound message processing.
+- Reconcile bridge accounting between lock and mint sides on a schedule.
+
+## Real-World Examples
+
+### Wormhole (2022)
+
+- Reference: https://rekt.news/wormhole-rekt/
+- Forged verification path enabled minting of unbacked wrapped assets.
+- Lesson: proof and signature validation must be strict, domain-separated, and invariant-tested.
+
+### Nomad (2022)
+
+- Reference: https://rekt.news/nomad-rekt/
+- Message validation assumptions failed, enabling widespread unauthorized message replay/copycat draining.
+- Lesson: receiver authenticity checks and replay protection are critical at every handler entry point.
+
+### Additional Bridge Incident Patterns
+
+- Bridge key-management failures (validator compromise).
+- Config drift between source and destination chain deployments.
+- Insufficient upgrade controls introducing unreviewed trust paths.
+
+### Pattern-to-Impact Mapping
+
+- `missing-chain-id-validation` -> cross-chain replay of otherwise valid messages.
+- `replay-across-chains` -> signature reuse on forks/L2 mirrors.
+- `unverified-bridge-message` -> direct unauthorized execution on destination chain.
+- `hardcoded-bridge-address` -> operational failure or unsafe hotfix pressure during upgrades.
+
+## References
+
+- Rekt News Wormhole: https://rekt.news/wormhole-rekt/
+- Rekt News Nomad: https://rekt.news/nomad-rekt/
+- EIP-712 typed structured data hashing: https://eips.ethereum.org/EIPS/eip-712
+- OpenZeppelin access control patterns: https://docs.openzeppelin.com/contracts/4.x/access-control
+- Chainlink CCIP security overview: https://docs.chain.link/ccip
+- NIST guidance on replay resistance concepts: https://csrc.nist.gov/
+- Trail of Bits bridge security research: https://blog.trailofbits.com/

package/skills/vulnerability-patterns/default-visibility/SKILL.md

@@ -1,6 +1,18 @@
 ---
 name: default-visibility
-description: - Functions or state variables are declared without an explicit visibility specifier
+description: '- Functions or state variables are declared without an explicit visibility specifier'
+pattern_category: access-control
+detection_rules:
+  - regex: 'function\s+\w+\s*\('
+    severity: Informational
+    confidence: Low
+    swc: SWC-100
+    description: Generic function declaration signal for manual default visibility review (legacy SWC-100/SWC-108 context)
+  - regex: 'function\s+\w+\s*\([^)]*\)\s*\{'
+    severity: Medium
+    confidence: Low
+    swc: SWC-100
+    description: Function without explicit visibility specifier — defaults to public in older Solidity versions
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/delegatecall-untrusted-callee/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: delegatecall-untrusted-callee
-description: - Contract uses `delegatecall`
+description: "Contract uses delegatecall with potentially untrusted callee"
+pattern_category: delegatecall
 detection_rules:
   - regex: 'delegatecall'
     severity: High

package/skills/vulnerability-patterns/dos-gas-limit/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: dos-gas-limit
-description: - Contract iterates over a dynamic array or mapping whose size can grow unboundedly
+description: '- Contract iterates over a dynamic array or mapping whose size can grow unboundedly'
+pattern_category: dos
+detection_rules:
+  - regex: 'for\s*\([^)]*\.length'
+    severity: Medium
+    confidence: Low
+    swc: SWC-128
+    description: Loop bounded by dynamic length may become unexecutable at scale
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/dos-revert/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: dos-revert
 description: Denial-of-service attacks through unexpected reverts in external calls
+pattern_category: dos
 source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
 source_license: MIT
 imported_at: "2025-01-15T00:00:00Z"

package/skills/vulnerability-patterns/erc4626-exchange-rate-manipulation/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: erc4626-exchange-rate-manipulation
+description: "ERC-4626 integrations are exploited by manipulating share price or conversion state to mint, borrow, or redeem at distorted rates."
+category: vulnerability-pattern
+pattern_category: erc4626
+source_url: "https://github.com/bailsec/BailSec"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: "(convertToShares|convertToAssets|previewDeposit|previewWithdraw|totalAssets\\()"
+    severity: "High"
+    description: "Critical ERC-4626 conversion surfaces requiring manipulation resistance"
+  - regex: "flashLoan\\(|flash\\s*loan|donat(e|ion)"
+    severity: "High"
+    description: "Capital-amplified exchange-rate manipulation preconditions"
+  - regex: 'balanceOf.*address.*this.*totalAssets|asset\.balanceOf'
+    severity: High
+    confidence: Medium
+    description: Vault totalAssets derived from balanceOf — vulnerable to donation attack to inflate share price
+  - regex: 'mulDiv|roundUp|roundDown|FullMath'
+    severity: Medium
+    confidence: Medium
+    description: Custom rounding math in vault share calculations — potential rounding errors favoring attacker
+  - regex: 'shares\s*=\s*(assets|amount)\b'
+    severity: Critical
+    confidence: Medium
+    description: Direct asset-to-share mapping without virtual offset — first depositor can inflate share price
+  - regex: '\.transfer\(address\(this\)|\.safeTransfer\(address\(this\)'
+    severity: High
+    confidence: Medium
+    description: Direct token transfer to vault bypassing deposit accounting — enables donation attack
+  - regex: 'totalSupply\(\)\s*==\s*0|totalAssets\(\)\s*==\s*0'
+    severity: Medium
+    confidence: Medium
+    description: Empty vault state check without minimum deposit or dead share enforcement
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# ERC4626 Exchange Rate Manipulation Vulnerabilities
+
+## Overview
+This pattern targets vault systems that rely on ERC-4626 share/asset conversion, especially when those conversions are consumed by lending, collateral, or routing logic. Attackers manipulate the apparent exchange rate (or timing of its update) so victims mint too few shares, borrow against mispriced collateral, or absorb bad debt. The exploit usually combines one of: flash liquidity, share supply edge cases, stale accounting, rounding asymmetry, or permissive user-specified share parameters.
+
+The core failure is trusting conversion outputs as if they were immutable and manipulation-resistant under adversarial flow ordering.
+
+## Common Patterns
+- User-facing functions accept shares as input without robust slippage/min-out protection.
+- Vault share price can be inflated/deflated between preview and execution.
+- First-user or low-liquidity states create nonlinear price jumps.
+- Protocol treats ERC-4626 collateral as safe despite supply concentration and flash accessibility.
+
+## Detection Heuristics
+- Trace every use of `convertToShares/Assets` and `preview*` into borrow limits, liquidation, and accounting updates.
+- Check for same-tx manipulability of `totalAssets` or effective share supply.
+- Verify min-out controls for both assets and shares on deposit/withdraw flows.
+- Stress-test empty, near-empty, and first-deposit states with fuzzed ordering.
+
+## Examples from Audits
+- Share-price inflation path where a victim specifying share quantity could be induced to supply more assets than intended.
+- ERC-4626 collateral market where flash-loan control of share supply enabled bad-debt creation through exchange-rate distortion.
+- Vault inflation scenario where fee accrual and conversion math created attacker-favorable rounding for later users.
+
+## Remediation
+Require explicit user slippage bounds on both assets and shares. Add anti-manipulation checks that compare pre/post conversion expectations and reject large deltas within the same transaction context. Introduce bootstrap protections for first deposits (seed shares, dead shares, or guarded initialization). For lending integrations, gate collateral eligibility, cap concentration, and add oracle or TWAP defenses around vault share pricing. Finally, test conversion invariants under adversarial ordering and flash-capital assumptions.