The world''s largest electronics manufacturer was hit by ransomware. But what makes this case singular is not the size of the victim — it is the bug in the encryptor that turns extortion into pure destruction. According to Coveware''s analysis, the Nitrogen ESXi encryptor corrupts its own public key during encryption. The result: decryption is mathematically impossible, regardless of payment. Not even the attackers can recover the files. At Tech86, we see this case as an unequivocal demonstration that paying ransom was never a guarantee of recovery — and now, in specific scenarios, it is a mathematical guarantee of failure.
The Foxconn attack: timeline and impact
According to the Nitrogen leak site, Foxconn was listed on May 11, 2026. Foxconn confirmed the attack on May 12, after initially calling it a "technical problem" in a statement to press. The Mount Pleasant, Wisconsin factory ground to a halt: according to a worker account verified by DysruptionHub, Wi-Fi down at 7 AM, employees sent home at 11 AM, time sheets recorded on paper.
Nitrogen claims to have stolen approximately 8 TB and 11 million files — this is the group''s claim, not independent verification. Samples on the leak site include Foxconn engineering documents and, according to AppleInsider, Apple server schematics related to data center infrastructure, not consumer product designs. Foxconn has not confirmed that customer data was accessed. The customer names — Apple, Nvidia, Intel — are an extortion tactic: maximizing pressure regardless of the actual content of the files.
Context: this is the 4th time Foxconn has been hit by ransomware. According to public records, DoppelPaymer in 2020, LockBit in 2022, LockBit in 2024 targeting subsidiary Foxsemicon, and now Nitrogen in 2026. The Wisconsin plant was recently expanded with a US$ 569 million investment and a partnership with OpenAI for AI infrastructure hardware design and manufacturing.
The bug: when encryption self-destructs
The technical detail that sets this attack apart is the analysis Coveware performed on the Nitrogen ESXi encryptor, published on February 2, 2026. The reverse engineering revealed a critical bug in the encryptor''s memory management.
The public key is stored as a stack variable at rsp+0x20. Another QWORD variable at rsp+0x1c overwrites 4 bytes of the public key with zeros. The corrupted key is then used in the Curve25519 key exchange to encrypt each file. Since the corrupted key was never derived from a valid private key, there is no corresponding private key. Not even the attackers have it. Decryption is mathematically impossible.
This bug affects only the ESXi variant. The Windows variant works correctly. Organizations must identify which variant encrypted their files before assuming recovery is impossible.
The approximately 3-month window: disclosure without correction
Coveware published this analysis on February 2, 2026. The Foxconn attack began in May. Approximately 3 months passed between the public disclosure of the bug and the attack. Nitrogen either did not fix the bug or does not care. For victims with ESXi encryption, paying the ransom solves nothing — the money goes and the files remain inaccessible.
This reveals something fundamental about the ransomware-as-a-service business model: operators do not necessarily care about product functionality. The encryptor is a means of pressure, not a reliable engineering tool. When the bug prevents decryption, the attacker can still extort with the threat of data leaks — but the promise of decryption is false.
The vector: malvertising as the entry point
The initial access vector was not confirmed by Foxconn. Nitrogen is known for malvertising: malicious ads on Google and Bing for trojanized installers of IT tools such as AnyDesk, WinSCP, PuTTY, FileZilla, and Cisco AnyConnect. This is the group''s documented modus operandi, though not confirmed in this specific attack.
What matters operationally: IT teams searching for legitimate tools on search engines are the vector. This is not sophisticated phishing — it is exploitation of trust in software distribution channels. EDR with behavioral detection identifies the execution of anomalous payloads even when the initial vector appears legitimate.
The operational lesson: paying is not a strategy
If the encryptor has a bug, paying does not help. If the attacker does not fix the bug approximately 3 months after public disclosure, the extortion business model breaks. And the victim is left without files and without money.
Foxconn is an extreme case by scale, but the pattern applies to any organization. The decision to pay ransom has historically depended on the attacker''s good faith — that the decryptor works, that data does not leak afterward, that the key is delivered. When the encryptor itself is defective by design or by negligence, that dependency reveals itself for what it is: a gamble.
At Tech86, we maintain that the response to ransomware starts before the attack: asset inventory, tested offline backups, EDR with behavioral detection, and continuous monitoring. When the encryptor fails, these are the only things that work.