Cybersecurity · Tuesday, 25 August 2026
01 · Briefing · what happened
A poisoned code package was live for 86 minutes. Building with it was enough.
Attackers linked to North Korea slipped malware into arrayref, a free Rust part found in most Rust setups. It ran during the build, so no finished app ever had to be launched.
86 minutes
the poisoned version was online
builds started in that window are treated as compromised
245 million
lifetime downloads of arrayref
found in about 75% of cloud setups running Rust
3 days
CISA's deadline to fix the Zimbra flaw
cut from weeks in June, citing machine-written attack code
8,539
serious flaws disclosed in three months
double the same quarter a year earlier, Rapid7 found
At a glance
-
Someone using the real maintainer's account published a poisoned version of arrayref, a free Rust code part, on 20 August.
[1] -
The code was not changed. One added line pulled in a look-alike part, proc-macro1, which carried the malware.
[2] -
It ran during the build, so compiling a project was enough - the finished app never had to be launched.
[3] -
It was online for 86 minutes; two other parts by the same maintainer lasted 90 and 107 minutes.
[1] -
arrayref has about 245 million lifetime downloads and sits in roughly 75% of cloud setups running Rust, Wiz says.
[3] -
The attacker also withdrew the five previous good versions, leaving the poisoned one as the only release the tool would not flag.
[2] -
Wiz links the servers to recent North Korean attacks that poisoned shared code; Microsoft tracks the group as Sapphire Sleet.
[3] -
CISA gave US agencies three days to fix a Zimbra mail-server flaw already under attack, and ordered TrueConf and Ray fixes too.
[7] [9] [8] -
Red Hat rated a Keycloak login-system flaw 9.1 out of 10: a password reset that never needed the emailed link.
[10] -
Iran-linked hackers shut a small British power plant for four days in July; the US then sanctioned six men and charged 17 more.
[13] [15] [16] -
US agencies warned that attackers are using AI-written scripts, dressed up as monitoring tools, against Siemens plant controllers.
[17] [18] -
A health records firm revised its March breach from 350,000 people to 3.76 million, and a Texas university went offline in its first week of term.
[21] [31]
Forces in play
a trusted maintainer's account pushed poisoned Rust parts, days after the same crew poisoned free JavaScript parts the same way
machines now write working attack code in hours while a fix still waits weeks on a human maintainer
a UK power plant down four days, and a China-linked crew running five new remote-control tools across Central Asia
the Rust team deleted every poisoned version within two hours of the first report and restored the clean ones
How it unfolded
-
07:15, 20 Aug
the poisoned arrayref version goes up; a researcher reports it the same morning
[1] -
08:41
the Rust team deletes it - 86 minutes online
[1] -
20 Aug
Microsoft ships 22 more security fixes across its cloud products
[30] -
21 Aug
CISA adds the Zimbra flaw to its must-fix list, deadline 24 Aug
[7] -
24 Aug
the US sanctions six men over hacking of energy, health and finance firms
[15]
Where this points
Watch whether more of the financial firms Google named confirm break-ins like Apollo's, and whether LockBit shows any proof for its claim against U.S. Bank
Full briefing
Why nothing had to be launched
Software is assembled from thousands of free parts other people maintain, fetched automatically by a tool
That single line is the whole attack. Rust’s build tool runs a small setup script for each part while a project is being compiled
What the two accounts disagree about
The Rust Security Response Team deleted the poisoned release 86 minutes after it appeared, and says it found no evidence of actual usage
The same week, aimed at you
The rest of the week needed no flaw. UK reports of QR-code scams are up 700% in four years
The defence is the same everywhere. Confirm any request for money or a login through a number you already had, never the one the message gave you. Two findings warn against the opposite mistake: trusting a check that cannot see. University College London tested gadgets sold to find hidden cameras and trackers. Many miss them, leaving people who checked feeling safer than they are
02 · Lesson · why it matters
The harm was done before anyone ran anything
We put our checks where a thing gets used. This one did its work while it was being made, so every check was standing in the wrong moment.
How it works
- Software is assembled from free parts
- A part may run a script while it is built
- That script runs on the builder's machine
- The theft finishes before anything ships
- Every check is aimed at the finished thing
- So the check looks, and sees a clean app
The twist
The finished thing can be genuinely clean and the harm already complete, because the harm happened while it was being made and nobody was watching that moment.
Where you've seen this
Food
a batch is contaminated at the plant; testing the packet in the shop tests the wrong moment
Concrete
the steel inside is checked before the pour, because afterwards every wall looks the same
Lab evidence
the sample can be tested perfectly, but only the record of who handled it says what the result means
A used car
the paint tells you nothing; the service history is the only view of how it was treated
The catch
Watching the making only works where the making is written down. Where nothing records what was pulled in, there is nothing to inspect.
Full lesson
Eighty-six minutes
The poisoned file sat on the shelf for eighty-six minutes on a Thursday morning. Then it was gone, and the shelf looked exactly as it had before.
In that window, nobody had to be tricked. Nobody clicked a bad link or typed a password into a fake page. A machine somewhere ran the command it runs every day - fetch the parts, build the project - and the theft happened inside that ordinary act.
The check is a place, and also a time
We think of a check as a thing you do. It is more useful to think of it as a place you stand.
Almost every security check stands at the moment of use. Scan the finished program. Watch what it does when it runs. Look at what leaves the network. That is a sensible place to stand, because using a thing is when it can hurt you.
This attack moved the harm upstream, to the moment of assembly. The setup script ran while the software was being put together, on the machine doing the putting together. By the time anything was finished, the passwords were already gone.
And here is the part that stings: the finished program was clean. Not disguised, not obfuscated - actually clean. Every check that looked at it reported the truth. It just answered a question nobody should have been asking.
Where you already know this
A food inspector who only tests the sealed packet cannot see what happened at the plant. That is why inspection lives at the plant.
A building inspector looks at the steel before the concrete is poured, because a wall with the steel left out looks identical to a wall with it in.
A laboratory can test a sample perfectly and tell you nothing, if there is no record of who handled it on the way. The test is fine. It is measuring a moment after the one that mattered.
In each case the honest check is not a better instrument. It is the same instrument, standing earlier.
You are downstream of a build you never saw
Nothing you own was written from scratch. Your banking app, your phone’s operating system, the till at the shop - all assembled from thousands of free parts, fetched automatically, on machines in rooms you will never enter.
The part at the centre of this had been downloaded about 245 million times. Nobody decides to trust it. It arrives because something else asked for it, which arrived because something else asked for it.
That is not carelessness. It is the arrangement that makes software cheap, and it mostly serves the people under it. Those 245 million downloads are 245 million times someone did not have to write that code. The same arrangement decides, in advance, that trust travels by name. A name is a very small thing to hang a chain on. Notice that, and you also notice that the maintainer whose account was used did nothing wrong.
Watching the making has a price
Standing earlier is not free, and it is not always possible. To inspect the making you need a record of the making - what was pulled in, from where, on what day. Where that record exists, it can be read. Where it does not, there is nothing to stand in front of.
That is why the practical answer here is dull and administrative: keep a written list of the parts, pin them, and read the list when it changes. It is filing. Filing is what makes an earlier check possible at all.
The window and the reach
Eighty-six minutes is a small window. The reach was not small.
Every person in this chain was doing something reasonable. The maintainer kept a useful library going for years. The teams that built that morning ran a command they run every day. The scanners looked at what they were built to look at and reported honestly.
The failure is not in any of those seats. It is in the distance between them - in the fact that no one seat could see both the moment the harm entered and the moment anyone thought to look. That distance is the normal condition of anything assembled by many hands, which is nearly everything you use.
03 · Lab · your turn
Where the check stands
Rehearse placing a single inspection and feel why a check aimed at the finished thing cannot see harm that happened while it was made.
04 · Hope · carry this
It lasted eighty-six minutes because a researcher who owed nobody anything reported it the same morning. Most of what holds this together is people deciding to tell someone.
More from Cybersecurity