TL;DR
Three low-to-moderate severity weaknesses were identified and reported through Lido’s Immunefi bug bounty program during the first three weeks of March 2026. None were exploited, no user funds were or are at risk, and all three are being addressed through corrective on-chain actions planned for the upcoming Aragon omnibus vote. Rather than publishing three separate disclosures, we are disclosing them together to provide a unified view of what was found, how the team responded, and what systemic changes are underway to stay ahead of evolving security tooling rather than fragmenting the discussion across three near-duplicate posts.
Context: Lido Bug Bounty Program
Lido maintains one of the longest-running (almost 5 years so far) and most comprehensive bug bounty programs in DeFi through Immunefi, with rewards up to $2M for critical findings. The program covers all core protocol smart contracts, staking modules, bridges, governance components, and main off-chain apps. This quarter, the program demonstrated its value by surfacing three distinct weaknesses from independent whitehats, all of which were confirmed, triaged, and mitigated within hours of escalation.
Weakness 1 — wstETH on zkSync claimFailedDeposit refund-path token binding
Essence.
The claimFailedDeposit() method on the wstETH on zkSync L1 bridge endpoint contract did not validate the caller-supplied _l1Token argument against the token originally deposited. While deposits are restricted to wstETH via the onlySupportedL1Token modifier, the refund path stored only the deposit amount — not the token address. This meant a third party could potentially “consume” a failed-deposit refund record by supplying an arbitrary ERC-20 address, causing the bridge endpoint contract to transfer that token to the depositor while deleting the legitimate refund claim. The depositor’s actual wstETH would remain locked in the bridge with no on-chain recovery path.
Potential impact.
A griefing behavior (non-profitable to the potential attacker) could prevent a depositor from reclaiming wstETH after a failed L1→L2 deposit. The weakness affects only the refund path for deposits that have provably failed on L2 — an edge case with very limited practical exposure.
Mitigations already in place.
Bridge deposit activity was very limited:
- ~33.66 wstETH deposited over the prior 30 days, with no deposits in the last 7 days.
- Since deployment, only a single transaction involving 0.001 wstETH had failed and remained unclaimed.
- Lido contributors confirmed the weakness was never exploited via on-chain analysis (using Dune queries).
- The sole outstanding failed deposit was proactively claimed by the team before deposits were paused see
Status of exploitation.
Never exploited. Deposits on the wstETH on zkSync L1 bridge were paused on March 3 as a precautionary measure. Withdrawals and token transfers remain fully operational.
Planned corrective on-chain action.
A smart contract upgrade to the L1 bridge will enforce that only wstETH (the supported l1Token) can be used in claimFailedDeposit(), eliminating the token mismatch entirely. This upgrade is planned for the upcoming omnibus vote, after which deposits will be re-enabled.
Weakness 2 — Easy Track ExitRequest factory validation
Essence.
The CuratedSubmitExitRequestHashes EasyTrack factory validates that a motion creator holds the reward address for a given node operator of the curated set, and that the supplied validator public key matches a key at a given registry index. However, it does not verify that the referenced key was actually deposited/used by that operator. Since an active curated node operator can potentially append arbitrary public keys under their own registry entry via addSigningKeys, a misbehaving operator could potentially reference a foreign validator’s public key, pass the factory’s validation, and create an EasyTrack motion to submit exit request hashes for validators belonging to a different operator.
Potential impact.
A misbehaving curated node operator (one of 37 vetted, publicly known entities approved by DAO governance) could potentially create an ET motion to request the forced exit for other operators’ validators. This cannot lead to theft of funds — withdrawal credentials remain under Lido protocol control — but could cause temporary reduction in validation activity and rewards. Crucially, even if such an ET motion were to be created, a successful exploitation of this vulnerability would also require the motion surviving a 72-hour objection window during which any suspicious motion is publicly visible and can be blocked.
Mitigations in place.
- The attacker must be an active curated node operator — a privileged, governance-vetted role.
- All EasyTrack motions are publicly visible for 72 hours before enactment, monitored by both the development team and DAO participants.
- Duplicate key uploads are actively monitored by operational tooling.
- Easy Track,
ValidatorExitBus, andTriggerableWithdrawalsGatewaycan all be paused as reactive measures. - SimpleDVT Module Committee is aware of the finding for possible exit considerations through the same factory used for SimpleDVT and maintained by the committee
- The Community Staking Module (CSM) exit-initiating mechanism already validates key ownership and is not affected.
Status of exploitation.
Never exploited. Additionally, we believe that existing protocol monitoring and incident response playbooks would have made possible successful exploitation very unlikely.
Planned corrective on-chain action.
The affected EasyTrack factory will be replaced with a hardened one in the upcoming Aragon omnibus vote. The fix will enforce the used flag check of getSigningKey — ensuring that only deposited keys can be referenced in exit request motions. An updated factory will be deployed once the fix is audited.
Weakness 3 — VaultHub partial-withdrawal / full-exit interaction
Essence.
VaultHub.triggerValidatorWithdrawals() includes a guard designed to prevent unhealthy vault owners from front-running forced validator exits with partial withdrawals. The guard validates that the requested partial withdrawal amount covers the vault’s obligation shortfall. As stVault validators using 0x02 compounding withdrawal credentials, the Ethereum Consensus Layer under Electra caps the actually processed partial withdrawal to the validator’s true excess above MIN_ACTIVATION_BALANCE. This means VaultHub validates the altered quantity: it checks what the user asked for, not what the CL can actually process. A vault owner could request a large partial withdrawal that VaultHub accepts, but which the CL trims to a negligible amount (e.g. 1 gwei), leaving the vault unhealthy and interfering with the forced rebalancing flow.
Potential impact.
A griefing scenario (non-profitable) exists, whereby an owner of an unhealthy vault delays forced validator exits required for rebalancing. The effect is temporary and reversible — funds remain on the Beacon Chain under validator exposure, which is expected by the staking design. The current stVaults TVL is relatively low (< 6k ETH), with total minted stETH exposure constrained to < 5k stETH across a few vaults. No vaults are currently unhealthy, and the stVaults committee is monitoring all launched vaults and would notice potential irregularities.
Mitigations in place.
- Requires a specific precondition: vault must be unhealthy, and all validator balances must be very close to 32 ETH(
MIN_ACTIVATION_BALANCE) - Oracle daemon can be updated with a mitigation patch within ~24 hours to push the vault into a virtual zero-TVL state, disabling partial withdrawals.
- Transition from “unhealthy” to undercollaterized takes weeks due to reserve ratio parameters.
Status of exploitation.
Never exploited. No unhealthy vaults exist, and no reserve ratio breaches have occurred.
Planned corrective on-chain action.
The fix will disable partial withdrawals when a vault has outstanding obligations which may be revised later depending on further research.
Why several weaknesses surfaced in a short time frame
The concentration of findings within March 2026 is not coincidental — it reflects a broader shift in how security research is conducted. AI-assisted auditing tools have matured significantly over the past two quarters, and whitehats are increasingly leveraging these tools to explore interaction patterns, edge cases, and cross-component authorization gaps that manual review might deprioritize.
Two of the three reports demonstrated sophisticated understanding of CL/EL interactions and governance trust boundaries — areas where AI-augmented analysis excels at systematic exploration. This is a positive development for the ecosystem. Better tooling means weaknesses surface earlier, through responsible disclosure rather than exploitation. Lido’s bug bounty program exists precisely to incentivize this, and the March reports validate that it is working as intended.
To be clear: all three weaknesses are confirmed, none were exploited, funds were never at risk, and all severity assessments are low-to-medium. The corrective on-chain actions for all three are bundled into the upcoming omnibus vote.
What Lido contributors are already doing
Lido contributors have actively adapted security processes over the past quarter to account for the evolving landscape:
- AI audit provider relationships. Lido maintains ongoing subscriptions and relationships with multiple AI-augmented audit providers (including Nethermind and Savant.Chat), and continuously evaluates new entrants based on circulated benchmarks (e.g. EVMBench).
- On-chain release checklists. Every release now explicitly requires multiple AI audit runs — both from external providers and internally-built tooling with Lido-specific protocol context — before deployment.
- Immunefi triage tooling. Incoming bug reports are monitored with additional rigor, supported by triage-assisting tools that accelerate validation and severity assessment.
- Overlapping scan coverage. The codebase is scanned with significant overlaps across tools and providers rather than scope-by-scope isolation, increasing the probability of catching cross-component issues.
- QA automation and AI augmentation. QA contributors facilitate additional automation and AI-augmented for test plans and pipelines to improve release assurance.
What’s next
Looking ahead, Lido contributors aim to maintain Lido position as a top-tier blue-chip DeFi protocol in security posture:
- Continue expanding AI audit provider relationships and always be early in evaluating new tools as they emerge.
- Improve internal tooling based on benchmarks, enriched Lido-specific context bases, and growing skillsets within the contributor community.
- Work toward enabling continuous, context-aware security coverage where AI tools operate with deep protocol understanding — not just static analysis but aware of governance flows, cross-layer interactions, and deployment-specific configurations.
- Invest in proactive security exercises including focused contests for new deployments and protocol upgrades (previously: Bug Bounty Comp | Lido V3 and Bug Bounty Comp | Dual Governance) with a preference of staged launches and training wheels available for a limited timeframe.
Why we are disclosing these together
We chose to publish a single batched bulletin rather than three separate reports for a deliberate reason: these findings share common context and timing, and we believe a consolidated disclosure better serves the community. Publishing them together allows us to present the systemic picture — not just the individual fixes, but the pattern they reveal about evolving security tooling and how the protocol’s defenses are adapting. It also avoids unnecessary noise from three separate communications that would largely reiterate the same timeline, process, and outcomes.
Acknowledgements
Lido contributors extend sincere thanks to the whitehats who responsibly disclosed these weaknesses through the Lido × Immunefi bug bounty program. The quality and thoroughness of these reports — particularly the proof-of-concept work — made triage and response significantly faster. Bounty rewards have been processed for all three reports.
We also thank the Emergency Brakes Multisig signers for their prompt response on the wstETH on zkSync bridge pause, Matter Labs and txFusion teams for their collaboration, 3rd-party audit providers and security experts for their prompt reaction (Cantina, MixBytes, Certora) and the broader Lido contributor community for coordinated incident response.
Discussion
We are publishing this bulletin to invite constructive discussion from the security community. In particular, we are interested in perspectives on:
- How other protocols are integrating AI-assisted audit tooling into their release pipelines
- Emerging approaches for cross-layer (e.g., CL/EL) security verification
- Best practices for continuous security coverage in protocols with broad attack surfaces
If you have ideas, experience, or feedback — we welcome the conversation.