FortiWeb RADIUS Wildcard Authentication Bypass (CVE-2026-26035): How to Check Whether Your Appliance Is Actually Exposed

On August 12, 2026 Fortinet published FG-IR-26-158, an improper authentication flaw in FortiWeb that lets a remote, unauthenticated attacker log into the appliance GUI or CLI with a random username and password. Coverage has split into two camps: the trackers reporting 9.8 Critical and the advisory itself reading High. Both numbers come from Fortinet, and neither is wrong — one is the base score, the other is the temporal score, and the gap between them is arithmetic, not disagreement. The detail that actually changes what you do this week is elsewhere: Fortinet's own CNA record lists FortiWeb 7.0.0 through 7.0.12 as affected, and the advisory's remediation table has no 7.0 row at all.

The Vulnerability

CVE-2026-26035 (CWE-287: Improper Authentication) sits in the path FortiWeb uses to authenticate administrators against a remote RADIUS server. Fortinet titles the advisory "Broken access control in the RADIUS type admin group" and describes it this way:

"An Improper Authentication vulnerability [CWE-287] in the FortiWeb Remote Radius Type Admin Authentication configured with specific, non-default settings may allow a remote unauthenticated attacker to login into the Fortiweb GUI/CLI with a random username and password"

Two clauses in that sentence carry all the weight. configured with specific, non-default settings is the precondition — this is not a flaw that fires against a stock appliance. with a random username and password is the impact — when the precondition holds, credentials stop being checked in any meaningful sense and the attacker lands with administrative access to a device that sits in front of the applications it protects.

Why You Are Seeing Both 9.8 and High

This is worth settling, because the two numbers are being reported as a vendor-versus-tracker dispute and they are not one. Fortinet's CNA submission to NVD carries the base vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, which computes to 9.8. The vector printed on the PSIRT advisory page is the same base metrics with three temporal metrics appended:

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H/E:P/RL:O/RC:C
                                   └───┬────┘
                                 temporal metrics

  base                    9.8
  × 0.94   E:P   Exploit Code Maturity: Proof-of-Concept
  × 0.95   RL:O  Remediation Level: Official Fix
  × 1.00   RC:C  Report Confidence: Confirmed
  ─────────────────────
  temporal                8.8

Same flaw, same base severity, one number adjusted for the fact that a patch exists. At least one vendor blog has explained Fortinet's lower figure as the score "accounting for configuration preconditions" — that reading does not hold. Preconditions would show up as AC:H or PR:L in the base vector, and both are unchanged at AC:L and PR:N. The temporal metrics encode exploit maturity, remediation availability and report confidence — nothing about how your appliance is configured.

The practical consequence is that CVSS is not modelling the thing that most determines your risk here. The base vector describes the vulnerability as it behaves once the wildcard precondition is met, and it is entirely accurate on those terms: no authentication, no interaction, full compromise of the appliance. It has no way to express that the precondition is non-default. That gap is what the configuration check above is for, and it is why a fleet-wide 9.8 panic and a fleet-wide shrug are both wrong responses.

One nuance worth flagging rather than glossing: E:P asserts that proof-of-concept exploit code exists. Fortinet simultaneously records Known Exploited as No, and third-party trackers reported no public PoC at disclosure. Fortinet applies E:P broadly across its advisories, so this is weak evidence of a circulating exploit — but it is Fortinet's own published vector, and it is not a reason to treat the flaw as theoretical.

The 7.0 Branch That Is Not in the Table

Here is the operational finding. Fortinet's CNA record — the description NVD serves, written by Fortinet — names five affected branches:

"...in Fortinet FortiWeb 8.0.0 through 8.0.2, FortiWeb 7.6.0 through 7.6.6, FortiWeb 7.4.0 through 7.4.11, FortiWeb 7.2.0 through 7.2.12, FortiWeb 7.0.0 through 7.0.12..."

The remediation table on the advisory lists four: 8.0 → 8.0.3, 7.6 → 7.6.7, 7.4 → 7.4.12, 7.2 → 7.2.13. There is no 7.0 row. Not a row saying "migrate to a fixed release," which is how Fortinet handled the unfixed branches in the FortiOS symlink bypass earlier this year — simply no row.

