Can software physically break hardware? A field guide to what “damage” actually means

The short answer is yes: software can cross into the physical world and permanently damage hardware.

The important answer is more constrained. The strongest demonstrations depend on particular hardware, particular control paths and particular weaknesses. A CPU damaged through a server power-management interface is not the same result as a modem made temporarily unusable by corrupted flash. A remote DRAM bit flip is a physical fault, but it is not proof that the memory chip was permanently destroyed.

The word “bricked” hides those differences. If we want useful security claims, we need a better map.

KA-SAT incident overview — Viasat, 2022

Throwhammer — USENIX ATC, 2018

Silicon Heist — USENIX Security, 2026

PMFault — Chen and Oswald, 2023

BadPower — Tencent Xuanwu Lab, 2020

“Bricked” is an operational description, not a diagnosis

A device can disappear from a network, fail to boot or be cheaper to replace than repair without suffering material damage.

The KA-SAT incident is the cleanest counterexample. Tens of thousands of modems dropped offline after an attacker reached a trusted management segment and issued commands that overwrote key flash data. The incident was consequential enough that nearly 30,000 replacement modems were shipped. Yet Viasat reported no impact to electrical or electronic components, no compromise or tampering with the modem software or firmware images, and said a factory reset could fully restore the devices.

That does not make the incident minor. It makes the failure mode digital corruption rather than physical destruction.

Read Viasat's KA-SAT incident findings

Packets can cause physical faults

It is too broad to say that a remote hardware effect always requires prior control of a power-management component.

Throwhammer showed that network traffic could induce Rowhammer bit flips on a susceptible RDMA-enabled system without first running attacker code on the target. The packets caused memory activity; the hardware's disturbance vulnerability supplied the physical effect.

That is a hardware-level fault with a remote trigger. But a flipped bit is not the same evidence as permanent material degradation. The distinction matters because the remediation, safety consequence and claim of persistence are all different.

Read Throwhammer at USENIX

Software becomes physically dangerous when it reaches an actuator

The clearest permanent-damage demonstrations have a digital control path connected to energy delivery.

In PMFault, the researchers used weaknesses around a server motherboard's management and power-control interfaces. They showed that a privileged software adversary could manipulate CPU voltage and permanently damage Intel Xeon CPUs on the tested susceptible platform without physical access to the motherboard or BMC login credentials.

BadPower crossed the same boundary through a different interface. The researchers found fast-charging products whose firmware-update mechanisms could be abused to change power-delivery behaviour. In their testing, many receiving devices suffered irreversible component damage; devices with stronger over-voltage protection sometimes resisted it.

Neither result creates a universal “destroy hardware” instruction. Each depends on the architecture exposing a controllable physical process and on protections failing to keep that process inside a safe envelope. BadPower is not evidence that ordinary USB data or Ethernet packets carry destructive power.

Read PMFault's peer-reviewed abstract and paper

Read Tencent Xuanwu Lab's BadPower disclosure

Permanent configuration is not necessarily material damage

Programmable hardware adds another kind of permanence.

Silicon Heist showed how a regular cloud FPGA user could escalate to low-level configuration and debugging interfaces. Those capabilities reached one-time-programmable eFuses. Malicious security settings could prevent the owner from reconfiguring affected FPGA regions without the required keys. The paper describes a ransomware scenario in which obtaining those keys could restore operation.

The researchers did not irreversibly program Amazon's devices. They limited cloud work to non-destructive operations, tested the irreversible step locally, disclosed the issue, and reported that AWS mitigated it before publication.

Calling this material damage loses the most interesting point. The component can remain physically intact while irreversible configuration changes who can use it. Lockout is a security and ownership failure with its own evidence standard.

Read Silicon Heist's ethical and disclosure record

What the network changes—and what it does not

A network transports information. The receiving system decides what physical activity follows: memory access, power negotiation, motor control, optical transmission or something else.

That means “it arrived over a network” does not make the outcome purely digital. Throwhammer used packet delivery to produce memory activity that exposed a hardware weakness. Industrial control systems can translate remote commands into mechanical action: the controlled 2007 Aurora test damaged a generator, although the later DOE/NERC report is explicit that the test did not use an internet connection or traditional IT vulnerabilities.

It also means the internet is not a magic energy pipe. A sender does not choose arbitrary voltage, optical power or temperature at every router and endpoint. A permanent-damage claim still needs a specific causal chain from input, through a reachable local control or workload, to a physical condition that exceeds the component's limits.

Read the DOE/NERC report's account of the Aurora test

A better test for extraordinary hardware claims

When someone says software “destroyed” or “bricked” hardware, ask four questions:

• What changed: service availability, stored data, live computation, security configuration or physical material?
• What was the access path: public request, authenticated management plane, privileged local software, exposed hardware interface or physical connection?
• What remained after power-cycle and valid recovery? A persistent symptom is not automatically permanent material damage.
• What evidence separates replacement from necessity? Fleet operators often replace recoverable devices because it is faster.

Those questions do not minimise digital attacks. They make the result legible enough to defend against.

The defensible verdict

Software-induced permanent material damage has been demonstrated on specific systems. Network-originated interactions have also caused hardware-level faults without prior attacker code on the target. Communication endpoints have real physical limits, and cyber-physical control can damage machinery.

What is not established is a general public-internet payload that can physically destroy arbitrary computers, Ethernet interfaces or fibre links. The missing step is always concrete: which input reaches which local physical process, through which permissions and protections, with what evidence of lasting material change?

That narrower answer is less cinematic. It is also much more useful.

Method and limits

This article is a targeted synthesis of published primary sources, not a new experiment, a newly disclosed vulnerability, an exploit or a measurement of product efficacy. It intentionally omits destructive parameters, procedures and target-selection details. Historical demonstrations are not claims of current exploitability or population-wide prevalence.