solidity-argus 0.1.8 → 0.3.0

package/skills/vulnerability-patterns/incorrect-inheritance-order/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: incorrect-inheritance-order
-description: - Contract uses multiple inheritance (`is ContractA, ContractB, ...`)
+description: '- Contract uses multiple inheritance (`is ContractA, ContractB, ...`)'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'is\s+\w+\s*,\s*\w+'
+    severity: Informational
+    confidence: Low
+    swc: SWC-125
+    description: Multiple inheritance declaration needing linearization review
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/insufficient-gas-griefing/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: insufficient-gas-griefing
-description: - Contract relays or forwards calls on behalf of users (meta-transactions, multisig execution, relayer patterns)
+description: '- Contract relays or forwards calls on behalf of users (meta-transactions, multisig execution, relayer patterns)'
+pattern_category: dos
+detection_rules:
+  - regex: '\.call\{gas:'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-126
+    description: Caller-controlled gas forwarding can censor relayed execution
+  - regex: 'gasleft\(\)'
+    severity: Low
+    confidence: Low
+    description: Gas accounting logic should be checked for griefing resilience
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/lack-of-precision/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: lack-of-precision
-description: - Contract performs integer arithmetic (division, fee calculations, reward distributions)
+description: '- Contract performs integer arithmetic (division, fee calculations, reward distributions)'
+pattern_category: logic-error
+detection_rules:
+  - regex: '/\s*\d+\s*\*'
+    severity: Low
+    confidence: Low
+    description: Division-before-multiplication pattern that can truncate precision
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/logic-errors/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: logic-errors
 description: Protocol logic bug patterns, exploit examples, and invariant-driven review strategies.
+pattern_category: logic-error
+detection_rules:
+  - regex: 'if\s*\([^)]*&&[^)]*\|\|'
+    severity: Informational
+    confidence: Low
+    description: Mixed boolean operators in one condition warrant logic review
+  - regex: 'require\(.*,\s*"'
+    severity: Informational
+    confidence: Low
+    description: Guard clauses can reveal critical business-logic invariants
 ---
 
 <!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->

package/skills/vulnerability-patterns/missing-parameter-bounds/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: missing-parameter-bounds
+description: "Protocol parameters are accepted without min/max constraints, allowing invalid or unsafe runtime states."
+category: vulnerability-pattern
+pattern_category: logic-error
+source_url: "https://github.com/bailsec/BailSec"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: "function\\s+(set|update|configure|initialize|constructor).*\\{[\\s\\S]{0,400}?(bps|fee|ratio|range|cap|threshold)"
+    severity: "Medium"
+    description: "Configurable economic parameter likely missing explicit bounds"
+  - regex: "require\\(.*<=\\s*(MAX|1e4|10000)"
+    severity: "Low"
+    description: "Use as a companion check to find setters lacking equivalent guardrails"
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# Missing Parameter Bounds Vulnerabilities
+
+## Overview
+Missing parameter bounds is a recurring configuration-class vulnerability where contracts accept values that violate economic assumptions, arithmetic safety, or protocol UX constraints. Typical examples include BPS percentages above 100%, negative-style behavior encoded in signed ranges, or credit and share thresholds that can be bypassed in one path but enforced in another. The issue is often not immediate code execution risk, but delayed protocol failure, broken accounting, or user-loss scenarios after governance changes.
+
+A high-risk variant is validation drift: constructor and setter logic differ, so initial deployment can inject invalid values that runtime mutation would reject (or vice versa). This creates non-obvious states auditors miss when they only inspect one code path.
+
+## Common Patterns
+- Constructor omits upper bound checks that exist in a later setter.
+- Setter enforces one invariant but related functions do not re-check post-action states.
+- Signed range parameters increase complexity and permit invalid semantics.
+- Optional token interfaces or assumptions are accepted without compatibility gating.
+
+## Detection Heuristics
+- Build a matrix of each mutable parameter: constructor checks, setter checks, and all usage-site assumptions.
+- Flag any economic parameter lacking explicit min/max and unit documentation.
+- Compare pre-state vs post-state constraints on mutating flows (supply/withdraw/rebalance).
+- Review all checks for consistency in BPS, decimals, and scaling conventions.
+
+## Examples from Audits
+- Bridge bonus percentage accepted in initialization without enforcing BPS cap, allowing values above 10,000.
+- Fee parameter validated in setter but not in constructor, enabling out-of-range deployment state.
+- Credit and liquidity-related validation logic that was difficult to reason about and left bypass opportunities in adjacent paths.
+
+## Remediation
+Define parameter invariants once and reuse them through internal validator functions called by constructor, initializer, setters, and upgrade hooks. Prefer explicit constants (`MIN_*`, `MAX_*`) with unit comments. For safety-critical parameters, add two-step governance updates plus simulation checks before activation. Back this with property tests that fuzz all bounded values and assert protocol invariants remain true after each update. This makes future maintenance safer and prevents silent drift between code paths.

