Post-mortem: NOR (Curated Module) / SDVT “Recovery-lever” weakness

1

Post-mortem: NOR (Curated Module) / SDVT “Recovery-lever” weakness
Impact Severity: Low

  • Impact
    A legacy Aragon function (transferToVault(), a recoverability feature in Aragon app templates allowing a user to recover tokens from an Aragon-based app) could redirect undistributed node-operator rewards (the protocol-fee portion) from the NodeOperatorsRegistry (Curated Module and SDVT implementation) contracts to the DAO Agent. The potential transfer is reversible and only adds operational overhead to undo the altered fee distribution outcome; staker funds and operator rewards were never at risk; the only possible impact could be delayed receipt of daily rewards by the latter.

    A sweep of on-chain history shows the function has never been called on any affected module.

  • Fixes (both applied & audited)

    1. Off-chain. Oracle transactions are now submitted as private mempool bundles, removing the front-running window (see the Composable Security security consultation report on the updated oracle version 5.2).
    2. On-chain. A set of vote items (#51-53) in on-chain vote #189 removed the unused lever via governance by nullifying the recovery app id, effectively disabling the recoverability feature for all of the Aragon-based apps deployed for the Lido protocol. Statemind reviewed this change during Dual Governance vote preparation (see Statemind’s report).

  • Acknowledgement
    Lido contributors thank Dmitry Zakharov (CTO of MixBytes, engaged through the GRAPPA initiative), for his responsible disclosure of the weakness. In addition to this, a huge thanks to the Composable Security and Statemind teams for their rapid reviews, and Lido Oracle committee for their collaborative effort promtply reviewing and deploying the fix.

  • Lessons learned
    When inheriting from external frameworks such as Aragon, the on-chain development action checklist now includes:

    1. Review every inherited function in the base contract more thoroughly for follow-on effects. In this case serious risk had already been mitigated by definition of a DAO-controlled recovery address, but when the rebase and rewards process was enhanced previously by splitting it into phases, the possible interaction with this method had been missed.
    2. Re-check any code path that can move tokens and ether, even indirectly, whenever auxiliary flows (rebasing, reward splitting, etc.) evolve.

  • Key dates

    • 12 June 2025: Initial disclosure by @DZahar0v, Immunefi self-report
    • 13 June 2025: Mitigation plan aligned within the Lido contributors group
    • 25 June 2025: Off-chain fix was audited by Composable Security & deployed
    • 30 June 2025: On-chain patch deployed as a part of the DG vote #189 enactment, which was confirmed by the on-chain alerting system

The weakness is now fully neutralized with no user impact, and Lido contributors’ playbook for integrating third-party frameworks has been tightened accordingly.

17 Likes