Ethereum validator operators using the Prysm consensus client received an emergency alert on December 4th. The Prysm team has confirmed that some nodes are generating stale state to handle stale certificates. If this is not checked, incorrect validation behavior may occur. To prevent this, Prysm has instructed all operators to immediately disable certain features by adding a single flag to their beacon nodes. This fix does not require a complete client upgrade and does not affect validation clients.
🚨 We’ve identified the issue and have a quick workaround. All nodes must disable Prysm and unnecessarily generate stale state to handle stale certificates. To do this, simply add the following flag to your beacon node: This flag works in v7.0.0, so you don’t need to do the following:
— Prysm Ethereum Client (@prylabs) December 4, 2025
The team asked the operator to add the following line: Disable –last-epoch-targets. This flag works in Prysm v7.0.0. This means that most nodes can apply fixes within minutes. This warning sparked a swift reaction across the validator community. This gives Prysm a large footprint within Ethereum’s consensus layer.
Prysm’s market share makes this a network-level event
According to MigaLabs data, Prysm controls nearly 20% of Ethereum’s consensus client market share. This makes it our second largest customer after Lighthouse. Its scale is what turned a client-side bug into a chain-wide problem. If a client with this kind of weight processes stale state data. Not just one validator is affected. It can spill over into things like:
- Missing authentication
- Wrong fork selection signal
- Increased risk of penalties and slashes in edge cases
So far, there is no evidence of live chain outages or finality failures related to this issue. However, the concern is only with risk prevention, not with damage control. Prism took action before the situation worsened. In other words, this was a pre-emptive fire extinguishing exercise, not a clean-up after the accident.
What exactly happened inside Prysm?
According to the Prysm team, affected nodes were generating unnecessary stale state while trying to process stale certificates from previous epochs. This behavior increases CPU and memory strain and can distort the way nodes track chain progress under stress. This kind of behavior is not new in Ethereum’s history. Similar state handling issues have also occurred in the following cases:
- Finality incident in May 2023
- Previous database index corruption bug
- Historical memory spike issue across multiple clients
The main difference this time is speed. Prysm detected the issue early and published a one-step workaround. It also avoided forcing thousands of validators to rush through a complete upgrade cycle.
What validators should do now
When running Prysm, the checklist is short and urgent.
- Add. –Disable last epoch target flag
- Restart the beacon node
- Verify logs for normal authentication flow
- Monitor memory and CPU after reboot
No changes to validator keys are required. No resync or termination required. For Ethereum as a whole, this episode confirms the well-known truth that client diversity remains important. When one client takes up nearly 20% of the network, even a manageable bug becomes a headline event. Still, this incident shows Ethereum’s operational maturity. The issue was identified, disclosed, and mitigated within hours instead of days. This is how we keep our $400 billion+ real payments layer resilient. The chain is currently stable. The only real deadline is for Prysm operators to act quickly and flip the safety switch.