package/skills/vulnerability-patterns/missing-protection-signature-replay/SKILL.md

@@ -1,6 +1,22 @@
 ---
 name: missing-protection-signature-replay
-description: - Contract verifies ECDSA signatures for authorization
+description: '- Contract verifies ECDSA signatures for authorization'
+pattern_category: signature
+detection_rules:
+  - regex: 'ecrecover\('
+    severity: Medium
+    confidence: High
+    swc: SWC-121
+    description: Signature recovery path requires nonce, chain, and domain separation checks
+  - regex: 'ECDSA\.recover\('
+    severity: Medium
+    confidence: High
+    swc: SWC-121
+    description: Library-based signature recovery still needs replay protection fields
+  - regex: 'permit\(|signTypedData'
+    severity: High
+    confidence: Medium
+    description: Permit or typed data signing — missing nonce allows signature replay
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/msgvalue-loop/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: msgvalue-loop
-description: - `msg.value` is referenced inside a loop (`for`, `while`) or in a function called multiple times within a single external call
+description: '- `msg.value` is referenced inside a loop (`for`, `while`) or in a function called multiple times within a single external call'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'msg\.value'
+    severity: Low
+    confidence: Low
+    swc: SWC-134
+    description: msg.value usage that may be reused across loop iterations
+  - regex: '(for|while)\s*\('
+    severity: Informational
+    confidence: Low
+    description: Loop context signal for msg.value reuse review
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/off-by-one/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: off-by-one
-description: - Contract uses loops with boundary conditions, comparison operators at thresholds, or array index calculations
+description: '- Contract uses loops with boundary conditions, comparison operators at thresholds, or array index calculations'
+pattern_category: logic-error
+detection_rules:
+  - regex: '\.length\s*-\s*1'
+    severity: Low
+    confidence: Low
+    description: Boundary arithmetic near array length that can hide fence-post mistakes
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/oracle-manipulation/SKILL.md

@@ -1,6 +1,28 @@
 ---
 name: oracle-manipulation
 description: Oracle manipulation techniques, case studies, and secure pricing integration controls for DeFi.
+pattern_category: oracle-manipulation
+source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
+source_license: MIT
+imported_at: "2025-01-15T00:00:00Z"
+detection_rules:
+  - regex: 'latestRoundData'
+    severity: Medium
+    confidence: High
+    swc: SWC-116
+    description: Chainlink price reads requiring freshness and sanity checks
+  - regex: 'getReserves\('
+    severity: High
+    confidence: High
+    description: AMM reserve spot-price usage vulnerable to manipulation
+  - regex: 'observe\(|consult\('
+    severity: Medium
+    confidence: Medium
+    description: TWAP oracle usage — time-weighted average prices can be manipulated via sustained trading pressure
+  - regex: 'priceFeed|oracle.*decimals'
+    severity: Medium
+    confidence: Medium
+    description: Oracle price feed with decimal handling — potential decimal mismatch between oracle and token
 ---
 
 <!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->

