Fortinet's FortiWeb Login Bypass Is a Settings Problem First, a Patch Problem Second

Fortinet released patches on Wednesday for eight vulnerabilities across its product line, including an improper authentication flaw in FortiWeb that, in the company's own words, allows a remote, unauthenticated attacker "to log in to the FortiWeb GUI/CLI with a random username and password" ^[1][3][4]. The reason this belongs in a configuration review and not only a patch queue: according to Fortinet, the bug reaches only deployments running specific, non-default settings ^[2].

The setting in question is the wildcard option for administrator accounts, which Fortinet says is disabled by default ^[5]. With it enabled, the system matches any username on a remote server against the Remote User account ^[6]. Fortinet adds that when wildcard is on and a group name has been defined in the Admin User Group, the system matches remote-server users whose group name value equals the one defined ^[7]. That is a deliberate convenience for shops running federated admin identity, and it is exactly the kind of switch that gets flipped once during a rollout and never revisited.

The fix landed in FortiWeb 8.0.3, 7.6.7, 7.4.12 and 7.2.13 ^[8], four maintained branches ^[9]. Where patching has to wait for a change window, Fortinet's recommended workaround is to disable the wildcard setting ^[10]. Operators who cannot enumerate which FortiWeb instances have it enabled should treat that inventory gap as the more urgent finding.

The pattern repeats in FortiManager. CVE-2026-70468 is an authentication bypass that lets remote attackers impersonate any FortiGate device managed by FortiManager, but it requires a specific CLI option to be set and the attacker to hold a valid certificate ^[11]. Two of the three high-severity issues in this batch therefore depend on a non-default configuration state ^[12], which means severity ratings alone will mis-rank the work for most estates.

The exception is FortiClient for Windows, where a high-severity buffer overflow, CVE-2026-70465, could let unauthenticated attackers who can modify or craft DNS responses execute arbitrary code ^[13]. No admin toggle stands between an attacker and that one, only network position, which makes it the item to schedule against the endpoint fleet rather than the appliance team.

Fortinet also resolved medium- and low-severity defects in FortiWeb WAF, FortiOS and FortiSIEM, and published an advisory on the impact of CVE-2026-49975, the HTTP/2 Bomb attack affecting Apache HTTP Server ^[14][15]. By subtraction from the company's own total, the remaining five of the eight sit below high severity ^[16]. Fortinet makes no mention of any of these vulnerabilities being exploited in the wild ^[17].

What to watch: whether Fortinet's PSIRT advisories are updated with exploitation notes, since edge appliance authentication bypasses historically do not stay theoretical ^[18]. Internally, watch whether your configuration baseline can answer the wildcard question without someone logging into each box, because that capability decides how long the FortiWeb exposure window stays open.