Sigma Prime, the team behind Lighthouse, published Lighthouse v8.3.3, dated 9 November on its GitHub release page, and asked every operator of a Lighthouse beacon node to upgrade “as soon as possible”. The release notes call it a high-priority patch that contains security fixes. They do not say what the flaws are: the details “will be disclosed at a later date”, once node operators have had time to install the new version.
That matters beyond one software team. By at least one count Lighthouse is the most used Ethereum consensus client: Miga Labs puts it at 46.96%, in data shown on clientdiversity.org when Coindaro checked it on 11 November. Another tracker on the same page, Rated.Network, shows 20.6%. A serious bug in a client that size concerns the whole network.
Neither the release notes nor CryptoSlate’s report of 11 November mention any exploitation or loss of funds. CryptoSlate also stressed that the mechanics and possible impact of the flaws have not been made public.
What the Lighthouse v8.3.3 release says, and what it keeps back
The release, nicknamed “Sleepy Gary” and signed with Sigma Prime’s PGP key, carries an update-priority table. It splits the software into its two parts: the beacon node, which follows the chain and talks to other nodes, and the validator client, which holds the signing keys and casts votes.
| Component | Staking users | Non-staking users |
|---|---|---|
| Beacon node | High | High |
| Validator client | Low | Not rated |
So the urgent part is the beacon node, for everyone who runs one, whether or not they stake. The validator client can wait for a normal update cycle. In Lighthouse’s own priority scale, as summarised by CryptoSlate, “high” means acting within hours or days, while “low” belongs in the next routine update, with two weeks given as an example.
The notes list no breaking changes. Operators still on v8.2.x or older are told to read the v8.3.0 release notes first, since that version brought its own changes.
The public change list is short: a libp2p update, a crypto-bigint bump, changes to how inbound network requests and timed-out substreams are counted and reclaimed, a fix to an is_infinity method, and a few build fixes. The release does not say which of these lines, if any, are the security fixes. Reading the list as a map of the bugs would be guesswork.
What is not known, as of 11 November: which versions are affected, how severe the flaws are and who reported them. Lighthouse has not given a date for the advisories either.
Why Sigma Prime keeps the details secret for now
Withholding the details is Sigma Prime’s stated policy. Four days before the release, on 5 November, Sigma Prime engineer Tan Chee Keong described the process in a blog post on bug reports. Researchers report flaws through the Ethereum Foundation bug bounty or by email; a developer usually replies within 24 hours with a first view on validity and severity. Sigma Prime also runs its own scanning tool on the code and receives bugs found by the Ethereum Foundation’s protocol security team.
Under that policy the fix ships first and the details wait. They go into the release notes and GitHub security advisories later, once users have had time to update.
The same post gives a rare look at the numbers. Of 81 closed reports, 54% turned out to be valid. Among the valid ones, 45% were rated low, 41% medium and 14% high, and Sigma Prime says it has not yet received a critical report. The median time from report to merged fix was 17 days, the average 33.
The track record points the same way. The Lighthouse security advisories page lists earlier patches whose details came out later, including four advisories published on 26 October 2026 (one rated high, for memory exhaustion when serving data column requests) and three on 15 October. High-priority releases are not rare either. The releases page rates v8.2.0 (22 June), v8.2.1 (21 July) and v8.2.2 (18 August) high priority for beacon nodes, each with security fixes, and v8.3.1 (22 October) high priority for stakers after the compromise of the eMudhra certificate authority.
What solo stakers and node operators should do
- If you run a Lighthouse beacon node, upgrade it to v8.3.3 now. Binaries exist for x86_64 and aarch64 Linux and for Apple Silicon Macs, and the Docker image is sigp/lighthouse:v8.3.3.
- Check the PGP signature of the download against Sigma Prime’s key, listed on the release page, before you install it.
- Update the Lighthouse validator client at your next routine maintenance. The release rates it low priority.
- Coming from v8.2.x or older? Read the v8.3.0 notes before you jump.
- Watch the release page: links to the security advisories will be added there once operators have had time to upgrade.
People who stake through an exchange, a staking means depositing a proof of stake coin with a protocol that stakes it for you and issues a transferable token (such as Lido stETH or rETH) representing the deposit plus rewards, which you can use or sell while the coins stay staked.">liquid staking protocol or a staking service have nothing to install: their node operator runs the software. In a distributed validator cluster built with Obol or SSV Network, the advice applies to each machine that runs a Lighthouse beacon node. The release covers Lighthouse only. For the basics of what each machine does, see our guide to blockchain nodes.
Why one client’s market share matters
Ethereum’s proof of stake needs two thirds of validators to agree before a block becomes final. That makes client share a safety number. If a client used by more than a third of validators fails, the chain can keep producing blocks but cannot finalise them. If a buggy client held more than two thirds, it could finalise a wrong chain. Clientdiversity.org sets the goal at below 33% for every client and calls anything above 66% the danger zone.
Where Lighthouse sits depends on who is counting, and the trackers disagree sharply.
| Tracker (clientdiversity.org, read 11 Nov 2026) | Lighthouse | Prysm | Teku | Nimbus |
|---|---|---|---|---|
| Miga Labs | 46.96% | 17.73% | 6.45% | 18.86% |
| Rated.Network | 20.6% | 21.17% | 53.86% | 3.12% |
The page says each source is updated daily but shows no date for these readings, and it warns that the data “may not be 100% accurate”. A third tracker on it, Blockprint, put Teku at 99.83% and Lighthouse at 0.16% on 11 November, far from both other readings. By Miga Labs’ count Lighthouse is above the one-third line and below the two-thirds one. By Rated’s, it is well under a third.
The Prysm near-miss of December 2025
Ethereum has already seen what a client bug looks like. The Fusaka upgrade went live on mainnet on 3 December 2025 at 21:49 UTC, according to the Ethereum Foundation. The next day, Prysm nodes ran out of resources while processing attestations from out-of-sync nodes and rebuilt old states from scratch, according to Cointelegraph’s account of the Prysm post-mortem.
At epoch 411,448, voting participation fell to 74.7%, about eight points above the two-thirds line, Cointelegraph reported using beaconcha.in data. It recovered to almost 99% by epoch 411,712. Validators lost about 382 ETH in attestation rewards over more than 42 epochs, according to the same Cointelegraph account, published on 15 December 2025. Prysm held less than a third of the network, so finality held.
Anthony Sassano, an Ethereum educator, wrote on X at the time, as quoted by Cointelegraph, that the network would have lost finality had the bug hit Lighthouse instead. Cointelegraph’s 5 December 2025 report, citing MigaLabs, put Lighthouse at 52.55% after the incident, up from below 48.5% before it. Miga Labs’ reading on clientdiversity.org on 11 November 2026 is 46.96%.
On 7 November the Reth execution client had its own flaw, which pushed Base, BNB Chain and Tempo to patch. For how missed duties and penalties work, see our guide to Ethereum slashing and validator rewards.
What to watch next
The next step is the disclosure itself. Lighthouse says links to the security advisories will appear on the v8.3.3 release page once operators have upgraded. When the advisories land, they should say which versions were exposed and how severe the flaws were. Lighthouse has given no date for them.