Infrastructure · Original reporting
The Comment Said the Unwrap Was Safe
A NEAR maintainer found a path for one chunk producer to crash validators working on shards it never touches. The fix merged forty-one minutes after it was opened, with no security label, no advisory, and a regression test whose failure message says exactly what was at stake.
On Friday at 12:38 UTC, a NEAR core developer opened a pull request against nearcore with an unglamorous title: don't panic on gas overflow in early transaction preparation. It carried no labels. It was not filed as a security fix. Forty-one minutes later it was merged.
The description, in full, is four sentences long. Read carefully, they describe a way for one participant in NEAR's validator set to crash other people's nodes.
The line that was wrong
NEAR is a sharded chain. Validators do not process everything; each one applies the shards it tracks, and takes the rest of the network's word for the shards it doesn't. Chunk headers — the summaries each shard's producer publishes — carry gas fields: how much gas the previous chunk burned, and the chunk's gas limit.
Those fields get cross-checked against the node's own record of what actually happened, prev_chunk_extra. But only for the shards that node applies. For every other shard, the numbers in the header are, at that moment, just numbers somebody sent.
NEAR's optimistic-block path is an optimization: rather than wait for a block to be fully processed, a node starts preparing the next chunk's transactions early, using a projected gas price. To project it, the code sums the gas fields across all shards. That sum ran before any block-level validation.
Until Friday, the code that did the summing looked like this:
// Unwrap is safe here because chunk headers are already verified.
let gas_used = chunk_headers.compute_gas_used_checked().unwrap();
The functions were named _checked. They returned an optional value precisely because the arithmetic can fail. And the calling code threw that safety away with .unwrap(), on the strength of a comment asserting the headers had already been verified.
They had not. Not the ones from shards the node doesn't apply, and not at that point in the pipeline. In Rust, an .unwrap() on a value that isn't there does not return an error to be handled upstream — it panics, and the node goes down.
What the test proves
The patch itself is small: replace the unwraps with a fallible chain, and if the gas math overflows, log a debug line and skip the optimization. Early transaction preparation is a speedup, not a requirement; skipping it costs a little throughput and nothing else.
The interesting part of the change is not the fix. It is the 78-line test file shipped alongside it, and what the author had to build to write it.
The pull request adds a new adversarial control to the chunk producer, gated behind a test-only compile flag, that forges a chunk header's previous-gas-used and gas-limit fields to Gas::MAX — the largest value the type holds. Two of those, summed, overflow. The new test then stands up a four-shard network with one chunk producer per shard and turns that control on for exactly one of them.
The comment above the test setup states the threat model in one line: one chunk producer per shard, so each validator applies only its own shard, as on mainnet. The test then asserts, before it starts, that the attacker's shards do not overlap any victim's — the point being that the victims never touch the forged shard's data at all.
The test's name is test_forged_max_gas_chunk_header_does_not_abort_honest_validators. Its failure message, which a maintainer will only ever see if the fix regresses, reads: a forged Gas::MAX chunk header took down an honest validator.
Where the gas fields were trusted, and where they were checked
| Path | Shards involved | Validated first? |
|---|---|---|
Header cross-check vs prev_chunk_extra | Only shards the node applies | Yes |
| Block-level checks | All | Yes — but later |
| Optimistic-block gas sum (the panic) | All | No |
That last row is the whole story. The forged chunks would never have been endorsed. NEAR's validation would have caught and rejected them. But the optimization ran first, and a node that panics does not get to reach the code that would have protected it.
What this is, and what it isn't
Some care is owed here, because it is easy to oversell a patch like this and the desk has no interest in doing so.
This is a liveness and availability issue, not a theft one. Nothing in the change suggests funds were reachable, balances could be altered, or consensus could be subverted. The failure mode is a validator process crashing.
The attacker also cannot be just anyone. Producing chunk headers means being a chunk producer, which on NEAR means holding enough stake to be selected for the role. This is not an anonymous, free attack; it requires a staked position and burns it publicly the moment anyone looks. That materially raises the cost and lowers the likelihood.
And there is no evidence any of this happened. Nothing in the pull request, the repository, or the public record suggests exploitation. The desk found no report of NEAR validators crashing, and is not asserting one.
What can be said, from the code alone: a NEAR developer identified a crash reachable by a single misbehaving chunk producer against validators on unrelated shards, built the tooling to forge exactly that header, demonstrated it against a mainnet-shaped topology, and fixed it. That is not speculation. It is what the pull request contains.
Quiet is not the same as hidden
The patch went to master with no security label and no advisory. NEAR's repository lists no published security advisories at all. The most recent tagged release, 2.13.4, shipped on September 3 — the day before this merged — which means the fix is on master and not yet in a release binary.
None of that is a scandal, and the desk has covered enough silent patches this year to say so plainly. Landing a fix without a klaxon is standard, defensible practice: an advisory is a map, and publishing one before operators can upgrade helps the wrong people first. This one merged in forty-one minutes on a Friday, which is what a team that takes something seriously looks like, not a team burying it.
The observation worth making is narrower. Quiet patching works as a security strategy only while nobody is reading the commits — and reading the commits is now trivially automatable. This desk's monitor surfaced this pull request the morning after it merged, from public data, on a schedule, with no inside knowledge. Whatever protective value silence has is shrinking, and it is shrinking for defenders and attackers at exactly the same rate.
The comment is the artifact
Strip away the sharding and what remains is a sentence someone wrote in good faith that stopped being true. Unwrap is safe here because chunk headers are already verified. Somewhere upstream, that was accurate. Then the optimistic-block path arrived, moved the work earlier in the pipeline, and quietly invalidated the premise — and the comment stayed, still confident, now wrong, vouching for an .unwrap() that nothing was checking anymore.
Comments do not get tested. That is the entire problem with them. The compiler will not tell you that a justification has expired, and a reviewer reading the line sees a claim of safety rather than an assumption to go verify. Every codebase has these — assertions that were true when written, sitting above code that has since moved out from under them.
What NEAR did right is the part worth copying. The maintainer did not simply delete the unwrap and move on. He built an adversary, forged the header, and left behind a test that fails loudly if anyone re-introduces the assumption. The comment is gone. The proof is in the repository.
The Take
Search your own codebase for the phrase "is safe here." Then check whether it still is. Every such comment is a claim that was verified once, by someone who is no longer reading it, about a call path that has probably changed — and unlike an assertion or a test, nothing in your toolchain will ever re-check it for you. NEAR's maintainer did the version of this that should be standard: he did not just remove the unsafe call, he wrote the attacker that breaks it, so the next person who reaches for the shortcut gets a red build instead of a comment telling them it's fine. Optimizations that run before validation deserve this scrutiny generally. They are, by construction, the code that handles untrusted input the earliest and trusts it the most.