The Firewall Is the Vulnerability, AGAIN

30,000 compromised Fortinet boxes, three fresh FortiSandbox CVEs, and a problem the security industry keeps rediscovering: it cannot keep attackers out of its own front door.

Another week, another version of the same story. Eduard Kovacs at SecurityWeek reported that three recently patched Fortinet FortiSandbox vulnerabilities (CVE-2026–39808, CVE-2026–39813, and CVE-2026–25089) are being exploited in the wild. One is an authentication bypass. One is OS command injection. The third lets a remote, unauthenticated attacker run commands on the box. In the same news cycle, SOCRadar disclosed FortiBleed: more than 30,000 compromised Fortinet firewalls and VPN gateways across 190-plus countries, pulled into a credential database that uses each cracked device to crack the next one.

Look at what is not in that summary. No quantum computer broke an RSA key. No AI agent invented a new exploit class. No nation-state spent a chain of four zero-days. Attackers used authentication bypass, command injection, and password guessing. These are the first things you learn in the field, and the first things you are supposed to defend against.

There is a lot of energy in security right now pointed at the frontier: AI-assisted attack tooling, post-quantum cryptography, the prospect of attacks that move at machine speed. Those concerns are legitimate. But the edge of the network is being pulled open today using bugs that are older than most of the products they live in. The hard future problems are not what is hurting us this quarter.

And Fortinet is not alone in this.

It is tempting to read the Fortinet headlines and decide one vendor is careless. The pattern says otherwise. Look across the companies whose whole pitch is keeping attackers out, and the same failures turn up everywhere.

Fortinet. Years of it. A FortiOS SSL-VPN path traversal that leaked credentials and stayed exploited long after the patch shipped. A FortiOS and FortiProxy authentication bypass that handed attackers admin access. SSL-VPN memory bugs that turned into pre-auth remote code execution. A FortiManager flaw that let managed devices get hijacked in bulk. Now FortiSandbox and FortiClient EMS.

Palo Alto Networks. A PAN-OS GlobalProtect command injection, chained with a file-write bug into unauthenticated RCE and exploited as a zero-day before any patch existed. A management-interface authentication bypass not long after.

Cisco. Two zero-days in the IOS XE web management interface, back to back. The first created a rogue admin account. The second escalated privileges and dropped an implant. Tens of thousands of devices were implanted within days. The ASA and FTD VPN appliances have their own version of this story.

SonicWall. SMA and firewall bugs that became ransomware entry points, with Akira and others getting in through SSL-VPN access. Pre-auth flaws, reused credentials, the usual.

Ivanti. Same disease, worth naming. A Connect Secure authentication bypass chained to command injection, mass-exploited, then exploited again after the first fix turned out to be incomplete, with still more bugs found in the patched code.

Different companies. Different codebases. Founded decades apart. The failures rhyme: pre-authentication remote code execution and authentication bypass, on the internet-facing management and VPN interfaces, recurring every few months for years.

When five separate vendors fail the same way, that is not five accidents. It is a property of the category.

Four reasons, and they feed each other.

First, the code is old, large, and written in C and C++. These platforms run decades deep. FortiOS, PAN-OS, IOS XE: millions of lines of C built up over twenty-plus years, parsing hostile input straight off the internet. In that setting, buffer overflows and use-after-frees are not rare events. They are the weather. A VPN parser written in 2019 does not get safer because the 2026 datasheet says "AI-powered."

Second, the attack surface faces the internet on purpose. A firewall or VPN concentrator exists to terminate untrusted connections from anywhere. The management page, the VPN portal, the API: reachable, often on the same plane, and far too often exposed straight to the open internet. The box that is supposed to be the hardest target is, by its job description, the most exposed one.

Third, the bugs are old and dull. Command injection, where user input gets pasted into a shell command. Authentication bypass, where a logic error skips the check. Path traversal, where ../../ walks into a credentials file. Default and reused passwords. None of this is advanced. All of it is exactly what code review, fuzzing, and static analysis are built to catch. When these reach production, the development process failed, not the threat model.

Fourth, patching these boxes is hard in practice. They sit at choke points. Maintenance windows are rare, downtime hurts, and the people running them are cautious for good reason. So even after a fix ships, the vulnerable population stays large for months. That gap is what FortiBleed lives on. "We patched it," from the vendor, and "we are safe," from the customer, can be a full quarter apart.

