Fortinet Patches FortiWeb and FortiManager Auth Flaws — Random Logins, FortiGate Impersonation
Fortinet patched high-severity authentication flaws in FortiWeb and FortiManager. One lets a remote attacker log in with random usernames and passwords; the other lets an attacker impersonate any FortiGate managed by FortiManager. No active exploitation is reported — patch now.
Fortinet on Wednesday shipped fixes for eight vulnerabilities across its product line, and two of them are the ones defenders should read first: authentication flaws in FortiWeb and FortiManager that, in the vendor's own description, let an attacker log in with a random username and password or impersonate any FortiGate appliance managed by a FortiManager. Both were disclosed on August 13, 2026, and both already have fixed builds available.
The line to carry into a change ticket: an unpatched FortiWeb with one non-default setting enabled can hand an unauthenticated attacker a working login, and an unpatched FortiManager can be coaxed into trusting an attacker as though it were one of its own managed firewalls. Fortinet reports no evidence that either flaw is being exploited in the wild, which makes this a patch-ahead-of-the-curve window rather than an active incident — the kind of lead time defenders rarely get with edge and management appliances.
The FortiWeb Flaw: A Login With Random Credentials
The FortiWeb issue, tracked as CVE-2026-26035, is an improper-authentication weakness that SecurityWeek reported a remote, unauthenticated attacker could use "to log in to the FortiWeb GUI/CLI with a random username and password." That is Fortinet's own phrasing, and it is worth taking literally: the flaw does not require guessing a valid credential so much as defeating the check that a credential should be valid at all.
The catch is that it only bites deployments configured a particular way. The weakness is tied to the wildcard setting for administrator accounts, which is disabled by default. When an administrator enables that wildcard option, the system matches any username on a remote authentication server against the Remote User account — the behavior the flaw turns into an authentication bypass. Sites that never touched the wildcard setting are not exposed, but any that did should treat this as a live administrative-access risk.
Fortinet patched the flaw in FortiWeb versions 8.0.3, 7.6.7, 7.4.12, and 7.2.13. For teams that cannot deploy a fixed build immediately, the vendor's stated workaround is to disable the wildcard setting, which removes the vulnerable code path until the patch lands.
The FortiManager Flaw: Impersonating a Managed FortiGate
The second and arguably more consequential bug lives in FortiManager, the platform organizations use to centrally administer fleets of FortiGate firewalls. Tracked as CVE-2026-70468, it is an authentication-bypass flaw that lets a remote attacker impersonate any FortiGate device managed by the FortiManager. Exploitation is not unconditional: it requires a specific CLI option to be set and the attacker to hold a valid certificate, according to Fortinet.
Why this one deserves attention beyond its preconditions: FortiManager is a trust anchor. It is the system a fleet of firewalls looks to for configuration and policy, so a flaw that lets an attacker pose as a managed FortiGate undermines the assumption that the devices talking to FortiManager are the devices they claim to be. Fortinet documents both flaws on its PSIRT advisories page, and coverage of the FortiManager advisory notes that disabling the fgfm-peercert-withoutsn setting serves as a mitigation where patching has to wait.
What Else Shipped, and What Did Not
The two authentication flaws arrived alongside a larger batch. Fortinet also fixed a high-severity buffer-overflow bug in FortiClient for Windows (CVE-2026-70465) that could let an attacker able to craft or modify DNS responses run arbitrary code, plus a set of medium- and low-severity issues in FortiWeb's WAF, FortiOS, and FortiSIEM. Notably absent from the disclosure is any claim of exploitation: Fortinet makes no mention of these vulnerabilities being used in attacks, and no threat actor has been tied to them. That detail separates this release from Fortinet's more urgent advisories earlier in 2026.
What to Verify This Week
Start with the two headline products. Inventory every FortiWeb and FortiManager instance, confirm the running build, and move anything vulnerable onto the fixed versions — FortiWeb 8.0.3, 7.6.7, 7.4.12, or 7.2.13, and the FortiManager build named in Fortinet's advisory. On FortiWeb specifically, check whether the wildcard administrator setting is enabled; if it is and you cannot patch at once, disable it as the interim control the vendor recommends.
Then reduce blast radius. Management-plane interfaces on FortiWeb and FortiManager should not be needlessly reachable from the open internet, a discipline that shrinks the surface any of these flaws depends on. Because the FortiManager bug is about impersonating a managed firewall, it is worth auditing FortiManager-to-FortiGate trust and enrollment for anomalies — unexpected device registrations or unusual certificate use — rather than assuming the management channel is clean. Keep watch on Fortinet's PSIRT feed for any change in exploitation status.
The wider context is that Fortinet's appliances have been a recurring defender workstream this year. The CyberSignal covered the same estate when a joint U.S.–South Korea advisory tied the Gunra ransomware crew to unpatched Fortinet authentication-bypass flaws, and again when CISA ordered urgent patching of actively exploited FortiSandbox vulnerabilities. The through-line is process: teams that treat Fortinet exposure as a standing inventory-and-patch cycle absorb releases like this one as routine.
My Read
My read: the gift here is timing. Two authentication flaws in internet-adjacent Fortinet products — one that fabricates a login, one that impersonates a managed firewall — are exactly the class of bug that tends to surface in an exploitation advisory a few months later, and this time defenders have the fix before anyone is known to be using it. The FortiWeb flaw is narrower than the headline suggests because it depends on a non-default setting, so the highest-value first move is simply checking whether that wildcard option is on. The FortiManager flaw is the one I would not sit on: it has real preconditions, but it strikes at the trust relationship between a management platform and the fleet it governs, and that is a harder thing to reason about after the fact than a single exposed appliance. Patch both, verify rather than assume, and use the quiet window while it lasts.