package/skills/vulnerability-patterns/outdated-compiler-version/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: outdated-compiler-version
-description: - Contract is compiled with a Solidity version significantly behind the latest stable release
+description: '- Contract is compiled with a Solidity version significantly behind the latest stable release'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'pragma solidity 0\.[0-7]\.'
+    severity: Informational
+    confidence: High
+    swc: SWC-102
+    description: Solidity pragma pins to an outdated major/minor compiler line
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/overflow-underflow/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: overflow-underflow
-description: - Solidity <0.8.0 without SafeMath, OR
+description: Integer overflow and underflow vulnerabilities in Solidity contracts
+pattern_category: logic-error
+source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
+source_license: MIT
+imported_at: "2025-01-15T00:00:00Z"
+detection_rules:
+  - regex: 'unchecked\s*\{'
+    severity: Medium
+    confidence: High
+    swc: SWC-101
+    description: Unchecked arithmetic block requiring manual overflow review
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/proxy-vulnerabilities/SKILL.md

@@ -0,0 +1,209 @@
+---
+name: proxy-vulnerabilities
+description: Proxy pattern vulnerabilities including storage collision, uninitialized proxy, and function selector clash
+category: vulnerability-pattern
+pattern_category: proxy
+detection_rules:
+  - regex: 'delegatecall|IMPLEMENTATION_SLOT'
+    severity: Critical
+    confidence: Medium
+    swc: SWC-112
+    description: Delegatecall or implementation slot usage - potential storage collision between proxy and implementation contracts if storage layouts diverge
+  - regex: '_disableInitializers|initializer'
+    severity: High
+    confidence: Medium
+    description: Proxy initialization pattern detected - verify implementation contract calls _disableInitializers() in constructor and proxy calls initialize()
+  - regex: 'fallback\(\)|receive\(\).*delegatecall'
+    severity: Medium
+    confidence: Low
+    description: Fallback or receive function with delegatecall - risk of function selector clash between proxy admin functions and implementation functions
+---
+
+# Proxy Vulnerability Patterns
+
+## Overview
+
+Upgradeable proxy systems trade immutability for maintainability. That trade introduces a second security model: execution context and storage live in the proxy, while logic lives in implementations reached through `delegatecall`. Any mismatch between expected and actual layout, initialization state, or function routing can grant attackers full control.
+
+Most proxy exploits are not complex cryptographic breaks. They are integration failures across deployment scripts, upgrade procedures, and ABI boundaries. A proxy setup can be technically standards-compliant and still vulnerable if governance, initialization, or selector design is weak.
+
+Auditing proxies requires system-level reasoning across deployment transactions, upgrade authority, storage layout evolution, and fallback behavior. Reviewing only implementation code misses critical attack surface in proxy shell contracts and admin operations.
+
+## Key Attack Vectors
+
+- Storage collision between proxy slots and implementation variables.
+- Uninitialized implementation contracts that an attacker can initialize directly.
+- Uninitialized proxies where initializer can be called by arbitrary users.
+- Selector clashes between admin functions and delegated user functions.
+- Unsafe fallback routing that forwards admin calls into implementation logic.
+- Upgrade functions lacking role checks, timelocks, or upgrade validation.
+- Incompatible storage layout changes during upgrades.
+- Missing rollback testing for UUPS upgrades.
+- Delegatecall to untrusted implementation addresses.
+
+### Typical Takeover Sequence (Uninitialized Proxy)
+
+1. Proxy is deployed without atomic initialization.
+2. Initializer remains externally callable.
+3. Attacker calls `initialize()` first and becomes owner/admin.
+4. Attacker upgrades implementation or drains managed assets.
+5. Team loses control of proxy governance path.
+
+### Typical Storage Collision Sequence
+
+1. New implementation reorders or inserts state variables incorrectly.
+2. Critical admin/value fields map to unexpected slots.
+3. Routine function calls mutate sensitive proxy state.
+4. Access control breaks or funds accounting corrupts.
+5. Recovery requires emergency upgrade or migration.
+
+## Detection Heuristics
+
+### Proxy Primitive Identification
+
+- Detect `delegatecall`, `fallback`, `receive`, and implementation slot constants.
+- Identify whether system is Transparent, UUPS, Beacon, or custom hybrid.
+- Enumerate upgrade entry points and admin authority graph.
+- Verify proxy and implementation compile with compatible storage assumptions.
+
+### Initialization Safety Checks
+
+- Confirm implementation constructor calls `_disableInitializers()`.
+- Ensure proxy initialization happens in deployment transaction.
+- Verify initializer functions are single-use and role-gated where required.
+- Check reinitializer versioning for upgrade modules.
+
+### Storage Layout Safety Checks
+
+- Compare storage layout before and after upgrade.
+- Ensure inherited contracts preserve variable ordering.
+- Validate use of storage gaps (`uint256[50] private __gap`) where applicable.
+- Confirm EIP-1967 slots are used for implementation/admin/beacon pointers.
+
+### Selector Clash and Routing Checks
+
+- Enumerate proxy admin selectors and implementation public selectors.
+- Detect collisions where admin and user paths share selectors.
+- Ensure Transparent proxy blocks admin from falling through to implementation.
+- For UUPS, verify `proxiableUUID` and upgrade authorization checks.
+
+### Concrete Code Smells
+
+```solidity
+fallback() external payable {
+    (bool ok,) = implementation.delegatecall(msg.data);
+    require(ok);
+}
+```
+
+```solidity
+function initialize(address owner_) external initializer {
+    owner = owner_; // callable by first caller if not atomically initialized
+}
+```
+
+```solidity
+bytes32 internal constant IMPLEMENTATION_SLOT =
+    keccak256("implementation"); // non-standard slot risks conflicts
+```
+
+### Audit Checklist
+
+- Is every proxy deployed with initialization calldata in the same transaction?
+- Are implementation contracts permanently non-initializable post-deploy?
+- Are storage layout diffs reviewed and enforced in CI before upgrade?
+- Are upgrade operations timelocked, multisig-gated, and event-rich?
+- Are selector collisions tested against full ABI surface?
+
+## Prevention
+
+### Use Battle-Tested Standards
+
+- Prefer OpenZeppelin TransparentUpgradeableProxy or ERC1967/UUPS implementations.
+- Use EIP-1967 storage slots and audited upgrade libraries.
+- Avoid custom proxy shells unless necessary for protocol-specific requirements.
+- Keep proxy logic minimal and immutable where possible.
+
+### Initialization Hardening
+
+- Call `_disableInitializers()` in implementation constructor.
+- Supply initializer calldata during proxy deployment.
+- Restrict or remove external initializer exposure after setup.
+- Document and test upgrade-time reinitializer sequences.
+
+### Upgrade Governance Controls
+
+- Gate upgrades behind multisig + timelock.
+- Require explicit implementation validation (`code.length > 0`, interface checks).
+- Emit events for proposed and executed upgrades.
+- Maintain emergency pause/rollback procedures with clear authority boundaries.
+
+### Selector and Routing Safety
+
+- For Transparent proxies, separate admin and user call paths strictly.
+- For UUPS proxies, enforce `_authorizeUpgrade` with robust roles.
+- Run selector collision scans in CI against proxy and implementation ABIs.
+- Avoid exposing overlapping administrative selectors in implementations.
+
+### Hardened Pattern Example
+
+```solidity
+contract Impl is Initializable, UUPSUpgradeable, OwnableUpgradeable {
+    constructor() {
+        _disableInitializers();
+    }
+
+    function initialize(address owner_) external initializer {
+        __Ownable_init(owner_);
+    }
+
+    function _authorizeUpgrade(address newImplementation)
+        internal
+        override
+        onlyOwner
+    {}
+}
+```
+
+### Operational Practices
+
+- Store upgrade runbooks with preflight and postflight checks.
+- Simulate upgrades on forked state before production execution.
+- Track implementation bytecode hashes and signed release artifacts.
+- Include automated storage-layout regression gates in release pipelines.
+
+## Real-World Examples
+
+### Proxy Initialization Incidents
+
+- Pattern: implementation or proxy left uninitialized.
+- Impact: attacker claims ownership role and controls upgrade path.
+- Lesson: initialization must be atomic, single-use, and scripted.
+
+### Storage Layout Corruption Cases
+
+- Pattern: variable order/type changes between implementation versions.
+- Impact: admin slots and balances are overwritten unintentionally.
+- Lesson: treat storage layout as immutable contract between versions.
+
+### Selector Clash Risk in Custom Proxies
+
+- Pattern: fallback delegatecalls overlap with proxy admin selectors.
+- Impact: privileged calls routed incorrectly or user calls blocked.
+- Lesson: transparent separation and selector audits are mandatory.
+
+### Pattern-to-Impact Mapping
+
+- `storage-collision` -> critical state corruption and privilege compromise.
+- `uninitialized-proxy` -> hostile initialization and upgrade takeover.
+- `selector-clash` -> call-path confusion and admin bypass risk.
+
+## References
+
+- SWC-112 (Delegatecall to untrusted callee): https://swcregistry.io/docs/SWC-112
+- OpenZeppelin Upgrades docs: https://docs.openzeppelin.com/upgrades-plugins/1.x/
+- OpenZeppelin proxy patterns: https://docs.openzeppelin.com/contracts/4.x/api/proxy
+- EIP-1967 proxy storage slots: https://eips.ethereum.org/EIPS/eip-1967
+- EIP-1822 (UUPS): https://eips.ethereum.org/EIPS/eip-1822
+- ConsenSys best practices for upgradeability: https://consensys.github.io/smart-contract-best-practices/
+- Trail of Bits proxy audit notes: https://blog.trailofbits.com/

