SHA-256's New Collision Attack, Explained

A headline claiming a SHA-256 collision attack can travel faster than the paper behind it. For Bitcoin miners, that creates one question that matters: does the result change the security of the work your hardware is doing right now? The word "attack" in a headline rarely settles that. What actually decides it is the exact security property, round count, model, and cost the researchers broke.

Discussion around IACR ePrint 2026/232, by Zhuolong Zhang, Muzhou Li, Lei Gao, and Meiqin Wang of Shandong University, and a reported 37-step SHA-256 collision attack is a good example. A reduced-round cryptanalytic result can be legitimate and valuable without being an attack on full SHA-256, Bitcoin proof-of-work, or Bitcoin ownership. Trust nothing. Verify the claim boundary.

Collision vs Preimage: the distinction Bitcoin miners need

A hash function takes an input of arbitrary size and returns a fixed-size digest. SHA-256 outputs 256 bits. Because there are infinitely many possible inputs and only a finite number of outputs, collisions must exist in principle. The security question is whether an attacker can deliberately find one at a practical cost.

A collision means finding any two different messages, M1 and M2, that produce the same hash: SHA256(M1) = SHA256(M2). For an ideal 256-bit hash, generic collision search takes roughly 2^128 work because of the birthday bound. That number is enormous, but it is far smaller than 2^256.

A preimage attack starts with a specific target digest and asks for an input that hashes to it: find M such that SHA256(M) = H. For ideal SHA-256, generic preimage search takes roughly 2^256 work. A second-preimage attack is related but starts with an existing message and seeks a different message with the same digest. It also has an expected generic cost near 2^256 for a well-designed 256-bit hash.

These are not interchangeable words. A collision result does not automatically provide a preimage result. A preimage result sits much closer to the property that would threaten the assumptions behind Bitcoin mining cryptography, because it lets an attacker start from a specific target rather than simply matching any two arbitrary inputs to each other.

Why Bitcoin SHA-256 security is not a collision problem

Bitcoin mining repeatedly hashes a block header, using SHA-256 twice. A valid header must produce a hash numerically below the network target. The miner is not trying to make two headers collide. The miner is trying to find one header whose double-SHA-256 output falls inside a very small acceptable range.

That is sometimes described as a partial-preimage search. The target is not one exact 256-bit digest, but any digest below the threshold. Bitcoin adjusts that threshold through difficulty.

A generic collision attack would let an attacker choose two inputs that share an output. Knowing that two headers collide with each other says nothing about where either one lands relative to the current target, so it provides no route to a below-target header on demand, no way to submit a stale share as a new valid header, and no way to convert spare nonces into free block solutions.

The same distinction applies to a pool's work accounting. A share proves that a particular header hashes below the assigned share target. It is an independently checkable condition.

There are other places where hash collision resistance matters in Bitcoin, including identifiers and Merkle-tree constructions. But even there, the practical impact must be traced through the full protocol: serialization rules, transaction validity, signatures, consensus verification, and the attacker's ability to get a chosen object accepted. A collision on paper is a research result. Whether it becomes a protocol break depends on whether each of those steps actually holds.

What a 37-step SHA-256 attack usually means

Full SHA-256 has 64 rounds in its compression function. Research papers often analyze reduced-round variants because those variants expose how differential paths, message modification, and other techniques behave before the full design becomes intractable.

So a 37-step SHA-256 attack likely refers to a result against a limited number of steps or rounds, not a practical break of all 64 rounds. Thirty-seven steps out of sixty-four covers a little under 58% of the algorithm. A successful attack on 37 rounds can be a meaningful advance in cryptanalysis while remaining irrelevant to the security level of production SHA-256.

Before treating any such paper as evidence that SHA-256 is broken, inspect it for four boundaries:

• The primitive: Is the result against the real SHA-256 compression function, a modified construction, or a simplified variant?
• The rounds: Does it cover all 64 rounds, or only a reduced-round target?
• The attack goal: Is it a collision, chosen-prefix collision, semi-free-start collision, preimage, second preimage, distinguisher, or something else?
• The cost model: Does the stated complexity include memory, offline preparation, special starting values, and the probability of success?

A semi-free-start collision, for example, grants the attacker control over internal chaining values that ordinary users do not control in standard SHA-256 use. That can be excellent academic work and still not map onto Bitcoin block-header hashing. A distinguisher can show non-random structure without giving an attacker a method to forge useful hashes. The details are the security claim.

Applied to this specific paper, those boundaries resolve cleanly. The previous record, set by Mendel et al. at EUROCRYPT 2013, stopped at 31 steps, and nobody had moved that number in twelve years. This result adds six more steps, plus a cheaper 36-step variant, which matters on its own: cost, not step count alone, determines whether an attack is practical. The progress curve shows how uneven the climb has been: 24 steps in 2008, 27 in 2011, 28 and then 31 in 2013, a more practical version of the 31-step attack in 2024, and now 37 in 2026.

