Mining Firmware Attacks: The Supply Chain Risk Bitcoin Miners Ignore

Every Bitcoin miner runs firmware: the low-level software that controls how an ASIC communicates with mining pools, constructs work, and reports results. Most miners never inspect this code. They flash whatever the manufacturer ships, connect to a pool, and start hashing. That trust is the attack surface.

Mining firmware attacks are not theoretical. Backdoors have been discovered in production hardware affecting a majority of global hashrate. Trojaned firmware circulates through unofficial channels, silently redirecting rewards to attackers. And in 2026, the 256 Foundation published the first independent security audit of major ASIC firmware, revealing 41 vulnerabilities across stock and third-party firmware alike. This article documents the attack vectors, the audit findings, and the mitigations available today.

How ASIC Mining Firmware Works

An ASIC miner is a specialized computer. Its firmware handles several critical functions: connecting to a pool over the Stratum protocol, receiving work units (typically via block templates from the pool), distributing hash computations across chip boards, reporting valid shares back to the pool, and managing thermal throttling and fan control.

The firmware also determines where mining rewards are sent. It contains the pool URL, the worker name, and in some configurations the payout address. Any code running at this level has complete control over what the miner does with its hashrate.

Why firmware is the perfect attack surface: Unlike malware on a desktop, compromised mining firmware runs on devices that operators rarely monitor at the software level. Miners watch hashrate dashboards and power draw. They almost never inspect running processes, network connections, or firmware binaries.

Attack Vector 1: Hashrate Hijacking and Reward Redirection

The most common firmware attack silently redirects a percentage of the miner's hashrate to an attacker-controlled pool. The miner's local dashboard continues to show normal performance, but the pool receives fewer valid shares than expected. The difference goes to the attacker.

Trojaned firmware variants have been documented for every popular Antminer model and several Whatsminer models. These malicious firmware files circulate through forums, Telegram groups, and unofficial download sites that impersonate manufacturers or third-party firmware projects like Braiins or other vendors. Once installed, some variants skim 5 to 30 percent of hashrate intermittently, making detection harder by varying the theft window.

Worm-style propagation

Some firmware trojans do not wait to be installed manually. They exploit default SSH credentials (commonly root/root or admin/admin on stock firmware) to scan the local network, copy themselves to adjacent miners, and modify each target's firmware to redirect hashrate. A single infected unit purchased on the secondary market can compromise an entire facility within hours.

Persistent variants disable SSH access and block legitimate firmware updates after infection, requiring physical SD card recovery to reflash the device. For large operations running thousands of units, this translates to days of downtime and manual labor.

Attack Vector 2: Remote Kill Switches

In April 2017, security researchers disclosed Antbleed, a backdoor in Bitmain's Antminer firmware. The code caused each miner to check in with a Bitmain-controlled server at random intervals of 1 to 11 minutes, transmitting the device's serial number, MAC address, and IP address. If the server responded with "false," the miner stopped hashing entirely.

The affected models included the S9, L3, L3+, T9, and R4: collectively estimated to represent up to 70 percent of active mining hardware at the time. Bitmain CEO Jihan Wu reportedly confirmed that percentage when asked. The company characterized the feature as "Minerlink," a legitimate remote management tool for hosted mining customers, and released patched firmware within days.

The deeper problem: Antbleed used no authentication. Security researcher Peter Todd noted that any attacker capable of a man-in-the-middle or DNS hijack against the check-in request could trigger the kill switch. The threat was not limited to Bitmain itself: it was exploitable by any network-level adversary.

Attack Vector 3: Covert Block Template Manipulation

Under the Stratum V1 protocol, the pool constructs the block template and sends it to miners. Miners have no say in which transactions are included. This creates a centralization chokepoint that firmware can exploit in two ways.

First, compromised firmware can silently modify the coinbase transaction within the block template, substituting the pool's payout address with the attacker's. If the miner finds a valid block, the reward goes to the wrong address. This attack is harder to execute than hashrate skimming because pools typically validate coinbase outputs, but it remains a viable vector against pools with weaker validation.

