Sometime in May, a group of attackers did something quietly audacious. They pushed a software update called FortiEndpoint_Patch.exe to a fleet of corporate laptops. It looked like a routine Fortinet patch. It arrived through the same management console the IT team uses every week. The endpoints accepted it, because everything about it said “this is your security vendor doing security vendor things.”
It was malware. An infostealer that raided saved passwords, cookies, and autofill data out of every browser it could find.
The way in was a vulnerability in FortiClient EMS, Fortinet’s endpoint management server, tracked as CVE-2026-35616.¹ That server sits at the center of the deployment and tells every managed device what to do. Compromise it and you do not hack one laptop. You inherit the authority to instruct all of them at once. Arctic Wolf caught the campaign.² CISA had already added the bug to its Known Exploited Vulnerabilities list back in April.³
I want to sit with the uncomfortable part, because most of the coverage races past it.
The patch was already late
There is a number I cannot stop thinking about. Mandiant’s latest M-Trends report puts the average time-to-exploit at “negative seven days”.⁴ Read that again. On average, attackers are exploiting vulnerabilities about a week before the vendor ships the fix. In 2018 that number was 63 days. It has gone negative.
If exploitation precedes the patch, then “patch quickly” is not a strategy. It is a wish. You are running a race whose starting gun fired last week, and the prize for finishing is that you were merely average.
This is not a Fortinet problem. The four most-exploited vulnerabilities of 2024 were all edge devices. Mandiant says network and security appliances were attackers’ favorite entry point for the fifth year running.⁵ Ivanti, Citrix, Palo Alto, Cisco, SonicWall: the same story, different logo, on a loop.
There is an irony here that deserves to be said plainly. The boxes we buy specifically to protect the perimeter have become the perimeter’s softest target. They face the public internet by design. They run with deep privilege by function. And most of them cannot run the detection tools we put on everything else, so when one is breached, we often cannot even see it.
“Undefendable” is the wrong word
I keep hearing this class of vulnerability described as undefendable. I understand the despair. I also think the word is wrong, and a little dangerous, because it leads good teams to give up on the part they can actually control.
These vulnerabilities are undefendable by patching. They are very defendable by architecture.
The difference is what you choose to defend. If your defense is “apply the fix faster than the attacker,” you lose, for the reasons above. If your defense is “make the attack impossible to express,” you change the game. For this incident, three architectural moves do exactly that.
Take the management plane off the public internet. CISA’s recent binding directive on edge devices says this out loud.⁶ ⁷ A console reachable from anywhere is reachable by everyone.
Replace shared secrets with hardware-rooted identity. If the management interface only answers to a client holding a certificate whose private key lives in a TPM or hardware security module, an unauthenticated request never reaches the vulnerable code path. There is no password to bypass and nothing to steal that works twice.
Sign the code and check the signature before it runs. A fake FortiEndpoint_Patch.exe carries no valid vendor signature. On an endpoint that refuses to run unsigned code, the clever fleet-wide push simply does not execute. The attacker’s best move dies on arrival.
This is the part of my job I actually believe in. Not faster patching. Foundations that make whole categories of attack stop working.
The honest limit
Here is what I will not pretend. The architecture above would have blocked the way in and the fleet-wide spread, and it would have made any stolen passwords worthless going forward. It would not have stopped the infostealer from grabbing the session cookies already sitting in a browser on a machine it reached. Cookie and token theft after the fact is an endpoint-detection and session-binding problem, not a certificate problem.
I say that out loud because the moment a security person promises you a silver bullet, you should keep a hand on your wallet. Hardware identity and code signing are the authentication and integrity layer of a defense-in-depth posture. They are necessary. They are not everything.
Is AI behind this?
Everyone asks, so let me be precise, because the honest answer is more useful than the scary one.
Is AI being used in offense? Yes, in specific, confirmed ways. AI agents have found real zero-day vulnerabilities; Google’s “Big Sleep” did exactly that in production code.⁸ An autonomous system topped a major bug-bounty leaderboard by volume.⁹ State actors have wired language models into live malware to generate commands on the fly.¹⁰
Is AI running these attacks end to end, or writing the malware itself? Mostly no, and the evidence is thinner than the headlines. The one widely cited “AI ran most of the operation” claim came with a quiet footnote that the model kept hallucinating and overstating its own results.¹¹ And this particular infostealer, EKZ, is almost charmingly crude. It dumps stolen data to a local file and has no real way to send it anywhere on its own. That is not the work of a superintelligence. That is commodity crime.
The FortiClient EMS attack is not an AI story. It is an architecture-and-identity story wearing this month’s CVE number.
Where I land
The edge is not undefendable. It is undefendable by the one method we keep reaching for. The boxes on the boundary will keep falling, faster than anyone can patch them, and the only durable answer is to stop treating a compromised box as automatically trustworthy and start demanding cryptographic proof of who, and what, we are running.
Negative seven days is not a patch-management metric. It is a tap on the shoulder telling us the model is wrong.
I write about trust, identity, and the security of connected devices here. If “patch faster” still strikes you as viable in 2026, I would genuinely like to read the case for it in the comments.
Sources
¹ Fortinet PSIRT advisory FG-IR-26-099 (CVE-2026-35616). fortiguard.fortinet.com/psirt/FG-IR-26-099
² Arctic Wolf Labs, “FortiClient EMS exploited via CVE-2026-35616 to deliver EKZ infostealer disguised as a Fortinet patch” (May 2026). arcticwolf.com
³ CISA Known Exploited Vulnerabilities Catalog, added April 6, 2026. cisa.gov/known-exploited-vulnerabilities-catalog
⁴ Mandiant, M-Trends 2025 / 2026 (mean time-to-exploit). cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
⁵ Google Threat Intelligence Group, 2024 zero-day analysis (security and networking appliances). cloud.google.com/blog/topics/threat-intelligence
⁶ CISA / Five Eyes, “Security Considerations for Edge Devices” (February 2025). media.defense.gov
⁷ CISA Binding Operational Directive 26-02. cisa.gov
⁸ Google Project Zero, “Big Sleep” agent (CVE-2025-6965). projectzero.google
⁹ XBOW, autonomous penetration testing (HackerOne US leaderboard). xbow.com
¹⁰ Google Threat Intelligence Group, PROMPTSTEAL / LAMEHUG used by APT28. cloud.google.com/blog/topics/threat-intelligence
¹¹ Anthropic, “Disrupting AI espionage” (GTG-1002). anthropic.com/news/disrupting-AI-espionage
About the author
Tim McAllister is Regional Field CTO at DigiCert, in the Office of the CTO. He works with OEMs and enterprises on device trust, post-quantum readiness, and CRA/RED compliance, and sits in the standards bodies shaping it (NIST, SAE EVPKI Consortium, CSA Matter, CharIN). He writes here about trust, identity, and the security of connected devices. Views are his own.
How this was made: the companion video was produced with Remotion (motion graphics and render), Google Gemini 2.5 Flash Image (cinematic stills), and TTS.AI’s Kokoro model (the “George” British narration voice), orchestrated with Anthropic’s Claude.