An administrator running FortiWeb 7.0.11 who opens the advisory, scans the solution table for their branch and finds nothing has been handed a genuinely ambiguous signal. The defensible reading, and the one to work from, is that 7.0 is affected and has no in-branch fix: Fortinet wrote the affected range itself, and absence from a remediation table is not a statement of non-vulnerability. The likely explanation is lifecycle — under Fortinet's published lifecycle policy, software reaches end of engineering support around 36 months after GA and end of support around 54 months, and FortiWeb 7.0 shipped in early 2022. Fortinet's authoritative lifecycle table sits behind a FortiCloud login, so we are not going to state a precise EOS date we cannot verify from the vendor directly; third-party lifecycle trackers place FortiWeb 7.0's end of support in mid-2026, weeks before this advisory.

Either way the action is the same and it is not a patch. It is a branch migration to 7.2.13 or later, which is a change-controlled upgrade rather than a maintenance release — and in the meantime, disabling wildcard on remote administrators is the only thing standing between a 7.0 appliance and this bug.

What the Wildcard Setting Actually Does

FortiWeb's CLI reference for system admin documents the relevant fields:

config system admin
  edit "<administrator_name>"
    set type {local-user | remote-user}
    set admin-usergroup "<remote-auth-group_name>"
    set wildcard {enable | disable}
  next
end

set type remote-user delegates authentication for that account to a remote server — LDAP or RADIUS — via the group named in admin-usergroup. Fortinet documents wildcard as being "used when administrator accounts authenticate via a RADIUS query," and notes it "applies only if the value of set type is remote-user."

A wildcard admin exists so that an organisation does not have to pre-create a local account object for every administrator. Rather than defining twelve accounts on the appliance, you define one wildcard entry and let the RADIUS server decide which administrators authenticate — FortiWeb still governs the admin group and access profile they land in. It is a convenience feature for shops running central authentication, which means the appliances most likely to have it enabled are the ones belonging to organisations with mature identity practice — a slightly uncomfortable inversion of the usual pattern where the sloppiest deployments are the exposed ones.

The failure, per Fortinet's advisory title, is in how the RADIUS-type admin group is matched. When the appliance stops requiring that the RADIUS exchange actually succeed before binding a session to an admin group, the wildcard entry that was supposed to accept "whichever legitimate administrator RADIUS vouches for" instead accepts anybody. Fortinet has not published exploitation detail beyond that, and we are not going to reconstruct a request shape from a two-sentence advisory.

A note on method: FortiWeb is a licensed appliance, not self-hostable open-source software, so there is no vulnerable instance we can legally stand up and no reproduction to show you. Everything above is sourced from Fortinet's advisory, Fortinet's CNA record and Fortinet's CLI documentation, and the boundary between what the vendor stated and what we inferred is marked. Where this blog reproduces a bug against a real product, it says so and shows the capture.

Investigation Workflow

Be clear about what remote work can and cannot establish here, because the honest answer shapes the whole engagement: no amount of external scanning will tell you whether wildcard is enabled. Network reconnaissance answers a narrower question — which FortiWeb management surfaces are reachable, and from where — and that question is worth answering on its own merits, because a management GUI that is not exposed to the internet dramatically reduces the reachable attack surface for this and every future FortiWeb advisory.

1. Port Scan: Locate Management Surfaces

FortiWeb is a reverse proxy, which makes its port picture genuinely ambiguous in a way that trips up scan-based triage. The appliance serves two entirely different things over HTTPS: the administrative GUI, and the protected web applications sitting behind its virtual servers. A 443 response from a FortiWeb address is far more likely to be a customer's website than a login page.

• • 443 — HTTPS. Either the admin GUI or a protected virtual server; the two are distinguished by response content, not port number
• • 80 — HTTP, same ambiguity
• • 22 — SSH administration (the CLI half of "GUI/CLI" in the advisory text)

The two settings that govern this are separate and both worth pulling: which interfaces permit administrative access is controlled per-interface by allowaccess, while the port the GUI listens on is a global administration setting that defaults to HTTPS on 443 and can be changed. So the port is a reasonable starting assumption but not a safe one, and interface exposure is the variable that actually matters. This is the point of the exercise: if you find the admin GUI answering on an internet-facing interface at all, that is a finding independent of CVE-2026-26035.