None of this is a secret inside these companies. The incentives just point elsewhere. Shipping features pays. Shipping a fast patch after a CVE pays. Quietly not having the bug in the first place pays nothing you can put in a keynote.

This is the part that should bother anyone who reads the spec sheets. These are not cheap, memory-starved IoT gadgets. Enterprise appliances increasingly ship with TPM 2.0 modules, hardware secure elements, and dedicated crypto engines on the board. The pieces for a hardware root of trust are already sitting there.

In principle, that hardware could give you:

• A device identity bound to the silicon, unique and hard to forge, so an appliance can prove what it is and a stolen config cannot be cloned onto someone else's server.
• Keys that never leave the secure boundary. VPN private keys, signing keys, and session secrets created and used inside the secure element, so a software compromise does not automatically hand over the crypto material.
• Measured, attested boot, so an implant (the Cisco IOS XE move) breaks attestation and shows up, instead of surviving quietly across reboots.
• Administrative login backed by hardware and resistant to phishing, instead of passwords that end up in someone's leaked database.

So why is this not normal across the category?

Here is where the original pitch for this piece is half right. The hardware does not fix the bugs being exploited. A TPM does nothing about command injection in a web script. A secure element does not patch a broken authentication check. An HSM cannot make a fifteen-year-old C parser memory-safe. A hardware root of trust protects keys, boot integrity, and identity. The CVEs in the headlines are flaws in the application, on the request path, and the attacker is already running code as the application, inside the trust boundary, before any of that cryptography gets a vote.

That distinction keeps getting blurred, usually in marketing. Hardware limits the blast radius. It does not stop the break-in. Both matter, and selling one as if it were the other is part of how the industry ended up here.

A secure-by-design appliance needs both halves. Get rid of the bugs, and contain the ones that slip through anyway. Which brings us to what that actually looks like.

1. Make it memory-safe and small. Write new network-facing code in memory-safe languages, fund a real plan to retire the legacy C on the request path, and cut the attack surface to the bone. Dead protocols off by default. Every code path kept alive "for compatibility" is attack surface kept alive.

2. Shut the doors and force strong login. A management plane that cannot reach the open internet without someone deliberately, and visibly, overriding that default. Phishing-resistant multi-factor authentication on every admin path, with no password-only fallback, anchored in the hardware the box already ships with. This alone would have starved most of these campaigns.

3. Use the silicon you already paid for. Hardware-bound identity, keys that stay inside the secure element, and attested boot that makes implants loud instead of silent. This will not prevent the bug. It keeps the bug from becoming total, silent, permanent ownership of the device and its keys.

4. Assume the front end falls, and make shipping the bug expensive. Least-privilege internals, so one web-process flaw is not instant root. Fuzzing, static analysis, and genuine outside review in the build pipeline, with the authority to hold a release. And from the outside, regulation or liability that puts the cost of shipping the bug on the vendor that shipped it, not only on the customer who runs it.

Notice that these vendors sell zero trust and least privilege as products. They apply far less of it to the products doing the selling.

Not capability. Incentives. A few reasons, strongest first.

Rewriting a twenty-year-old C codebase in a memory-safe language is a multi-year program that costs a fortune and ends with no new feature to show for it. Markets reward quarters, and that work does not fit in a quarter.

Backward compatibility traps everyone. Customers run old configs, dead protocols, and integrations nobody wants to break. So the old code stays, and so does its attack surface.

Locking down the management plane and forcing MFA creates support tickets. Customers who exposed the interface to the internet for convenience complain loudly when that stops. The friction is immediate and lands on sales. The CVE lands on the customer six months later, and the vendor has learned to ride those out.

Secure-by-design does not demo. "We rewrote the VPN parser in Rust and nothing visibly changed" loses every bake-off to a competitor's new dashboard.

And the cost of a breach lands on the customer first. When FortiBleed pulls in 30,000 boxes, the operational, legal, and reputational pain hits the organizations running them, not, at least at first, the vendor that shipped the flaw. The party best placed to fix the root cause is the one least exposed to the consequences. That misalignment is the real clock behind the every-few-months rhythm.

CISA's Secure by Design pledge exists to change that math. It is voluntary, and the rate at which this keeps happening tells you what a voluntary pledge weighs against a roadmap.