package/skills/vulnerability-patterns/reentrancy/SKILL.md

@@ -1,6 +1,28 @@
 ---
 name: reentrancy
 description: Reentrancy attack patterns, real incidents, and defensive coding checks for Solidity protocols.
+pattern_category: reentrancy
+source_url: https://github.com/kadenzipfel/smart-contract-vulnerabilities
+source_license: MIT
+imported_at: "2025-01-15T00:00:00Z"
+detection_rules:
+  - regex: '\.call\{value:'
+    severity: High
+    confidence: High
+    swc: SWC-107
+    description: External value transfer via low-level call before effects
+  - regex: '\.call\{.*\}\('
+    severity: Medium
+    confidence: Medium
+    description: Low-level external call that can open a reentrancy window
+  - regex: '\.(transfer|transferFrom)\('
+    severity: Medium
+    confidence: Medium
+    description: ERC-20 token transfer that may precede state changes — reentrancy via token callback hooks (ERC-777, ERC-1155)
+  - regex: '(external|public)\s.*\{[^}]*\.call'
+    severity: High
+    confidence: Low
+    description: Public/external function with low-level call — potential cross-function reentrancy if shared state is read by other functions
 ---
 
 <!-- Source: DeFiFoFum/fofum-solidity-skills (MIT) -->