What actually moved the number has two parts. Attacks like this work by finding "local collisions," small patterns in SHA-256's message expansion where an attacker's changes cancel out instead of propagating. Building those by hand is slow and hard to scale, which is what capped progress at 31 steps for over a decade. This paper's first contribution is an automated tool that searches for local collisions instead of relying on a researcher to find them by inspection. The second contribution is new models of SHA-256's IF and MAJ Boolean functions that capture every relevant bit condition; earlier models, including one published at CRYPTO 2025, only captured a subset of those conditions and missed valid attack paths as a result. The authors did not extend either technique to SHA-512: the larger 64-bit word size made their models intractable, at least so far, and they have flagged it as future work rather than claimed it.

Is SHA-256 broken? Use a stricter test

"Broken" is a poor technical label because it hides the question that needs answering: broken for what application, under what conditions, and at what cost?

For Bitcoin proof-of-work, a result becomes operationally serious if it produces a practical advantage in finding valid full SHA-256d block headers below the network target. That advantage would need to be repeatable, materially cheaper than brute force, and applicable to the exact input format and two-pass construction Bitcoin uses. For background on the generic complexity bounds behind that brute-force baseline, see Wikipedia's overview of SHA-2.

Put a number on that bar. Bitcoin's current network difficulty sits around 126.23 trillion. Difficulty times 2^32 gives the expected number of hashes needed to find a valid block: roughly 2^78.8 hashes, honestly, the normal way, with real mining hardware pointed at the real problem. The 36-step collision attack from this paper costs 2^94.4 in time; the 37-step version costs 2^119.1.

Approach	Time complexity	Relative to honest mining
Honest mining at current difficulty	~2^78.8 hashes	baseline
36-step collision attack (this paper)	2^94.4	~50,000x more expensive
37-step collision attack (this paper)	2^119.1	~1.3 trillion times more expensive

Set aside, for a moment, that a collision attack doesn't even solve mining's preimage problem. The shortcut costs vastly more than the thing it's supposed to shortcut. Nobody spends 2^119.1 worth of computation to save themselves 2^78.8 worth of computation.

For transaction integrity, the relevant question is different. Could an attacker exploit a real-world collision to substitute a transaction, alter a committed structure, or bypass an authorization check? Bitcoin signatures, transaction IDs, witness commitments, and consensus rules create separate barriers.

A genuine break of SHA-256's preimage resistance, if one ever surfaces, would not announce itself as an unusually lucky miner finding a suspicious number of blocks. It would show up as forged signatures and coins draining from addresses that should be uncrackable, and it would show up there first. Anyone holding a real preimage break has far better uses for it than mining one block at a time; using it to mine would be like using a master key to unlock a bank vault and walking out with a stick of gum.

No responsible operator should dismiss cryptanalytic research. Reduced-round attacks are one way the field measures margin. But a reduced-round collision result is not evidence that a home miner's hardware suddenly has an exploitable shortcut to blocks.

The double-SHA-256 detail matters

Bitcoin does not apply SHA-256 once to a block header. It applies SHA-256 twice. An attack against a single reduced-round compression function must be evaluated against the full first hash, the full second hash, padding behavior, fixed header structure, and the fact that the intermediate value becomes the input to another full SHA-256 invocation.

That does not mean double hashing makes every theoretical weakness irrelevant. It means the attacker needs an end-to-end method against the actual construction, not a result that stops at a component or reduced-round model. SHA-256's own padding rules also fix the message length and structure that an 80-byte block header can take, which further narrows how any reduced-round differential path could be carried into real header data in the first place.

Mining hardware also does not operate over arbitrary attacker-designed messages in the way many collision constructions assume. Miners vary nonce fields, time, extraNonce-derived coinbase data, and Merkle roots within strict block-validity rules. The available degrees of freedom are substantial for brute-force search, but they are not a blank check to satisfy specialized differential constraints.

What independent miners should verify

The immediate operational risk for a solo miner is not normally an academic SHA-256 collision. It is opaque infrastructure: work that does not match the advertised template, shares that are silently discarded, a payout address altered before block construction, or a pool that takes custody of a reward it did not earn.

Those are present-tense failures. They are also failures a miner can test directly.

Check that the coinbase payout destination is your own Bitcoin address before mining a template. Confirm that submitted shares are checked against a declared target, and look at where the pool gets its chain state and whether stale-work behavior is observable. If you use Stratum V2, look at the authority key and encrypted connection behavior yourself rather than taking a browser badge as proof. If a pool claims a ledger of accepted work, check the signature format and the bytes being signed.

NexusPool's design follows that boundary: the miner keeps the payout address, and a solved block pays the subsidy and transaction fees directly on-chain. That does not change your luck. No pool can do that. It removes a separate custody and accounting risk that should never be confused with a hash-function claim. Our own custody system, the Glass Ledger, signs its receipts with SHA-256 and related primitives, alongside HKDF, ChaCha20-Poly1305, and Schnorr signatures per BIP340. None of that depends on SHA-256 preimage resistance either, so we hold our own stack to the same test this article applies to Bitcoin's block header, not just the chain we're paying out on.

A real hash function vulnerability deserves exact language, independent reproduction, and protocol-specific analysis. Until a claim demonstrates a practical shortcut against full SHA-256d proof-of-work or a concrete Bitcoin consensus path, the standard does not change: validate the work, control the address, and require proof before you act on anything less.