Up to now, there are 11 Lighthouse releases in 2026. It is apparent that most releases have one distinction: fixes for security vulnerabilities. In this blog, we attempt to answer some questions that you may have in your mind: what happens behind the scenes about bug reports?
How we receive bug reports
If you think you have identified a bug, you can submit via the Ethereum Foundation bug bounty programme. We ask that you do not publicly open an issue, as doing so will disqualify you from the program. Once you have submitted the bug report, we will be notified by the Ethereum Foundation Protocol Security Research Team.
We use our in-house security review tool Secstant to scan the Lighthouse codebase. Secstant has identified dozens of bugs which were reported to our developers internally.
The Protocol Security Research Team is also working on finding security vulnerabilities. If they find a bug, they will inform us. We are therefore in close contact with the Ethereum Foundation Protocol Security Research Team, even more so in the past few months, as the advent of AI and LLMs has led to bugs being discovered at an unprecedented rate.
Alternatively, we can be reached directly via email: security@sigmaprime.io.
From receiving to closing a report
Once we receive a report, our developer typically replies within 24 hours for a first assessment of how we think of the bug severity, or if the bug report is valid.
The bug report usually comes with a proof of concept (PoC). The PoC can be as simple as a peer connecting to a Lighthouse beacon node, sending invalid data to attack the node; or it can be a Kurtosis testnet. We run the PoC to reproduce the bug. If the PoC has demonstrated the attack, we will then work on a fix. When we have a fix, we run them against the PoC again and/or testnets to confirm that the attack no longer works.
Once the fix is merged, we will close the report as complete.
Closed reports
The previous section alludes that not all reports contain valid bugs. From our record of 81 closed reports, 54% are valid and 46% are not considered as valid. The latter includes reports that are not a security concern, known or duplicated issues, or reports that are informational in which a fix is not necessary.
The bugs are categorized into a few categories of severity: low, medium, high or critical. Of the valid reports, the percentage of severity is as follows: 45% low, 41% medium and 14% high. We have not received a critical bug report to date, and we hope to maintain it this way.
Counting from the day the bug was reported to the day the fix was merged, the median is 17 days and the average is 33 days. The time taken to fix a bug varies, depending on its impact, complexity and exploitability. For high impact bugs, we will fix it as a high priority. This includes publishing a release right after to prevent any potential exploits. Conversely, if a bug is not impactful or easily exploitable, we will still fix it but with a lower urgency.
List of vulnerability
When we publish a new release, we will not disclose the vulnerability instantly. This is to give users time to update their nodes. After some time, we will update the vulnerability details in the release notes and Github Security Advisories for full transparency.
A summarising table of all vulnerabilities from Lighthouse v8.1.1 to v8.3.1 is appended at the end.
Coordination
You may be wondering: since Lighthouse is open-source, how do we push the fix and not attract exploits? After all, the fix will be public for some short time before a release is announced.
This is true, and this is where coordination comes in. If the bug is within Lighthouse itself, we can push the fix and make a release right after, minimizing the window between the fix and the release to just a few hours.
If the bug is in a Lighthouse dependency, for example the quinn repository, our developers will coordinate with the maintainer of the repository about a release timeline. Using Lighthouse v8.2.3 as an example, the quinn repository published:
- quinn-udp 0.5.16 at 09:37 UTC on 30th September 2026
- quinn-proto 0.11.19 at 10:25 UTC on 30th September 2026
We were aware of their update timeline. We planned internally and published:
- Lighthouse v8.2.3 at 02:15 UTC on 1st October 2026
This is within 24 hours after the dependency update. Narrowing the window of time not only reduces the likelihood of an attack, it also enables our users to update Lighthouse quickly and enjoy the peace of mind.
Real-life attack
You may also be wondering: has there been a successful real-life attack on a Lighthouse node that has not updated?
As a matter of fact, there was. We rolled out Lighthouse v8.1.2 which contains the security fix for rust-libp2p on 9th March 2026. Just one day after, a user reported a crashed Lighthouse node. The issue is exactly the vulnerability that is fixed in Lighthouse v8.1.2. The user was using Lighthouse v8.1.1, which is vulnerable to the bug, and the node was brought down. The fix is to simply update Lighthouse to be immune to the attack.
Concluding remarks
With AI and LLMs tools actively scanning the Lighthouse codebase, there is no doubt that new bugs will keep being surfaced. Looking on the bright side, fixing bugs improves Lighthouse quality, making it more resilient to attacks. In the blockchain industry where things are changing rapidly, one thing does not change: our developers who have been working diligently, and will continue to work diligently to ensure that Lighthouse remains a performant and secure client.
Appendix
A list of vulnerability fixes from Lighthouse v8.1.1 to v8.3.1