Security Vulnerability Report: HIGH Severity
Component: IncidentManager (upgradeable proxy)
Severity: HIGH
Date: 2026-08-18
Status: Responsible Disclosure
Summary
The IncidentManager contract allows any address holding the CURATOR_ROLE to indefinitely block vault deposits for any active period by creating incidents that remain in OPEN status. There is no time limit for confirming or canceling an incident, and each open incident triggers a deposit block via vault.setActiveIncident(period, true). This creates a griefing vector where a single compromised or malicious curator can cause sustained economic damage by preventing new capital from entering the vault.
Root Cause
In IncidentManager.sol, the createIncident() function is permissioned to CURATOR_ROLE and calls _increaseIncident() which sets a vault-level flag blocking ALL deposits when the first incident for a period is created via vault.setActiveIncident(period, true).
The Problem:
- No timeout on OPEN status - An incident can remain in OPEN status indefinitely
- No rate limiting on incident creation - No limit on how many incidents a curator can create per period
- Deposit blocking is automatic - As soon as _increaseIncident() detects count == 1, ALL vault deposits are blocked
- No rollback mechanism - Economic damage occurs during the blocking period
Attack Scenario
- Attacker compromises a curator account (or malicious curator acts deliberately)
- Calls createIncident() for the current vault period with any valid captureTimestamp
- Incident created in OPEN status, vault deposits immediately blocked
- Attacker takes no further action - incident stays OPEN indefinitely
- All vault deposits remain blocked until another curator cancels the incident or the period expires
Impact
- Economic: Blocked deposits reduce TVL, impacting coverage capacity and revenue
- Reputational: Users unable to deposit may lose confidence
- Griefing cost: ~$1-5 gas for a transaction causing significant economic damage
- Amplification: Multiple incidents across different periods maximize blocking duration
Proof of Concept
Recommendations
Option 1 (Recommended): Time-Limited Open Status
Add a confirmationDeadline to incidents. Auto-cancel OPEN incidents that exceed the deadline.
Option 2: Rate Limiting
Limit the number of open incidents per curator per period.
Option 3: Deposit Block Grace Period
Implement a grace period before deposit blocking takes effect.
This report is submitted in good faith under responsible disclosure principles. Please confirm receipt and let me know if you need additional analysis.
Security Vulnerability Report: HIGH Severity
Component: IncidentManager (upgradeable proxy)
Severity: HIGH
Date: 2026-08-18
Status: Responsible Disclosure
Summary
The IncidentManager contract allows any address holding the CURATOR_ROLE to indefinitely block vault deposits for any active period by creating incidents that remain in OPEN status. There is no time limit for confirming or canceling an incident, and each open incident triggers a deposit block via vault.setActiveIncident(period, true). This creates a griefing vector where a single compromised or malicious curator can cause sustained economic damage by preventing new capital from entering the vault.
Root Cause
In IncidentManager.sol, the createIncident() function is permissioned to CURATOR_ROLE and calls _increaseIncident() which sets a vault-level flag blocking ALL deposits when the first incident for a period is created via vault.setActiveIncident(period, true).
The Problem:
Attack Scenario
Impact
Proof of Concept
Recommendations
Option 1 (Recommended): Time-Limited Open Status
Add a confirmationDeadline to incidents. Auto-cancel OPEN incidents that exceed the deadline.
Option 2: Rate Limiting
Limit the number of open incidents per curator per period.
Option 3: Deposit Block Grace Period
Implement a grace period before deposit blocking takes effect.
This report is submitted in good faith under responsible disclosure principles. Please confirm receipt and let me know if you need additional analysis.