FortiWeb CVE-2026-26035: random credentials can open the admin panel

Fortinet published CVE-2026-26035, an improper-authentication flaw in FortiWeb, on 12 August 2026. An unauthenticated remote attacker can log in to the GUI or CLI with a random username and password. This is not the cracking of an existing administrator’s strong password; it is a verification path accepting credentials that should have failed.

Fortinet advisory FG-IR-26-158 scores it 8.8 under CVSS 3.1 and identifies these affected ranges: FortiWeb 8.0.0–8.0.2, 7.6.0–7.6.6, 7.4.0–7.4.11, 7.2.0–7.2.12 and 7.0.0–7.0.12. The CNA score should take precedence over older or automated aggregator values. Administrators should move to a release outside the relevant range using the official upgrade path rather than guess one version number for every branch.

Why a WAF flaw has a broad blast radius

FortiWeb protects web applications and APIs by terminating or inspecting traffic and managing WAF policy, bot controls, certificates and backend configuration. Its management interface is a control plane in front of multiple services. An administrative session could potentially modify protection, routing, integration or logging settings; the exact reach depends on the role obtained and deployment configuration.

The CVE confirms entry to the GUI or CLI. It does not confirm every subsequent action or a mass campaign. Effects on certificates, backends and policy are reasoned from the appliance’s function. Incident communications should preserve that distinction without minimising loss of control over a WAF.

Highest priority goes to interfaces reachable from the Internet, a user network, a guest segment or a broad VPN. A panel confined to an isolated management network has lower reachability but still needs an update: a compromised administrator workstation or mistaken firewall rule can defeat the trusted-segment assumption.

Establishing actual exposure

Do not look only at the current interface and conclude that a private address is not public. Inspect NAT rules, reverse proxies, load balancers, support tunnels, FortiManager or other management paths, firewall history and HA configuration. In a cluster, each unit and out-of-band interface may have a different address and policy.

Inventory should record version, branch, HA role, management addresses, allowed sources, authentication type and latest configuration change. Images in storage and powered-off appliances also need marking so they do not later return to production with vulnerable firmware.

Verify reachability from a controlled external vantage point. An internal scan cannot show WAN publication. Do not reproduce the authentication bypass on production. Version and reachability are sufficient to establish remediation need; an exploit test can alter state and complicate an investigation.

Actions for the first hours

1. Restrict GUI and CLI access to individual administration hosts or a dedicated VPN. Remove public exposure before other work.
2. Confirm every unit’s version, including passive nodes, and map it to FG-IR-26-158 ranges.
3. Take a protected configuration and log backup using the vendor procedure; never place it on a public share.
4. Upgrade to Fortinet’s resolution for the relevant branch and apply any required intermediate upgrade steps.
5. After restart, verify version, HA state, policy sync, certificates, backend health checks and critical application flows.
6. Review accounts, roles, API keys, trusted-host configuration, WAF rules, routing, certificates and log destinations.
7. If an interface was reachable from an untrusted network, begin incident analysis and rotate secrets after establishing appliance integrity.

Cluster maintenance needs an availability plan. It must not leave an active node vulnerable merely because the passive node was fixed. After every change, verify which unit serves management and traffic. If no immediate update window exists, apply a strict network control outside FortiWeb so compromise of the appliance cannot remove it.

What to look for in logs

Review successful GUI and CLI sign-ins, including usernames absent from the normal directory. Look for unfamiliar source addresses, times, user agents and sessions without normal preceding authentication steps. Compare local records with external syslog, SIEM, NetFlow and VPN history.

Then search for post-authentication activity: new accounts, role changes, configuration exports, policy edits, logging disabled, certificates added, backend changes and routing updates. These actions do not prove exploitation of this specific CVE; they are possible impact after panel access. Correlating time and session helps distinguish an administrator from unknown activity.

Absence from a local log is not proof of safety. A highly privileged user may alter logging or remove records. An external collector should receive events in one direction, and the appliance should not be able to overwrite them. If that telemetry did not exist, report a lower confidence level rather than claim certainty.

Secrets and restoring trust

After confirmed or likely compromise, assume information accessible to the administrative role may have been read. Derive rotation scope from configuration: local accounts, API tokens, integration credentials, certificate private keys, backend secrets and logging-system credentials. FortiWeb deployments differ, so the list needs to reflect the actual appliance.

Rotate only after removing the vulnerability and persistence. For a certificate, consider issuing a new key pair rather than changing a password if private-key export was possible. Check applications behind the WAF as well: a policy change could have created a window in which malicious traffic reached a backend.

For a high-criticality environment, restoration from a trusted image and manual application of approved configuration may provide stronger assurance than continuing with an appliance of unknown integrity. Coordinate the decision with continuity needs, but availability should not mean permanently accepting a compromised control plane.

Long-term management architecture

A WAF panel should be invisible from the Internet, protected by an independent identity gateway and MFA, network-restricted and administered from managed workstations. Personal accounts provide stronger attribution than a shared administrator. Emergency access needs a procedure, recording and automatic expiry.

Edge-device updates should have a shorter SLA than ordinary internal systems. Automatically compare versions with vendor PSIRTs, test configuration on a representative node and maintain a current diagram of management paths. A control plane needs independent logs and an external access control it cannot disable.

The affected ranges and random-credential access are facts from Fortinet’s advisory and the CVE record. Post-compromise impact and investigative recommendations are Breachroad analysis. Those sources do not establish mass exploitation.

Infrastructure and SOC teams should practise this scenario together because updates, continuity and evidence interact. Our cybersecurity training for organisations prepares those decisions before an incident. An independent IT security assessment can review edge-device segmentation and management.