A web application firewall exists to check who is knocking before letting them through. This week Fortinet disclosed a bug where, under one specific but common configuration, FortiWeb stopped checking altogether.

Wildcard RADIUS turns any username into an admin login

CVE-2026-26035, published in advisory FG-IR-26-158 on 12 August, is an improper authentication flaw carrying a CVSS score of 9.8. It surfaces when a FortiWeb administrator account is set up for Remote RADIUS Type authentication with the wildcard setting enabled, a configuration organisations use to let any account in a central RADIUS directory group log in without provisioning each admin locally. Under that setup, FortiWeb ends up matching any username returned by the remote RADIUS server against the defined admin group, without properly validating that the credentials presented were actually correct. The practical result: a remote, unauthenticated attacker can log into the FortiWeb GUI or CLI with a random username and password, no valid credential, no guessing, no brute force required.

Not a default, but not an edge case either

Wildcard RADIUS is off by default, which keeps this out of the “every FortiWeb everywhere” category. It is also exactly the kind of setting enterprise teams turn on deliberately, because centralising admin authentication through an existing RADIUS or identity provider is standard practice for reducing local account sprawl. Any organisation that integrated FortiWeb admin access with centralised authentication for that entirely sensible reason should assume this configuration applies to them until they have checked. The affected range spans FortiWeb 8.0.0 through 8.0.2, 7.6.0 through 7.6.6, 7.4.0 through 7.4.11, 7.2.0 through 7.2.12 and the older 7.0.x branch. Fixed builds are 8.0.3, 7.6.7, 7.4.12 and 7.2.13.

A WAF is the wrong appliance to have this bug

FortiWeb sits directly in front of the web applications and APIs it protects, frequently as the only layer between the open internet and a European organisation’s customer-facing services. An attacker who gains admin access to the WAF itself does not need to find a bypass for the applications behind it, they can simply reconfigure the WAF to let their own traffic through unfiltered, or use it as a pivot point into the network it was meant to be defending. That combination of internet-facing exposure and total control over the protection layer is what pushes a 9.8 from “patch this cycle” to “patch this week.”

What to check right now

If your FortiWeb admin accounts use Remote RADIUS Type authentication, confirm immediately whether the wildcard option is enabled, and if it is, patch to 8.0.3, 7.6.7, 7.4.12 or 7.2.13 without waiting for a scheduled maintenance window. If you are not certain whether your deployment uses this configuration, that uncertainty is itself worth resolving today rather than assuming the default applies.

If your organisation runs FortiWeb and needs help auditing its authentication configuration, confirming whether this flaw applies to your environment, or getting a patch out ahead of the next scanner sweep, contact Excello Digital. We help European organisations find the non-default settings that turn a routine advisory into a critical exposure before an attacker does.