solidity-argus 0.2.0 → 0.3.0

package/skills/case-studies/beanstalk-governance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: beanstalk-governance
+description: "Case study of the 2022 Beanstalk exploit: flash loan + governance manipulation draining ~$182M"
+category: reference
+source_url: "https://rekt.news/beanstalk-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'propose\(.*\)'
+    severity: "Medium"
+    description: "Detects governance proposal functions. Critical to check if voting power can be acquired via flash loans."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Beanstalk Governance (2022)
+
+## Overview
+In April 2022, Beanstalk Farms, a decentralized credit-based stablecoin protocol, was exploited for approximately $182 million. The attacker used a flash loan to acquire a massive amount of the protocol's governance token (Stalk), allowing them to pass a malicious governance proposal and drain the protocol's reserves.
+
+## Root Cause
+The vulnerability was in the protocol's governance mechanism, which allowed users to gain voting power (Stalk) by depositing assets into the "Silo". Crucially, the protocol did not prevent users from using flash-loaned assets to gain this voting power and immediately vote on proposals. The attacker used this to reach the 67% supermajority required to execute a "BIP" (Beanstalk Improvement Proposal) instantly.
+
+## Attack Flow
+1. Attacker took a massive flash loan from Aave, Uniswap, and SushiSwap (including ~350M DAI, 500M USDC, 150M USDT, 32M BEAN, and 11M LUSD).
+2. Attacker deposited these assets into the Beanstalk Silo to gain a huge amount of Stalk (voting power).
+3. Attacker had already submitted two malicious proposals (BIP-18 and BIP-19) one day prior.
+4. With the flash-loaned Stalk, the attacker voted in favor of their own proposals, reaching the 67% threshold.
+5. The proposals were executed immediately, sending all assets in the Beanstalk Silo to the attacker's address.
+6. Attacker repaid the flash loans and kept the remaining assets (mostly ETH and stablecoins).
+
+## Impact
+- **Loss**: ~$182M
+- **Protocol**: Beanstalk Farms
+- **Chain**: Ethereum
+- **Date**: 2022-04-17
+
+## Key Transactions
+- Attack tx: `0xcd314c6351513518c37cba34ba8225939f8f5787a0a0d958999cc468992275d6`
+
+## Detection Heuristics
+- Pattern 1: Governance systems where voting power can be acquired and used within the same transaction (vulnerable to flash loans).
+- Pattern 2: Lack of a delay between proposal submission, voting, and execution.
+
+## Remediation
+- Fix 1: Implement a "snapshot" mechanism for voting power, where power is determined by balances at a previous block.
+- Fix 2: Introduce a mandatory delay (e.g., 2-3 days) between proposal submission and the start of voting, and another delay before execution.
+- Fix 3: Prevent flash-loaned assets from being used to gain governance rights (e.g., by checking if the balance was acquired in the same block).
+
+## References
+- [rekt.news/beanstalk-rekt/](https://rekt.news/beanstalk-rekt/)
+- [bean.money/blog/2022-04-18-post-mortem-of-the-beanstalk-exploit](https://bean.money/blog/2022-04-18-post-mortem-of-the-beanstalk-exploit)

package/skills/case-studies/bzx-flash-loan/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: bzx-flash-loan
+description: "Case study of the 2020 bZx exploits: oracle manipulation via flash loans draining ~$1M"
+category: reference
+source_url: "https://rekt.news/bzx-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'KyberNetworkProxy|UniswapV2Router'
+    severity: "Medium"
+    description: "Detects usage of DEX routers which might be used as price oracles."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# bZx Flash Loan Exploits (2020)
+
+## Overview
+In February 2020, bZx was hit by two separate flash loan attacks within days. The first attack involved a complex sequence of trades to manipulate the price of WBTC on Kyber, while the second attack manipulated the sUSD price on Kyber using a flash loan from bZx itself. Total losses were approximately $1M.
+
+## Root Cause
+The primary vulnerability was bZx's reliance on a single on-chain liquidity source (Kyber) as a price oracle. By using flash loans to execute large trades on Kyber, the attacker could significantly move the price, allowing them to take out undercollateralized loans or execute profitable liquidations on bZx.
+
+## Attack Flow (First Attack)
+1. Attacker took a flash loan of 10,000 ETH from dYdX.
+2. Attacker deposited 5,500 ETH to Compound to borrow 112 WBTC.
+3. Attacker deposited 1,300 ETH to bZx to open a 5x short position on ETH/BTC.
+4. bZx executed the short by swapping ETH for WBTC on Kyber, which routed to Uniswap.
+5. The large trade on Uniswap caused massive slippage, driving up the WBTC price.
+6. Attacker sold the 112 WBTC borrowed from Compound back into the manipulated market for a huge profit.
+7. Attacker repaid the dYdX flash loan.
+
+## Impact
+- **Loss**: ~$1M
+- **Protocol**: bZx (Fulcrum/Torque)
+- **Chain**: Ethereum
+- **Date**: 2020-02-15 (First), 2020-02-18 (Second)
+
+## Key Transactions
+- First Attack tx: `0xb5c8bd9430b6cc87a0e2fe110ece6bf527fa4f170a4bc8cd032f768fc5219838`
+- Second Attack tx: `0x762881dda4f35930d15524a4413fde45bc75096f0a7a495caeac6197b928e934`
+
+## Detection Heuristics
+- Pattern 1: Use of low-liquidity DEX pools as the sole price oracle for lending or margin trading.
+- Pattern 2: Lack of slippage checks or price deviation checks against external oracles (like Chainlink).
+
+## Remediation
+- Fix 1: Use decentralized, aggregate oracles like Chainlink or Time-Weighted Average Prices (TWAP) from Uniswap V2+.
+- Fix 2: Implement circuit breakers or maximum slippage limits for large trades.
+
+## References
+- [rekt.news/bzx-rekt/](https://rekt.news/bzx-rekt/)
+- [bzx.network/blog/post-mortem-eth-btc-margin-tokens-exploit](https://bzx.network/blog/post-mortem-eth-btc-margin-tokens-exploit)

package/skills/case-studies/cream-finance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: cream-finance
+description: "Case study of the 2021 Cream Finance exploit: flash loan + oracle manipulation draining ~$130M"
+category: reference
+source_url: "https://rekt.news/cream-rekt-2/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'yUSD|yETH'
+    severity: "Medium"
+    description: "Detects usage of Yearn vault tokens which can have complex pricing mechanisms vulnerable to manipulation."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Cream Finance (2021)
+
+## Overview
+In October 2021, Cream Finance was exploited for approximately $130 million. The attacker used a complex flash loan attack to manipulate the price of Yearn's yUSD vault tokens, which were used as collateral on Cream. By inflating the value of yUSD, the attacker was able to borrow almost all other assets available on the platform.
+
+## Root Cause
+The vulnerability lay in how Cream Finance calculated the price of Yearn vault tokens (yUSD). The price was derived from the total assets in the Yearn vault divided by the total supply of vault shares. The attacker used flash loans to deposit a massive amount of assets into the Yearn vault, which temporarily inflated the "price per share" used by Cream's oracle.
+
+## Attack Flow
+1. Attacker took a massive flash loan of 500M DAI and other assets from MakerDAO and Aave.
+2. Attacker deposited the DAI into Yearn's yUSD vault to receive yUSD tokens.
+3. Attacker then deposited the yUSD into Cream Finance as collateral.
+4. Attacker used more flash-loaned assets to further manipulate the Yearn vault's internal state, significantly increasing the reported value of yUSD on Cream.
+5. With the inflated collateral value, the attacker borrowed almost all liquid assets from Cream's lending pools (ETH, WBTC, stablecoins).
+6. Attacker repaid the flash loans and kept the borrowed assets.
+
+## Impact
+- **Loss**: ~$130M
+- **Protocol**: Cream Finance
+- **Chain**: Ethereum
+- **Date**: 2021-10-27
+
+## Key Transactions
+- Attack tx: `0x0fe2588608f3588c4a273c63e47ae7793c920909623d9d55666e082059d3c7df`
+
+## Detection Heuristics
+- Pattern 1: Using vault share prices (like `pricePerShare`) as an oracle without accounting for potential manipulation of the underlying vault's reserves.
+- Pattern 2: Lack of caps on how much a single asset can be used as collateral, especially for complex derivative tokens.
+
+## Remediation
+- Fix 1: Use more robust oracles that are resistant to instantaneous reserve manipulation (e.g., Chainlink or TWAP).
+- Fix 2: Implement collateral caps and borrow limits to prevent a single exploit from draining the entire protocol.
+- Fix 3: Add a delay or "sanity check" when the price of a collateral asset changes significantly within a short period.
+
+## References
+- [rekt.news/cream-rekt-2/](https://rekt.news/cream-rekt-2/)
+- [medium.com/cream-finance/c-r-e-a-m-finance-post-mortem-october-27-2021-d5a411f3f87a](https://medium.com/cream-finance/c-r-e-a-m-finance-post-mortem-october-27-2021-d5a411f3f87a)

package/skills/case-studies/curve-reentrancy/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: curve-reentrancy
+description: "Case study of the 2023 Curve reentrancy exploit: Vyper compiler bug draining ~$70M"
+category: reference
+source_url: "https://rekt.news/curve-lp-rekt-vyper-reentrancy/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: '@nonreentrant'
+    severity: "High"
+    description: "Detects Vyper's nonreentrant decorator. In certain compiler versions (0.2.15, 0.2.16, 0.3.0), this was broken for cross-function reentrancy."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Curve Reentrancy (2023)
+
+## Overview
+In July 2023, several Curve Finance liquidity pools (alETH, msETH, pETH) were exploited for approximately $70 million. Unlike most reentrancy attacks caused by developer error, this was caused by a bug in the Vyper compiler (versions 0.2.15, 0.2.16, and 0.3.0) that failed to properly implement reentrancy guards.
+
+## Root Cause
+The vulnerability was a compiler-level bug in Vyper's `@nonreentrant` decorator. In the affected versions, the compiler used the same storage slot for reentrancy locks across different functions if they were in the same "reentrancy group", but it failed to correctly handle the lock state in certain scenarios involving cross-function calls. This allowed an attacker to re-enter a contract through a different function even if both were marked `@nonreentrant`.
+
+## Attack Flow
+1. Attacker identified Curve pools using vulnerable Vyper versions (specifically those with `add_liquidity` and `remove_liquidity` functions).
+2. Attacker called `add_liquidity` to deposit assets.
+3. During the execution of `add_liquidity`, the contract made an external call (e.g., to a token's `transfer` or `fallback` function).
+4. The attacker's malicious contract re-entered the Curve pool by calling `remove_liquidity`.
+5. Because the reentrancy guard was broken at the compiler level, the second call was allowed to proceed before the first call's state updates (like updating the pool's total supply) were finalized.
+6. This allowed the attacker to withdraw more assets than they were entitled to.
+
+## Impact
+- **Loss**: ~$70M
+- **Protocol**: Curve Finance
+- **Chain**: Ethereum
+- **Date**: 2023-07-30
+
+## Key Transactions
+- Attack tx (pETH pool): `0xa84aa0650c3e6f849339384388e1a769a540003ade07ba379c2d3efc4fb7ca7d`
+
+## Detection Heuristics
+- Pattern 1: Use of Vyper compiler versions 0.2.15, 0.2.16, or 0.3.0.
+- Pattern 2: Contracts with multiple functions using the same reentrancy lock key.
+
+## Remediation
+- Fix 1: Upgrade to a patched version of the Vyper compiler (0.3.1 or later).
+- Fix 2: Manually implement reentrancy guards using storage variables if the compiler version cannot be changed.
+- Fix 3: Conduct thorough audits that include checking the underlying compiler and infrastructure vulnerabilities.
+
+## References
+- [rekt.news/curve-lp-rekt-vyper-reentrancy/](https://rekt.news/curve-lp-rekt-vyper-reentrancy/)
+- [hackmd.io/@vyperlang/H1No9_h_h](https://hackmd.io/@vyperlang/H1No9_h_h)

package/skills/case-studies/dao-hack/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: dao-hack
+description: "Case study of the 2016 DAO hack: reentrancy exploit draining ~$60M"
+category: reference
+source_url: "https://rekt.news/dao-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: '\.call\{value:.*\}\(.*\);'
+    severity: "High"
+    description: "Detects low-level calls that may be vulnerable to reentrancy if state is updated after the call."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# DAO Hack (2016)
+
+## Overview
+The DAO was a decentralized autonomous organization launched in 2016 on the Ethereum blockchain. It was designed to operate as a venture capital fund for the crypto space. In June 2016, an attacker exploited a reentrancy vulnerability in the DAO's smart contract, draining approximately 3.6 million ETH, worth about $60 million at the time.
+
+## Root Cause
+The vulnerability was a classic reentrancy bug. The `splitDAO` function allowed a member to withdraw their ETH and receive "Child DAO" tokens. The contract sent ETH to the user using a low-level `.call()` before updating the user's balance. This allowed the attacker to recursively call the `splitDAO` function from their malicious contract's fallback function before the first call finished, effectively draining the contract.
+
+## Attack Flow
+1. The attacker created a malicious contract and funded it with DAO tokens.
+2. The attacker called the `splitDAO` function.
+3. The DAO contract sent ETH to the attacker's contract via a low-level call.
+4. The attacker's fallback function triggered another call to `splitDAO`.
+5. Steps 3 and 4 repeated recursively until the gas limit was reached or the contract was drained.
+6. The state update (reducing the attacker's balance) only happened after the recursive calls finished, which was too late.
+
+## Impact
+- **Loss**: ~$60M (3.6M ETH)
+- **Protocol**: The DAO
+- **Chain**: Ethereum
+- **Date**: 2016-06-17
+
+## Key Transactions
+- Attack tx: `0x0eb3f4d006903f621f048358878b2ad9046f00d28e5540fa24644433252170e4`
+
+## Detection Heuristics
+- Pattern 1: Low-level `.call()` used for ETH transfers without a reentrancy guard.
+- Pattern 2: State variables (like balances) updated after an external call.
+
+## Remediation
+- Fix 1: Use the Checks-Effects-Interactions pattern. Update state before making external calls.
+- Fix 2: Implement a reentrancy guard (e.g., OpenZeppelin's `ReentrancyGuard`).
+
+## References
+- [rekt.news/dao-rekt/](https://rekt.news/dao-rekt/)
+- [blog.slock.it/the-history-of-the-dao-628d50257c3d](https://blog.slock.it/the-history-of-the-dao-628d50257c3d)

package/skills/case-studies/euler-finance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: euler-finance
+description: "Case study of the 2023 Euler Finance exploit: donation attack draining ~$197M"
+category: reference
+source_url: "https://rekt.news/euler-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'donateToReserves'
+    severity: "High"
+    description: "Detects donation functions that might allow a user to intentionally make their position underwater to trigger liquidations."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Euler Finance (2023)
+
+## Overview
+In March 2023, Euler Finance, a non-custodial lending protocol, was exploited for approximately $197 million. The attacker used a "donation attack" where they intentionally made their own position underwater by donating funds to the protocol's reserves, allowing them to liquidate themselves and profit from the protocol's bad debt handling.
+
+## Root Cause
+The vulnerability was in the `donateToReserves` function of the EToken contract. This function allowed a user to donate their EToken balance to the protocol's reserves. However, it did not check if the donation would make the user's position insolvent. By donating a large amount of collateral while having a large debt, the attacker could make their position underwater and then use a separate account to liquidate the position at a massive discount.
+
+## Attack Flow
+1. Attacker took a flash loan of 30M DAI from Aave.
+2. Attacker deposited 20M DAI into Euler to receive eDAI.
+3. Attacker leveraged their position by minting 200M dDAI (debt) and 195M eDAI (collateral).
+4. Attacker called `donateToReserves` with 100M eDAI. This reduced their collateral but kept their debt the same, making the position heavily underwater.
+5. Attacker used a second account to liquidate the first account. Due to the way Euler's liquidation worked, the liquidator received the remaining eDAI at a massive discount, while the protocol was left with bad debt.
+6. Attacker repeated this for other assets (wBTC, wETH, stETH).
+7. Attacker repaid the flash loan and kept the profit.
+
+## Impact
+- **Loss**: ~$197M
+- **Protocol**: Euler Finance
+- **Chain**: Ethereum
+- **Date**: 2023-03-13
+
+## Key Transactions
+- Attack tx (DAI): `0xc310a0affe2169d1f6feec1c63dbc7f7c62a88bf44e7906e2bc6445e10086615`
+
+## Detection Heuristics
+- Pattern 1: Functions that allow users to reduce their collateral (e.g., via donation or transfer) without checking their health factor or solvency.
+- Pattern 2: Liquidation logic that doesn't properly account for "donated" or "burned" collateral.
+
+## Remediation
+- Fix 1: Add a health factor check to the `donateToReserves` function to ensure the user remains solvent after the donation.
+- Fix 2: Implement stricter checks on liquidation bonuses and ensure that the protocol's reserves are not used to subsidize malicious liquidations.
+
+## References
+- [rekt.news/euler-rekt/](https://rekt.news/euler-rekt/)
+- [euler.finance/blog/euler-vault-kit-post-mortem](https://www.euler.finance/blog/euler-vault-kit-post-mortem)

package/skills/case-studies/harvest-finance/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: harvest-finance
+description: "Case study of the 2020 Harvest Finance exploit: flash loan + price manipulation draining ~$34M"
+category: reference
+source_url: "https://rekt.news/harvest-finance-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'getPricePerFullShare'
+    severity: "Medium"
+    description: "Detects usage of share price functions which can be manipulated by large trades in underlying pools."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Harvest Finance (2020)
+
+## Overview
+In October 2020, Harvest Finance was exploited for approximately $34 million. The attacker used flash loans to manipulate the price of stablecoins (USDC and USDT) within Curve Finance pools, which Harvest used to calculate the value of its vault shares.
+
+## Root Cause
+Harvest Finance vaults calculated the value of their shares based on the "virtual price" of assets in Curve pools. By using a flash loan to execute a massive swap in a Curve pool, the attacker could temporarily depress the price of an asset. They then deposited that asset into Harvest at the depressed price, swapped back in Curve to restore the price, and withdrew from Harvest at the higher price.
+
+## Attack Flow
+1. Attacker took a flash loan of 50M USDC and 17.3M USDT from Uniswap V2.
+2. Attacker swapped 11.4M USDC for USDT on Curve's Y pool, pushing down the USDC price.
+3. Attacker deposited 60.6M USDC into the Harvest fUSDC vault. Because the USDC price was manipulated downwards, the attacker received more fUSDC shares than they should have.
+4. Attacker swapped the USDT back for USDC on Curve, restoring the price.
+5. Attacker withdrew USDC from the Harvest vault. Since the price was now higher, their shares were worth more USDC than they deposited.
+6. Attacker repeated this process multiple times.
+7. Attacker repaid the flash loan and walked away with the profit.
+
+## Impact
+- **Loss**: ~$34M
+- **Protocol**: Harvest Finance
+- **Chain**: Ethereum
+- **Date**: 2020-10-26
+
+## Key Transactions
+- Attack tx: `0x35f8d2f572fceaac9288e5632737885a062dd0c8587ce9044329942b694a9974`
+
+## Detection Heuristics
+- Pattern 1: Calculating share value or collateral value based on instantaneous on-chain prices from a single pool.
+- Pattern 2: Lack of slippage protection or "sanity checks" against a more robust oracle when depositing or withdrawing from vaults.
+
+## Remediation
+- Fix 1: Use a decentralized oracle (like Chainlink) or a TWAP for asset valuation.
+- Fix 2: Implement a "slippage" or "premium" check that prevents deposits/withdrawals when the pool price deviates significantly from the oracle price.
+
+## References
+- [rekt.news/harvest-finance-rekt/](https://rekt.news/harvest-finance-rekt/)
+- [medium.com/harvest-finance/harvest-flashloan-economic-attack-post-mortem-3cf900d65bc6](https://medium.com/harvest-finance/harvest-flashloan-economic-attack-post-mortem-3cf900d65bc6)

package/skills/case-studies/level-finance/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: level-finance
+description: "Case study of the 2023 Level Finance exploit: referral code reentrancy draining ~$1.1M"
+category: reference
+source_url: "https://rekt.news/level-finance-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'claimMultiple'
+    severity: "High"
+    description: "Detects functions that allow multiple claims in a single transaction. Must be checked for reentrancy if they involve external calls."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Level Finance (2023)
+
+## Overview
+In May 2023, Level Finance, a decentralized perpetual exchange on BNB Chain, was exploited for approximately $1.1 million. The attacker exploited a reentrancy vulnerability in the protocol's referral contract, specifically within the `claimMultiple` function, allowing them to claim referral rewards multiple times in a single transaction.
+
+## Root Cause
+The vulnerability was in the `LevelReferralController` contract. The `claimMultiple` function allowed users to claim rewards for multiple referral epochs. However, the function did not follow the Checks-Effects-Interactions pattern and lacked a reentrancy guard. The contract sent rewards to the user before updating the `isClaimed` status for the epoch, allowing the attacker to re-enter the function and claim the same rewards repeatedly.
+
+## Attack Flow
+1. Attacker created multiple referral accounts and generated referral rewards.
+2. Attacker called the `claimMultiple` function with a list of epoch IDs.
+3. The contract calculated the rewards and sent them to the attacker's malicious contract.
+4. The attacker's fallback function triggered another call to `claimMultiple` with the same epoch IDs.
+5. Because the `isClaimed` status was only updated after the loop finished, the second call (and subsequent recursive calls) succeeded.
+6. Attacker drained approximately 214,000 LVL tokens and swapped them for 3,345 BNB.
+
+## Impact
+- **Loss**: ~$1.1M
+- **Protocol**: Level Finance
+- **Chain**: BNB Chain
+- **Date**: 2023-05-01
+
+## Key Transactions
+- Attack tx: `0xe18396571315154179da08573f38039c50f8c46653302f9c449e10ba575606f5`
+
+## Detection Heuristics
+- Pattern 1: Reward claiming functions that iterate over a list and make external calls within the loop before updating the "claimed" status.
+- Pattern 2: Lack of reentrancy guards on functions that handle token transfers or sensitive state updates.
+
+## Remediation
+- Fix 1: Implement a reentrancy guard (`nonReentrant` modifier) on the `claimMultiple` function.
+- Fix 2: Use the Checks-Effects-Interactions pattern. Update the `isClaimed` status for each epoch *before* sending the rewards.
+
+## References
+- [rekt.news/level-finance-rekt/](https://rekt.news/level-finance-rekt/)
+- [twitter.com/Level__Finance/status/1653035345610817536](https://twitter.com/Level__Finance/status/1653035345610817536)

package/skills/case-studies/mango-markets/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: mango-markets
+description: "Case study of the 2022 Mango Markets exploit: oracle price manipulation draining ~$114M"
+category: reference
+source_url: "https://rekt.news/mango-markets-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'MNGO'
+    severity: "Low"
+    description: "Detects usage of the MNGO token. Highlights the risk of using low-liquidity governance tokens as collateral."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Mango Markets (2022)
+
+## Overview
+In October 2022, Mango Markets, a decentralized exchange on Solana, was exploited for approximately $114 million. The attacker used a large amount of capital to manipulate the price of the MNGO token on the platform's own order book, which was used as the price oracle for collateral valuation.
+
+## Root Cause
+The vulnerability was the protocol's reliance on its own low-liquidity internal markets as a price oracle for its native token (MNGO). By wash trading MNGO against USDC, the attacker was able to artificially inflate the price of MNGO. Because Mango used this manipulated price to determine how much a user could borrow, the attacker was able to take out massive loans of other assets (USDC, SOL, BTC, etc.) against their "valuable" MNGO collateral.
+
+## Attack Flow
+1. Attacker funded two separate accounts with 5M USDC each.
+2. Account A placed a large sell order for MNGO perps at a high price.
+3. Account B placed a large buy order for MNGO perps, matching Account A's order.
+4. This wash trade significantly moved the MNGO price on the Mango order book.
+5. The internal oracle updated the MNGO price based on these trades, inflating it by over 2,000%.
+6. With the inflated MNGO collateral value, Account B borrowed $114M worth of various assets from the Mango treasury.
+7. The attacker then proposed a governance settlement to return some funds in exchange for no criminal prosecution (which was later rejected by law enforcement).
+
+## Impact
+- **Loss**: ~$114M
+- **Protocol**: Mango Markets
+- **Chain**: Solana
+- **Date**: 2022-10-11
+
+## Key Transactions
+- Attack tx (Example): `599986Yfs4S6996Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9Yv9`
+
+## Detection Heuristics
+- Pattern 1: Using internal, low-liquidity markets as the primary price oracle for collateral.
+- Pattern 2: Lack of caps on borrowing against highly volatile or manipulatable assets.
+
+## Remediation
+- Fix 1: Use external, aggregate oracles (like Pyth or Chainlink) that incorporate liquidity from multiple high-volume exchanges.
+- Fix 2: Implement "oracle confidence intervals" or "sanity checks" that ignore price spikes that aren't reflected in broader markets.
+- Fix 3: Set strict borrow limits and higher collateral requirements for native governance tokens.
+
+## References
+- [rekt.news/mango-markets-rekt/](https://rekt.news/mango-markets-rekt/)
+- [mango.markets/blog/post-mortem-october-exploit](https://mango.markets/blog/post-mortem-october-exploit)

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

@@ -0,0 +1,51 @@
+---
+name: nomad-bridge
+description: "Case study of the 2022 Nomad Bridge exploit: initialization bug draining ~$190M"
+category: reference
+source_url: "https://rekt.news/nomad-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: '0x0000000000000000000000000000000000000000000000000000000000000000'
+    severity: "High"
+    description: "Detects usage of the zero hash as a trusted value, which can be dangerous if it's the default state of an uninitialized mapping."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Nomad Bridge (2022)
+
+## Overview
+In August 2022, the Nomad bridge was drained of approximately $190 million in a "decentralized robbery." A routine upgrade accidentally initialized the bridge's trusted root to a zero hash (`0x00`), allowing anyone to bypass message verification by providing a message that hashed to a value already present in the uninitialized mapping.
+
+## Root Cause
+The vulnerability was introduced during a contract upgrade. The `Replica` contract's `confirmAt` mapping was intended to store the time at which a message root was confirmed. The upgrade set the default "trusted" root to `0x00`. Because uninitialized storage in Solidity is `0`, any message with a root of `0x00` was automatically considered "confirmed" by the contract. This allowed users to submit withdrawal messages with arbitrary data that would be executed without valid signatures.
+
+## Attack Flow
+1. Attacker noticed that the `Replica` contract accepted messages with a root of `0x00`.
+2. Attacker crafted a message to withdraw funds from the bridge.
+3. Attacker submitted the message to the `process` function.
+4. The contract checked if the message's root was confirmed. Since the root was `0x00` and the mapping returned `0` (or a value that passed the check), the message was processed.
+5. Once the first attack was public, hundreds of other users (copycats) simply copied the transaction data, changed the recipient address, and drained the remaining funds.
+
+## Impact
+- **Loss**: ~$190M
+- **Protocol**: Nomad Bridge
+- **Chain**: Ethereum / Moonbeam / Evmos / etc.
+- **Date**: 2022-08-01
+
+## Key Transactions
+- First Attack tx: `0xa5ce309047a92177ad43c03f1f13a87339e38c89509cf5564d79775c4456cf92`
+
+## Detection Heuristics
+- Pattern 1: Trusting a zero value (`0x00` or `0`) in a mapping that is also the default state for uninitialized entries.
+- Pattern 2: Lack of explicit checks to ensure that a root or hash is not the zero value before processing sensitive operations.
+
+## Remediation
+- Fix 1: Explicitly initialize trusted roots to a non-zero value or use a separate boolean mapping to track confirmation.
+- Fix 2: Add a `require(root != bytes32(0))` check in the message verification logic.
+- Fix 3: Implement more rigorous testing for contract upgrades, specifically checking the state of critical storage variables.
+
+## References
+- [rekt.news/nomad-rekt/](https://rekt.news/nomad-rekt/)
+- [medium.com/nomad-xyz-blog/nomad-bridge-hack-post-mortem-e6f630cf3b7f](https://medium.com/nomad-xyz-blog/nomad-bridge-hack-post-mortem-e6f630cf3b7f)

package/skills/case-studies/parity-multisig/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: parity-multisig
+description: "Case study of the 2017 Parity Multisig Freeze: delegatecall + self-destruct exploit freezing ~$150M"
+category: reference
+source_url: "https://rekt.news/parity-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'delegatecall\(.*\)'
+    severity: "High"
+    description: "Detects use of delegatecall, which can be dangerous if the target contract is not trusted or can be modified."
+  - regex: 'selfdestruct\(.*\)'
+    severity: "High"
+    description: "Detects use of selfdestruct, which can be used to destroy a contract and freeze funds if not properly protected."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Parity Multisig Freeze (2017)
+
+## Overview
+In November 2017, a user accidentally triggered a vulnerability in the Parity Multisig wallet library contract. By calling an uninitialized `initWallet` function, the user became the owner of the library contract and subsequently called `kill()`, which executed `selfdestruct`. This froze approximately 513,000 ETH (worth ~$150M at the time) across 587 wallets that depended on this library.
+
+## Root Cause
+The Parity Multisig wallets used `delegatecall` to execute logic from a shared library contract. However, the library contract itself was not initialized. This allowed any user to call the `initWallet` function on the library contract directly, making them the owner of the library. Once they were the owner, they could call the `kill` function, which contained a `selfdestruct` instruction.
+
+## Attack Flow
+1. A user (devops199) found the uninitialized library contract.
+2. The user called `initWallet()` on the library contract, becoming its owner.
+3. The user then called `kill()` on the library contract.
+4. The library contract executed `selfdestruct`, removing its code from the blockchain.
+5. All multisig wallets that used `delegatecall` to this library now had no logic to execute, effectively freezing all funds held in them.
+
+## Impact
+- **Loss**: ~$150M (513k ETH)
+- **Protocol**: Parity Multisig
+- **Chain**: Ethereum
+- **Date**: 2017-11-06
+
+## Key Transactions
+- Initialization tx: `0x05f5c113c130f928d4d0d261046c5511846909b77060ef6568bf9158ad312a06`
+- Kill tx: `0x47f7cff3ad8733831a0e273108ef239bb0d0657da3a4279b1d17ac2616a12487`
+
+## Detection Heuristics
+- Pattern 1: Uninitialized library contracts that contain sensitive functions like `selfdestruct` or `init`.
+- Pattern 2: Use of `delegatecall` to a contract that can be destroyed or modified by unauthorized users.
+
+## Remediation
+- Fix 1: Initialize library contracts during deployment or use a constructor to disable initialization functions.
+- Fix 2: Avoid using `selfdestruct` in library contracts.
+- Fix 3: Use static libraries or ensure the target of `delegatecall` is immutable and properly initialized.
+
+## References
+- [rekt.news/parity-rekt/](https://rekt.news/parity-rekt/)
+- [paritytech.io/blog/security-alert-heavy-update/](https://www.parity.io/blog/security-alert-heavy-update/)

package/skills/case-studies/poly-network/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: poly-network
+description: "Case study of the 2021 Poly Network exploit: cross-chain relay manipulation draining ~$600M"
+category: reference
+source_url: "https://rekt.news/polynetwork-rekt/"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: 'putCurEpochConPubKeyBytes'
+    severity: "High"
+    description: "Detects functions that can modify the public keys of cross-chain relayers/keepers."
+---
+<!-- Source: rekt.news (CC0) -->
+<!-- Source: SunWeb3Sec/DeFiHackLabs (Reference) -->
+
+# Poly Network (2021)
+
+## Overview
+In August 2021, Poly Network, a cross-chain interoperability protocol, was exploited for approximately $611 million across Ethereum, Binance Smart Chain, and Polygon. The attacker was able to manipulate the protocol's "keeper" role, allowing them to sign and execute arbitrary cross-chain transactions.
+
+## Root Cause
+The vulnerability was in the `EthCrossChainManager` contract. The contract had a function `crossChain` that could call any contract on the target chain. The attacker used this to call the `EthCrossChainData` contract's `putCurEpochConPubKeyBytes` function. This function was intended to update the public keys of the "keepers" (the entities that sign cross-chain messages). Because the `EthCrossChainManager` was the owner of the `EthCrossChainData` contract, the call was authorized, allowing the attacker to replace the official keeper keys with their own.
+
+## Attack Flow
+1. Attacker crafted a cross-chain message on a source chain (e.g., Ontology).
+2. The message was designed to trigger a call to `putCurEpochConPubKeyBytes` on the target chain (Ethereum/BSC/Polygon).
+3. The `EthCrossChainManager` received the message and, because it was the owner of the data contract, executed the call.
+4. The attacker's public key was now registered as the only valid keeper key.
+5. The attacker then crafted and signed withdrawal transactions for the bridge's assets using their own key.
+6. The bridge accepted these transactions as valid and released the funds.
+
+## Impact
+- **Loss**: ~$611M (Most was later returned by the attacker)
+- **Protocol**: Poly Network
+- **Chain**: Ethereum, BSC, Polygon
+- **Date**: 2021-08-10
+
+## Key Transactions
+- Attack tx (Ethereum): `0xb1f3535b698f3a0917a219673e7c0e1501c35f9bb8a2811b7a781363bd23c228`
+
+## Detection Heuristics
+- Pattern 1: Cross-chain managers that can call arbitrary functions on internal data or configuration contracts.
+- Pattern 2: Lack of strict access control on functions that modify critical system roles (like keepers or validators).
+
+## Remediation
+- Fix 1: Implement a whitelist of allowed functions that can be called via cross-chain messages.
+- Fix 2: Ensure that critical configuration functions (like updating keeper keys) require multi-signature authorization or a time-lock, and cannot be triggered by a single cross-chain call.
+
+## References
+- [rekt.news/polynetwork-rekt/](https://rekt.news/polynetwork-rekt/)
+- [slowmist.medium.com/the-analysis-and-q-a-of-poly-network-hack-8112a353e439](https://slowmist.medium.com/the-analysis-and-q-a-of-poly-network-hack-8112a353e439)