For the vendors. Emergency engineering, incident response, the PSIRT treadmill, and slow damage to the one thing a security company cannot fake: trust. Every "patches exploited flaw" headline is a small withdrawal from a brand whose entire promise is safety. So far the market has been forgiving. Switching costs are high, the products are wired deep into networks, and the alternatives carry the same disease, so the punishment stays mild. That forgiveness is itself part of the problem, because it takes the pressure off the rebuild. The bill that is coming is regulatory: secure-by-design requirements, software liability, and procurement rules that treat a vendor's security history as a gate rather than a footnote.

For the customer. This is where it gets concrete and immediate. A compromised firewall is not a compromised laptop. It is the device sitting across all your traffic and terminating your remote access. Take it over and you get credential harvesting, which is FortiBleed's whole design, plus traffic interception, a path into the internal network, and a quiet, persistent vantage point. The follow-on costs: incident response, rebuilds, regulatory disclosure, breach notifications, ransomware, and the slow bleed of credentials leaving the building for months before anyone notices.

For the supply chain, which the headlines undersell. FortiBleed reportedly reached Foxconn, Samsung, Comcast, Siemens, Lenovo, PwC, Accenture, and Oracle: manufacturers, a carrier, and consultancies that operate inside thousands of other companies' networks. SOCRadar also found credentials for what looked like a defense-industry VPN endpoint. Compromise the edge of an integrator or a manufacturer and you have not breached one company. You have picked up a trusted way into everyone downstream. The device that was supposed to guard the perimeter becomes the route into perimeters nobody listed in the original disclosure. One owned box, many victims.

We do have hard problems coming. AI-scale offensive operations are real. So is the eventual threat quantum computing poses to today's cryptography. Both are worth preparing for.

But nobody has earned the right to obsess over the frontier while unauthenticated strangers are still walking into the management interface of a firewall. Thirty thousand owned Fortinet boxes, three fresh FortiSandbox CVEs, and a credential harvester that grows itself are not a frontier problem. They are a fundamentals problem, the basics, repeating every few months across every major vendor in the category, on hardware that already carries the parts to do better.

The silicon to limit the damage is already in the box. The engineering to remove the bugs is well understood. What is missing is a reason to spend the slow, unglamorous years doing both. Until that reason shows up, whether the market finally punishes the failure or a regulator does, the safest assumption is the one FortiBleed already runs on: the box at your perimeter is not protecting you. It is the way in.

Spot an error, disagree, or have a 2 a.m. story about patching one of these boxes? Reply and tell me.

Tim McAllister_ is Regional Field CTO at DigiCert, leading customer-facing technical strategy for device trust, PKI, and post-quantum cryptography. He participates in NIST, SAE EVPKI, Matter, and CharIN standards bodies. Views are his own._

• Eduard Kovacs, "Recently Patched Fortinet FortiSandbox Vulnerabilities in Hacker Crosshairs," SecurityWeek, June 17, 2026. Covers CVE-2026–39808, CVE-2026–39813, CVE-2026–25089, plus FortiClient EMS CVE-2026–21643 and CVE-2026–35616.
• Defused and KEVIntel: honeypot and in-the-wild exploitation telemetry, as cited by SecurityWeek.
• SOCRadar: analysis of the "FortiBleed" campaign (30,000-plus compromised Fortinet devices across 190-plus countries).
• Bob Diachenko and Hudson Rock: independent monitoring of the FortiBleed campaign and affected organizations.
• Fortinet FortiOS SSL-VPN path traversal / credential disclosure: CVE-2018–13379.
• Fortinet FortiOS and FortiProxy authentication bypass: CVE-2022–40684.
• Fortinet FortiOS SSL-VPN memory corruption / pre-auth RCE: CVE-2023–27997 ("XORtigate") and CVE-2024–21762.
• Fortinet FortiManager device-management flaw ("FortiJump"): CVE-2024–47575.
• Palo Alto Networks PAN-OS GlobalProtect command injection: CVE-2024–3400. Management-interface auth bypass: CVE-2025–0108 (chained with CVE-2025–0111).
• Cisco IOS XE web UI zero-days: CVE-2023–20198 and CVE-2023–20273.
• SonicWall SonicOS access-control flaw linked to Akira ransomware: CVE-2024–40766. SMA pre-auth flaw: CVE-2021–20016.
• Ivanti Connect Secure authentication bypass and command injection: CVE-2023–46805 and CVE-2024–21887.

Note: the CVE-2026 identifiers, the FortiBleed figures, and the list of affected organizations come from the June 2026 reporting cited above. The earlier CVEs are included as documented precedent for the same classes of vulnerability across vendors.

Originally published at https://timmcallister.substack.com.