The Wildcard That Wasn't: CVE-2026-26035 and FortiWeb's RADIUS Admin Login Bypass

The bug in one sentence

If a FortiWeb administrator account is configured as Remote Type against RADIUS with the Wildcard option enabled, an unauthenticated attacker can log into that device’s GUI or CLI with a random username and a random password. Fortinet disclosed CVE-2026-26035 on August 12 (FG-IR-26-158), the same day as the FortiManager FGFM impersonation bug covered separately here, and both trace back to the same theme: an auth-relevant option that isn’t on by default, does something narrower than it sounds like it should, and quietly breaks a trust check when it’s turned on.

What “wildcard” is supposed to do, and what it actually does

FortiWeb supports Remote Type administrator accounts, meaning the login credential check happens against an external server rather than a locally stored password, RADIUS in this case. Normally that account maps to one specific remote username. The Wildcard option exists to loosen that: instead of matching one exact username, it lets FortiWeb accept any username that RADIUS authenticates, provided the returned group membership matches an Admin User Group configured under System > Administrators.

That’s a reasonable feature on paper, useful if you’re managing admin access through RADIUS group attributes rather than maintaining a FortiWeb-side account per person. CVE-2026-26035 is what happens when the implementation of that group check goes further than “loosen the username match” and ends up not properly validating the credential exchange at all. Fortinet’s own classification is blunt about it: CWE-287, Improper Authentication. The advisory doesn’t publish the exact mechanics Fortinet found during its internal audit, appropriately, but the practical outcome is stated plainly: a remote, unauthenticated attacker can reach the login prompt and get in with credentials that were never actually valid.

Severity, affected versions, fix

CVSS 3.1 base score 8.8, CVE ID CVE-2026-26035, discovered internally as part of a Fortinet audit rather than reported by an outside researcher, not known to be exploited at time of disclosure.

Version	Affected	Fixed
FortiWeb 8.0	8.0.0 – 8.0.2	8.0.3 or later
FortiWeb 7.6	7.6.0 – 7.6.6	7.6.7 or later
FortiWeb 7.4	7.4.0 – 7.4.11	7.4.12 or later
FortiWeb 7.2	7.2.0 – 7.2.12	7.2.13 or later

Like the FortiManager bug, there’s a real workaround, and it’s the same shape: turn off the non-default setting that enables the vulnerable path.

config system admin
    edit <remote-type-administrator-account>
        set wildcard disable
    next
end

Or from the GUI: System > Administrators, edit the affected Remote Type account, disable Wildcard. If you don’t specifically remember configuring RADIUS-backed admin accounts with wildcard matching on FortiWeb, that’s still worth a show system admin pass rather than an assumption, the same audit discipline that applies to FortiManager’s fgfm-peercert-withoutsn setting.

Why the RADIUS layer is the part worth double-checking

RADIUS vs TACACS+ for FortiGate admin AAA and its configuration follow-up both went deep on RADIUS as the AAA backend of choice for FortiGate device admin, and the same protocol underpins this FortiWeb bug. The pattern worth internalizing here isn’t specific to FortiWeb: any device that authenticates administrators against a remote AAA server has to correctly bind three things together, the identity RADIUS confirms, the group or role that identity maps to, and the actual permission grant on the device itself. Break the binding between any two of those, and a feature meant to make group-based access management more convenient turns into a bypass. NSE4 Part 4 covers RADIUS as one of four FortiOS authentication backends at the fundamentals level; this bug is a reminder that the fundamentals-level trust assumption, “the remote server vouches for who this is,” only holds if every option layered on top of that exchange is implemented as carefully as the base case.

Two Fortinet auth-relevant bugs disclosed the same day, both internally found, both fixed with a one-line config change, both hinging on a non-default option somebody had a real reason to turn on once. That’s not a coincidence worth reading too much into, internal audits tend to surface clusters of related findings together. But it’s a good prompt to actually go check what’s enabled on any FortiWeb or FortiManager instance sitting in front of production, rather than trusting that “we never touched that setting” is the same thing as “that setting is off.”