Full Report
EigenLayer introduces restaking on Ethereum. This allows staked assets to secure other applications, known as Actively Validated Services (AVS) rather than just Ethereum. EigenLayer runs alongside Ethereum, so its implementation is highly security-sensitive. The EigenLayer sidecar is an off-chain worker supporting the main logic in the smart contracts. It listens for on-chain events, processes the data and performs computations on it, such as Rewards. AVSs submit reward details on the chain to the RewardsCoordinator.sol contract, where the sidecar process processes the amount and duration information. The Solidity contract attempts to do input validation on the duration: it must be a divisor of CALCULATION_INTERVAL_SECONDS. This is checked by doing duration % CALCULATION_INTERVAL_SECONDS == 0. Technically, zero satisfies this requirement. Within the off-chain codebase, there is a SQL query that performs division. This leads to a divide-by-zero error in the database. They found this issue by first seeing the division within the SQL query (sink) and tracing it all the way back to the source. I typically don't trace divide by zero bugs this way so that was interesting to see. The impact is slightly dubious to me. A crash or exit doesn't necessarily mean a Denial of Service in all cases. Error handling and continuation need to be taken into consideration. In this case, since the SQL query failed, all AVS operators' sidecar operations for reward calculations would be halted. A good bug and an interesting trace!
Analysis Summary
# Vulnerability: Critical Division-by-Zero in EigenLayer Sidecar Reward Calculation
## CVE Details
- CVE ID: Not assigned at the time of the report.
- CVSS Score: Not assigned at the time of the report (Impact suggests High/Critical based on DoS potential).
- CWE: CWE-369: Improper Check for Zero (Leading to Division by Zero)
## Affected Systems
- Products: EigenLayer Sidecar (off-chain worker) and EigenLayer Smart Contracts (`RewardsCoordinator.sol`).
- Versions: Previous versions of the EigenLayer Sidecar and `RewardsCoordinator.sol` prior to the implemented fixes.
- Configurations: Any configuration where AVSs submit reward details to `RewardsCoordinator.sol` and the sidecar processes these state changes via SQL database operations.
## Vulnerability Description
The vulnerability stems from the EigenLayer sidecar accepting a reward `duration` parameter that was mathematically valid against the on-chain input validation but resulted in a divide-by-zero error in the off-chain processing layer.
1. **On-chain Validation Failure:** The `RewardsCoordinator.sol` contract validated that `duration % CALCULATION_INTERVAL_SECONDS == 0`. This check incorrectly permitted a `duration` of zero (`0 % N == 0`), allowing a zero value to be emitted in events.
2. **Off-chain Ingestion:** The EigenLayer sidecar, listening to these events, parsed the `duration` directly without explicitly checking if it was greater than zero. The sidecar's PostgreSQL database schema allowed `duration` to be stored as `0`.
3. **Code Execution Sink:** Later stages of the sidecar's reward calculation involved constructing SQL queries that performed division using this stored `duration` (e.g., calculating tokens per day via `amount / (duration / 86400)`). When `duration` was zero, the query execution resulted in a database *divide-by-zero error*.
## Exploitation
- Status: **Fixed before exploitation**. The issue was discovered during security review.
- Complexity: Low (If an attacker could reliably submit a zero-duration reward, the crash is deterministic).
- Attack Vector: Network (via submitting a malformed or zero-duration reward event from an AVS).
## Impact
- Confidentiality: No direct impact identified.
- Integrity: Potential integrity impact if the failure halts transactional data processing, though the primary impact is Availability.
- Availability: **High**. A division-by-zero error in the SQL query causes the associated sidecar process stream (responsible for reward calculations) to crash or halt. This results in a Denial of Service (DoS) for all AVS operators dependent on that sidecar instance for reward distribution processing, blocking reward attribution until manual intervention.
## Remediation
### Patches
1. **Smart Contract Fix (On-chain):** `RewardsCoordinator.sol` was patched to enforce an explicit check: `require(duration > 0, ...)` in addition to the modulo check. (Referenced PR: eigenlayer-contracts PR #1216).
2. **Sidecar Fix (Off-chain):** The sidecar logic was updated to explicitly filter out and ignore submissions where `duration = 0` before they are written to the database, ensuring the vulnerable SQL queries never receive zero input. (Referenced PRs: sidecar PRs #266, #275).
### Workarounds
- Immediately stopping the ingestion or pausing functionalities related to reward submissions that could trigger the zero-duration path, if the patch deployment was in progress. (Not explicitly stated as a workaround, but implied by the fix strategy).
## Detection
- **Indicators of Compromise:** Database error logs showing SQL exceptions indicative of division by zero occurring during rewarded processing steps within the sidecar service. Sidecar monitoring showing a persistent halt or persistent crash loop in processes managing reward calculations (e.g., impacting modules like `1_goldActiveRewards.go`, `7_goldActiveODRewards.go`).
- **Detection methods and tools:** Monitoring the operational health of the EigenLayer sidecar process and inspecting database logs for SQL runtime errors related to arithmetic operations on reward duration fields.
## References
- Vendor Advisory/Source: Sigma Prime Blog post detailing the discovery and fix.
- Relevant links:
- hxxps://blog.sigmaprime.io/eigenlayer-sidecar-division-by-zero-fix.html