2. HTTP Response: Separate GUI from Protected Site

Fetch the root of each candidate and read what comes back. A FortiWeb administrative login page is Fortinet-branded and identifies the product; a protected virtual server returns the customer application, usually with no Fortinet indication at all, since the entire purpose of a WAF is to be invisible to legitimate traffic. Where a site is proxied by FortiWeb, the tell is more often a cookie or a block page returned when a request trips a signature than anything in a clean 200 response.

3. TLS Inspect: Certificate as the Reliable Discriminator

The certificate is the strongest single signal available remotely. A protected virtual server presents the customer's own publicly-trusted certificate for their domain. An administrative interface that has never had a certificate installed presents Fortinet's factory-default self-signed certificate — untrusted, with a Fortinet-associated subject rather than a customer hostname. Fortinet documents replacing the GUI certificate as an explicit administrative step, which is a reliable indicator precisely because it is a step many deployments skip. A self-signed certificate on an internet-facing address in a Fortinet netblock is the combination worth chasing down.

4. Cross-Reference External Data

Resolve the hostnames your organisation associates with FortiWeb-fronted applications and confirm which addresses answer on management surfaces from outside. Compare against the advisory's affected ranges once you have the version from inside. Two supporting checks are worth running at the same time: whether the appliance's RADIUS server is reachable from the same segment as the management interface, and whether administrative access is restricted by trusthost entries — FortiWeb supports up to three IPv4 and three IPv6 trusted management sources per account, and a populated trusthost list meaningfully constrains who can reach the vulnerable login path even while the flaw is present.

The Rest of the August 12 Batch

CVE-2026-26035 shipped alongside two other authentication-related fixes worth tracking if you run the wider Fortinet estate. Neither is reported as exploited, and both are rated High by Fortinet:

• • CVE-2026-70468 — FortiManager authentication bypass permitting device impersonation. Relevant because a FortiManager compromise is a management-plane compromise of everything it manages.
• • CVE-2026-70465 — FortiClient for Windows buffer overflow enabling remote code execution, i.e. an endpoint-side issue rather than an appliance one.

Remediation

1. Check the configuration before the version. Run show system admin and look for accounts with set type remote-user and set wildcard enable. This determines whether you have an active exposure or a patch-at-next-window item, and it takes a minute.
2. Apply the workaround immediately if wildcard is enabled. config system admin → edit <account> → set wildcard disable, or System > Administrators in the GUI. This removes the precondition and is reversible after upgrade. Confirm your administrators can still authenticate — disabling wildcard means each remote administrator needs a defined account object.
3. Upgrade to a fixed build. 8.0.3+, 7.6.7+, 7.4.12+, or 7.2.13+.
4. Treat 7.0.x as a migration, not a patch. There is no fixed 7.0 build. Plan the move to 7.2.13 or later and keep the wildcard workaround in place until it lands.
5. Restrict management access. Populate trusthost entries on administrator accounts and remove administrative access from internet-facing interfaces. This is the control that would have blunted this CVE before it was published and will blunt the next one.
6. Review administrative logins if wildcard was enabled on an unpatched build. Look for successful GUI or CLI administrator authentications from unexpected sources, and for accounts that do not correspond to a known administrator. Since exploitation yields a normal-looking successful login rather than an error, absence of failures is not evidence of absence.

Sources

• → Fortinet PSIRT: FG-IR-26-158 — Broken access control in the RADIUS type admin group
• → NVD: CVE-2026-26035 (Fortinet CNA record, base 9.8)
• → Fortinet: FortiWeb CLI Reference — system admin (type, admin-usergroup, wildcard, trusthost)
• → Fortinet: Configuring the SSL certificate for administrator access to the FortiWeb GUI
• → FIRST: CVSS v3.1 Specification — temporal metric weights
• → Fortinet: Product life cycle information (EOES / EOS policy)
• → SecurityWeek: Fortinet Patches Authentication Flaws in FortiWeb and FortiManager