package/skills/vulnerability-patterns/shadowing-state-variables/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: shadowing-state-variables
-description: - Contract inherits from one or more parent contracts
+description: '- Contract inherits from one or more parent contracts'
+pattern_category: logic-error
+detection_rules:
+  - regex: 'override\b'
+    severity: Informational
+    confidence: Low
+    swc: SWC-119
+    description: Override-heavy inheritance context worth shadowing review
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/share-accounting-desynchronization/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: share-accounting-desynchronization
+description: "Asset/share systems drift out of sync across views, transfers, or reward logic, enabling value leakage, bypasses, or protocol lockups."
+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: "(sharesToToken|tokenToShares|previewWrap|previewUnwrap|accRewardPerShare|totalShares|totalSupply)"
+    severity: "High"
+    description: "Share conversion and accumulator surfaces prone to state drift"
+  - regex: "(round|mulDiv|division by zero|overflow|underflow)"
+    severity: "Medium"
+    description: "Numerical conditions that amplify desynchronization impact"
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# Share Accounting Desynchronization Vulnerabilities
+
+## Overview
+Share-accounting desynchronization appears when a protocol tracks ownership in shares but exposes user actions, approvals, rewards, or integrations in asset-denominated values without guaranteed synchronization. If share supply, token supply, and fee accrual are updated at different times or with inconsistent caps, attackers and edge cases can exploit the mismatch to bypass approvals, drain value, lock funds, or break reward accounting.
+
+Unlike a single arithmetic bug, this is a system-level failure of consistency across view logic, state updates, and transfer semantics.
+
+## Common Patterns
+- Approval consumption and transfer amount are evaluated in different units.
+- View functions use theoretical future supply while state-changing paths use capped or delayed supply updates.
+- Reward accumulators assume minted fees that are not actually minted.
+- Rounding strategy differs across conversion helpers, causing exploitable drift in repeated operations.
+
+## Detection Heuristics
+- Map all conversions between shares and assets, then verify consistent rounding direction by context.
+- Compare view-only paths (`pending`, `preview`, `realBalance`) against state-changing mint/burn/update behavior.
+- Check behavior when fee collector address changes, updates are delayed, or supply caps are hit.
+- Fuzz with long periods of inactivity, then sudden updates to detect discontinuities.
+
+## Examples from Audits
+- Share transfer path that could bypass token-amount approval checks under specific conversion outcomes.
+- Reward preview functions allocating value from uncapped or unminted fees, creating inconsistent accumulator states.
+- Systems where stale supply updates or abrupt fee-recipient changes altered debase/reward behavior and destabilized accounting.
+
+## Remediation
+Adopt a single canonical accounting model and centralize conversions in audited helper functions with documented rounding policy. Enforce that view and state paths share the same cap logic and fee-mint assumptions. Add invariant tests ensuring `assets <-> shares` coherence under updates, pauses, and collector changes. When conversions can become stale, force synchronization before sensitive operations or require bounded slippage from callers. This reduces drift accumulation and makes behavior predictable for integrations.