Second, and more concerning for the broader Bitcoin ecosystem: firmware could filter transactions from templates before hashing. A state-sponsored attacker embedding transaction censorship logic into firmware distributed across a significant share of hashrate could selectively prevent certain transactions from confirming. This is not a documented attack, but the technical path is straightforward given firmware's position in the mining stack.

The Closed-Source Problem

The root cause enabling these attacks is that most miners run firmware they cannot inspect. According to Michael Schmid, principal engineer at the 256 Foundation's LibreBoard project, approximately 90 percent of ASIC mining devices run single-vendor closed-source firmware with no independent audit history.

Two manufacturers dominate ASIC production. Bitmain and MicroBT together supply the vast majority of deployed mining hardware globally. Their firmware is proprietary. Miners receive compiled binaries with no source code, no reproducible build process, and until recently, no third-party security review. Newer Antminer models (S19 generation onward) include web-interface signature verification that checks uploaded firmware files before flashing, but this only verifies that firmware came from Bitmain: it does not prove the firmware is free of backdoors.

The geopolitical dimension

In November 2025, Bloomberg reported that the U.S. Department of Homeland Security launched a probe (reportedly called "Operation Red Sunset") to assess whether Bitmain machines could be remotely manipulated for espionage or used to compromise the U.S. power grid. Investigators reportedly examined chip hardware and firmware code for backdoors. A July 2025 Senate Intelligence Committee report described "several disturbing vulnerabilities" in Bitmain devices.

Bitmain called the remote-control allegations "unequivocally false." As of late 2026, DHS has not published findings, and the investigation reportedly remains ongoing. Regardless of the outcome, the probe highlights a structural risk: critical Bitcoin infrastructure depends on opaque software from a concentrated set of foreign manufacturers.

The 256 Foundation Firmware Audit

In 2026, the 256 Foundation's Red Team published the first independent security audit of major ASIC firmware. Using reverse engineering, real-time traffic capture, and share-level reconciliation, the team examined stock Bitmain firmware alongside third-party alternatives including LuxOS, VNISH, and Braiins OS.

The audit submitted 41 issue reports. Stock Bitmain firmware on the tested models showed no evidence of hashrate skimming, covert communication beacons, or other actively malicious behaviors. However, the third-party firmware options each introduced new attack vectors despite marketing themselves primarily as performance upgrades. Common findings across all firmware included:

• Unauthenticated factory APIs exposing device control
• Default credentials granting root access
• Built-in vendor SSH keys that persist across updates
• Update mechanisms that fail to verify what they install
• Paths granting root access without authentication

These are not exotic supply chain attack techniques. They are basic security failures: the same classes of vulnerabilities that would fail a routine penetration test on any enterprise system.

Firmware Attack Vectors Compared

Open-Source Firmware Alternatives

The primary defense against firmware supply chain attacks is verifiability: running firmware whose source code can be inspected, audited, and reproduced. Several projects aim to provide this.

Braiins OS+

Braiins OS describes itself as the first fully open-source Bitcoin mining firmware. The base version is open-source; the commercial Braiins OS+ edition adds proprietary autotuning algorithms. Braiins OS+ is also the most mature firmware with native Stratum V2 support, including the Job Declaration protocol that enables miner-constructed block templates.

256 Foundation LibreBoard

The 256 Foundation is developing LibreBoard, a fully open-source ASIC control board and firmware stack. The project aims to eliminate dependence on manufacturer firmware entirely by providing open hardware alongside open software. As of late 2026, the project remains in active development.

Adoption barriers

Despite the security advantages, open-source firmware adoption remains limited. Several factors slow adoption:

• Manufacturer warranty policies often void coverage if third-party firmware is installed
• Performance tuning on stock firmware is specifically optimized for each ASIC chip revision
• Large mining operations with vendor support contracts face contractual restrictions
• Open-source options support fewer hardware models than stock firmware

Stratum V2: Reclaiming Block Template Construction

Even if firmware is clean, the Stratum V1 protocol centralizes a critical function: the pool decides which transactions go into every block. The Stratum V2 protocol addresses this through its Job Declaration sub-protocol, which lets miners run their own Bitcoin node, build block templates from their own mempool, and submit those templates to the pool for validation.

