The Bug That Shouldn't Exist
We've all been there: panic: runtime error: invalid memory address or nil pointer dereference. Usually, it’s just a bug in your local service. But what if that same panic could stop an entire blockchain?
While auditing the Binance Smart Chain (BSC) fork of Geth, I found exactly that. A missing nil-check in the state package that allows a malicious actor to trigger a network-wide halt.
The Technical Deep Dive
The vulnerability sits in the state transition logic. When the engine attempts to create a contract (CreateContract) for an address that is missing from the state database, it doesn't return an error—it panics.
In a distributed system, this is a "Nuke". Because blockchain execution must be deterministic, every single node that validates the block containing this transaction will hit the same nil pointer and crash.
The PoC:
I isolated the crash into a simple test case. If you're running a BSC node, this is your nightmare:
Go
func TestBSCCreateContractPanic(t *testing.T) {
// 1. Init state
state, _ := New(common.Hash{}, NewDatabaseForTesting())
// 2. Use a non-existent address
addr := common.HexToAddress("0xdeadbeef")
// 3. Boom.
state.CreateContract(addr)
}
The "Not Applicable" Paradox
I reported this via Bugcrowd to the Binance team. Despite it being a core protocol vulnerability capable of halting the chain, it was marked Not Applicable.
The reason? I submitted it under the "Web App" scope because the "Core" scope was locked or restricted. It’s a classic example of how rigid Bug Bounty rules can sometimes overlook critical infrastructure risks.
Lessons for Go Devs
Never assume state: Even in core libraries, if a pointer can be nil, it will be nil at the worst possible time.
Handle, don't Panic: In consensus-critical code, a panic is almost always a security vulnerability.
Check out the full reproduction here:
github.com/rdin777/bsc-halt-poc
Top comments (0)