package/skills/vulnerability-patterns/signature-malleability/SKILL.md

@@ -1,6 +1,16 @@
 ---
 name: signature-malleability
-description: - Contract uses ECDSA signatures for authorization or deduplication
+description: "Contract uses ECDSA signatures for authorization or deduplication"
+pattern_category: signature
+detection_rules:
+  - regex: 'ecrecover'
+    severity: Medium
+    confidence: High
+    description: Raw ecrecover usage needs strict signature normalization checks
+  - regex: 'ECDSA'
+    severity: Low
+    confidence: Medium
+    description: Signature verification path to inspect for nonce and domain separation
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/stateful-parameter-update-drift/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: stateful-parameter-update-drift
+description: "Changing live protocol parameters without synchronizing accrued state creates hindsight effects, unfair allocations, or broken invariants."
+category: vulnerability-pattern
+pattern_category: logic-error
+source_url: "https://github.com/bailsec/BailSec"
+source_license: "CC0"
+imported_at: "2025-02-20T00:00:00Z"
+detection_rules:
+  - regex: "set[A-Z][A-Za-z0-9_]*\\(.*\\)"
+    severity: "Medium"
+    description: "State-changing parameter setter that may require pre-update synchronization"
+  - regex: "(lastUpdate|pending|accrued|epoch|index|reward|supply).*(set|change|update)"
+    severity: "High"
+    description: "Potential hindsight impact when mutable parameters affect accrued accounting"
+---
+<!-- Source: BailSec audit reports (CC0) -->
+
+# Stateful Parameter Update Drift Vulnerabilities
+
+## Overview
+Protocols with time-based accrual (fees, rebases, emissions, yield drips) often expose governance or admin setters that modify core parameters while accrual windows are still open. If the contract does not settle or checkpoint state before applying the new value, the update retroactively changes historical accounting. This creates hindsight effects: users can gain or lose value for periods that should already be fixed.
+
+The vulnerability is not just governance centralization. Even trusted governance can unintentionally trigger unfair redistribution or lockups when parameter updates are applied to stale state.
+
+## Common Patterns
+- Mutable fee collector or tax parameter changed without first syncing pending accrual.
+- Unstake tax, reward rate, or epoch frequency updates affecting already elapsed time.
+- Toggle-style parameters (`address(0)` sentinel, pause/unpause) that alter future and past calculations simultaneously.
+- Setter functions that bypass the same accounting hooks used by normal user actions.
+
+## Detection Heuristics
+- For each admin setter, identify all variables that depend on elapsed time since last update.
+- Verify setters call the same `_update*`, `_accrue*`, or checkpoint routines as user-facing flows.
+- Test state transitions with long inactivity windows and then a single governance change.
+- Check whether parameter changes can reorder who receives already-accrued rewards.
+
+## Examples from Audits
+- Fee-collector changes that prevented expected debasing in hindsight or triggered abrupt catch-up effects.
+- Tax parameter updates that applied to previously elapsed yield windows, redistributing value unexpectedly.
+- Configuration changes that could move protocol behavior into disruptive states immediately after activation.
+
+## Remediation
+Require a deterministic pre-update checkpoint in every setter that influences accrual math. Apply parameter changes only after accrued state is finalized to the current timestamp or epoch boundary. Where governance changes are sensitive, add delay and staged execution with explicit before/after snapshots. Include invariant tests asserting that total distributable value is conserved across parameter changes and that historical periods are not recomputed with new settings.

