# When Your Firewall Is the Open Door: Fortinet's August Authentication Reckoning
Fortinet shipped patches Wednesday for eight vulnerabilities across its product stack, but the two that should be keeping network administrators awake are both authentication failures — the kind where an attacker doesn't need to break down the door because the lock was never working right.
The company says none of these are being exploited in the wild. That claim will age poorly if organizations don't move fast.
## The FortiWeb Wildcard Problem
CVE-2026-26035 is the kind of vulnerability that gets discovered because someone actually read the documentation and asked the uncomfortable question: what happens if you combine this non-default feature with a network-accessible GUI?
Here's what happens: when FortiWeb administrators enable the wildcard setting for remote authentication — a feature that lets any username on a remote authentication server match the system's Remote User account — they're essentially telling the authentication system to accept credentials it cannot verify. An unauthenticated attacker on the network can log into the FortiWeb GUI or CLI with a completely random username and password.
Let that sit for a moment. The authentication mechanism that is supposed to protect your web application firewall can be reduced to theater by a feature that exists in the product's own admin interface.
Fortinet's framing that this requires "specific, non-default settings" is technically accurate and practically misleading. Enterprise deployments are not static lab environments. Features get enabled for legitimate reasons — a specific integration, a support ticket workaround, a configuration migrated from an older version. Non-default doesn't mean rare in production.
The fix is in FortiWeb versions 8.0.3, 7.6.7, 7.4.12, and 7.2.13. If patching immediately isn't feasible, disabling the wildcard setting closes the hole.
## FortiManager: Impersonating Your Own Network
The FortiManager bug, CVE-2026-70468, has a narrower attack surface but a more unsettling implication. This is an authentication bypass that lets a remote attacker impersonate any FortiGate device managed by that FortiManager instance.
Two conditions apply: a specific CLI option must be configured, and the attacker needs a valid certificate. That second requirement sounds like a meaningful barrier until you remember that certificate theft and misuse are table stakes for sophisticated adversaries, and the valid cert doesn't need to be for *your* environment — it needs to be one the system will accept.
What an attacker can do once they've successfully impersonated a managed FortiGate is, generously, not fully detailed in Fortinet's advisory. But the attack surface of a management platform that believes it's receiving legitimate telemetry and commands from a managed device it actually isn't is large. Configuration exfiltration, false status reporting, and lateral positioning are all plausible follow-ons.
## FortiClient's DNS Problem
Third on the severity list, and arguably the most interesting from an attack-chain perspective: CVE-2026-70465 is a high-severity buffer overflow in FortiClient for Windows that triggers when an unauthenticated attacker can modify or craft DNS responses.
DNS poisoning as a vector for endpoint compromise is a pattern that never fully goes away. It fits neatly into adversary-in-the-middle scenarios — compromised hotel Wi-Fi, poisoned enterprise resolvers, BGP hijacking — and the fact that it doesn't require authentication makes it accessible to a broad range of threat actors, not just sophisticated nation-state operators.
Endpoint security software is a high-value target precisely because it typically runs with elevated privileges. A buffer overflow in that context often means full code execution at a privileged level. This is the one in this batch that deserves the most urgency from organizations with distributed workforces or users connecting from untrusted networks.
## What Else Shipped Wednesday
Fortinet's full patch release also addressed:
## HackWire Analysis
Fortinet has been here before, and often. The company's PSIRT page is one of the more active in enterprise security, and that's not entirely a criticism — some vendors are prolific patchers because they're also prolific at finding their own bugs before attackers do. But the authentication failures keep coming.
The FortiManager impersonation bug in particular deserves more scrutiny than it's getting. When a management plane — the system through which you push config, validate device health, and respond to threats — can be convinced it's talking to a legitimate device when it isn't, you've lost the ability to trust the information your security operations are built on. That's not a single-device compromise. That's a trust-layer problem.
The pattern here fits a broader trend that's been building for three years: attackers are increasingly targeting the security tooling itself rather than the perimeter it protects. VPN gateways, firewall management consoles, endpoint agents — these all run with elevated access and trust, and compromising them is often worth more to an attacker than compromising the assets they're meant to protect. Fortinet isn't uniquely vulnerable in this respect, but it is the most frequently targeted vendor in the management-plane attack category based on incident data from 2024 and 2025.
For defenders: patch FortiClient first if you have a distributed workforce. The DNS vector is plausible in too many real-world scenarios to deprioritize. FortiWeb wildcard check second — an audit of which deployments have that setting enabled should take less than an afternoon. FortiManager impersonation third, but only because the cert requirement adds some friction for commodity attackers; sophisticated operators won't be slowed by it.
One thing missing from broader coverage of this patch batch: no guidance on detection. If these vulnerabilities have been exploited before patches were applied — and Fortinet's "not exploited in the wild" claim covers only what they know — defenders have no IoCs to hunt on. That gap deserves a direct question to Fortinet's PSIRT.
— HackWire Editorial
## Related Coverage