Imagine a login page where the username and password don’t matter — type anything, and you’re in as administrator. That’s not a hypothetical; it’s CVE-2026-26035, an authentication bypass in Fortinet’s FortiWeb that Fortinet patched this month. It’s a great bug to study, not just to patch, because authentication bypass is one of the highest-value classes in bug bounty — and the shape of this bug is one you can learn to hunt for. This post covers both: what the FortiWeb flaw is, and what it teaches you about finding auth-bypass bugs of your own.
The bug: log in with anything
CVE-2026-26035 is an improper-authentication flaw (CWE-287) in FortiWeb’s login mechanism, rated critical (CVSS in the 8.8–9.8 range). Here’s the precise condition: when a FortiWeb administrator account is configured for Remote RADIUS-type authentication with the “wildcard” setting enabled, a remote, unauthenticated attacker can log into the FortiWeb GUI and CLI using arbitrary — literally random — usernames and passwords. The credentials are never meaningfully validated. Provide any string, get administrator access.
An important caveat for defenders: the wildcard option is not enabled by default, so not every FortiWeb is exposed. But where it is on, the box is wide open.
- Affected: 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, 7.0.0–7.0.12
- Fixed in: 8.0.3, 7.6.7, 7.4.12, 7.2.13
- Workaround: disable the wildcard setting on remote-type admin accounts
It’s also worth noting FortiWeb has had a string of authentication-bypass CVEs — earlier in 2026, CVE-2026-24858 (an SSO-related bypass) was actively exploited in the wild. When a product’s login logic produces repeat auth-bypass bugs, that’s a signal about where its complexity — and its weakness — lives.
Why this bug happens: authentication that “fails open”
The root cause of most auth-bypass bugs is the same idea: somewhere, the code that’s supposed to deny by default ends up allowing by default under some condition. Here, a “wildcard” feature — designed to let RADIUS match a range of users flexibly — interacts with the login flow so that the credential check effectively passes for anyone. The feature that was meant to add convenience removed the check entirely.
That’s the mental model to carry into any target: authentication is a decision (allow / deny), and bugs happen when an edge case, a config option, an error path, or a piece of trusted-but-attacker-controlled input flips that decision the wrong way.
The bug-bounty lesson: how auth-bypass bugs are found
Authentication bypass pays well because it scales to every user and often lands you admin. Here are the recurring patterns worth hunting for — CVE-2026-26035 is an instance of the first two:
- Config/feature flags that weaken auth. Options like “wildcard,” “allow any,” “trust proxy,” “skip verification,” or debug modes that were meant to be convenient. When you have access to configuration (or documentation), map which settings touch the auth path.
- Fail-open logic. What happens when the auth check errors? If an exception, a timeout, or an unexpected input causes the code to fall through to “allow,” that’s a bypass. Feed the login unexpected things: empty passwords, arbitrary credentials, malformed tokens, oversized inputs.
- Alternate auth paths. The web login might be hardened, but the API, the mobile endpoint, the SSO callback, or the admin CLI may enforce the check differently — or not at all. Enumerate every way to authenticate, not just the obvious one. FortiWeb’s bug hit both GUI and CLI.
- Client-trusted state. Any auth or role decision made from data the client controls — a JWT you can tamper with (
alg:none, weak secret), a cookie likeisAdmin=false, a header the backend trusts (X-Forwarded-User,X-Remote-User) — is a candidate. - The anomaly of the one unauthed route. In a sea of endpoints that require auth, the single route that doesn’t is the first place to look. Map every route and annotate its auth requirement; the outlier is your lead.
A practical, safe testing methodology
On a target you’re authorized to test:
- Inventory the auth surfaces. Web login, API auth, SSO/OAuth callbacks, mobile app auth, admin consoles, CLI/management interfaces. Each is a separate bypass candidate.
- Baseline the “denied” response, then attack it. Note exactly what a failed login / 401 / 403 looks like. Now try to turn it into a success: arbitrary credentials, empty fields, known-default accounts, token tampering, method swaps, and path/header bypass tricks. Any transition from “denied” to “allowed / 200 / 302” is a finding to chase.
- Probe config-dependent behavior. If the product exposes settings (or you can read its docs/source), test the paths that specific options enable. CVE-2026-26035 only fires with wildcard on — many bypasses are conditional like this.
- Test every auth path the same way. Don’t assume the API enforces what the web form does. Re-run your checks against each surface independently.
- Prove impact cleanly. Demonstrate the bypass with accounts and data you’re allowed to touch, and write the one-line impact: “an unauthenticated attacker gains administrator access to X.” That clarity is what gets an auth-bypass report triaged fast.
For defenders
If you run FortiWeb: patch to 8.0.3 / 7.6.7 / 7.4.12 / 7.2.13, and in the meantime disable the wildcard setting on any remote-type admin account. Beyond this specific bug, the durable lesson is that management interfaces should never be internet-facing — a FortiWeb admin GUI reachable from the internet turns an auth-bypass into instant compromise, while the same bug on an isolated management network is far less catastrophic. Audit what’s exposed, and treat repeated auth-bypass CVEs in a product as a reason to tighten its exposure, not just to apply the latest patch.
The bottom line
CVE-2026-26035 lets anyone log into a misconfigured FortiWeb as admin with random credentials — a stark reminder that authentication is only as strong as its weakest path and its riskiest config option. For hunters, it’s a model of the auth-bypass class: look for fail-open logic, convenience flags that disable checks, and alternate auth paths that skip what the front door enforces. For defenders, patch it, disable wildcard, and get the management plane off the internet. The best auth-bypass bugs aren’t clever exploits — they’re places where the code simply forgot to say no.
Sources: SecurityWeek — Fortinet Patches Authentication Flaws in FortiWeb and FortiManager · CISA (on the earlier CVE-2026-24858). Confirm affected builds against Fortinet’s PSIRT advisory before acting. Only test systems you are explicitly authorized to assess.