package/skills/vulnerability-patterns/unbounded-return-data/SKILL.md

@@ -1,6 +1,17 @@
 ---
 name: unbounded-return-data
-description: - Contract makes a low-level `.call()` to an untrusted or user-specified address
+description: '- Contract makes a low-level `.call()` to an untrusted or user-specified address'
+pattern_category: dos
+detection_rules:
+  - regex: '\.call\(.*\)'
+    severity: Low
+    confidence: Low
+    swc: SWC-110
+    description: Low-level call paths may copy attacker-controlled return data
+  - regex: 'returndatasize'
+    severity: Medium
+    confidence: Medium
+    description: Return-data handling path that warrants bounded-copy checks
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unchecked-return-values/SKILL.md

@@ -1,6 +1,18 @@
 ---
 name: unchecked-return-values
-description: - Contract uses low-level calls: `.call()`, `.send()`, or `.delegatecall()`
+description: "Contract uses low-level calls: .call(), .send(), or .delegatecall()"
+pattern_category: logic-error
+detection_rules:
+  - regex: '\.call\{'
+    severity: Medium
+    confidence: Medium
+    swc: SWC-104
+    description: Low-level call usage requires explicit success handling
+  - regex: '\.send\('
+    severity: Medium
+    confidence: High
+    swc: SWC-104
+    description: send return value can fail silently if unchecked
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->
 

package/skills/vulnerability-patterns/unencrypted-private-data-on-chain/SKILL.md

@@ -1,6 +1,13 @@
 ---
 name: unencrypted-private-data-on-chain
-description: - Sensitive data (passwords, secrets, private keys, game answers) is stored in contract storage
+description: '- Sensitive data (passwords, secrets, private keys, game answers) is stored in contract storage'
+pattern_category: logic-error
+detection_rules:
+  - regex: '(private|internal)\s+(uint|address|bytes|string)\s+\w*(secret|password|key|pin|seed)\w*'
+    severity: Medium
+    confidence: Low
+    swc: SWC-136
+    description: Sensitive identifier names stored in contract state
 ---
 <!-- Source: kadenzipfel/smart-contract-vulnerabilities (MIT) -->