This directly mitigates the transaction censorship attack vector. If miners construct their own block templates, compromised pool software cannot filter transactions. The pool still validates the coinbase transaction but cannot reject a valid template based on which transactions it includes. For a deeper analysis of how this reshapes mining centralization, see our research on Stratum V2 and mining decentralization.

Adoption progress

In May 2026, seven major pools representing approximately 75 percent of global hashrate joined the Stratum V2 Working Group, including Foundry, AntPool, F2Pool, and MARA Pool. However, joining the working group is not the same as deploying the protocol in production.

Actual Job Declaration usage remains limited. DEMAND Pool and OCEAN are the primary pools running V2 natively, together holding under 5 percent of hashrate. In June 2026, GoMining and DEMAND reportedly mined a block using a miner-constructed template through Job Declaration: one of the first documented instances of this feature in production. Bitcoin Core v30 (October 2025) added experimental V2 support, which should accelerate adoption.

Risk Matrix by Mining Operation Size

Firmware supply chain risk varies significantly with operation scale. Larger operations present higher-value targets but typically have more security resources. Smaller operations are more likely to run unaudited firmware but represent less attractive individual targets.

Detection and Defense Checklist

Mining operators at any scale can reduce firmware supply chain risk with these practices:

1. Download firmware exclusively from official manufacturer websites or verified open-source repositories. Never install firmware from forums, Telegram groups, or third-party sites.
2. Verify firmware checksums against manufacturer-published hashes before flashing. Some newer models support signature verification natively.
3. Change default SSH and web interface credentials immediately after initial setup. Disable SSH entirely if remote management is not needed.
4. Segment mining networks from corporate or home networks. Restrict outbound connections to known pool IP addresses and ports.
5. Monitor the gap between local hashrate (reported by the miner's dashboard) and pool-reported hashrate. A persistent discrepancy indicates possible hashrate skimming.
6. Reflash any used or secondhand equipment with verified firmware before connecting it to your network.
7. Run a full node and adopt Stratum V2 with Job Declaration where pool support exists, ensuring your miner constructs its own block templates.

Why Mining Firmware Integrity Matters Beyond Mining

Mining firmware security is not only a miner profitability issue. It is a base layer integrity issue that affects every protocol built on Bitcoin. If a significant share of hashrate runs compromised firmware capable of transaction censorship, the consequences cascade upward.

Layer 2 protocols depend on the ability to confirm transactions on Bitcoin L1. Lightning commitment transactions, force-close transactions, and penalty transactions all require timely L1 inclusion. Protocols like Spark rely on L1 for unilateral exit transactions that guarantee users can always withdraw their funds. If firmware-level censorship could delay or prevent these transactions from confirming, the security guarantees of every Layer 2 weaken.

This is why initiatives like Stratum V2 Job Declaration matter beyond mining economics. Distributing block template construction across thousands of independent miners, rather than a handful of pool operators running potentially compromised infrastructure, directly strengthens the censorship resistance that the entire Bitcoin ecosystem depends on.

What Miners Should Do Next

The mining industry's firmware security posture in 2026 resembles where enterprise software was a decade ago: running critical infrastructure on unaudited, unverifiable code from a small number of vendors, with limited visibility into what that code actually does.

The 256 Foundation audit is a start, not an endpoint. Miners should advocate for reproducible firmware builds, support open-source alternatives where hardware compatibility allows, and adopt Stratum V2 to reclaim control over block template construction. For developers building on Bitcoin's Layer 2 ecosystem, the Spark documentation covers how Spark's exit mechanism interacts with L1 confirmation requirements: understanding that dependency is essential context for evaluating base-layer risks like firmware compromise.

For ongoing coverage of mining infrastructure security and its implications for Bitcoin scaling, see our research on mining centralization and pool risks and our block template glossary entry.

This article is for educational purposes only. It does not constitute financial or investment advice. Bitcoin and Layer 2 protocols involve technical and financial risk. Always do your own research and understand the tradeoffs before using any protocol.