FortiWeb authentication bypass exposes the risk in RADIUS admin flows

At a glance

What this is: This analysis covers CVE-2026-26035, a FortiWeb improper authentication flaw in the RADIUS-backed admin flow that can expose appliance administration without valid credentials.

Why it matters: It matters because WAF management planes often sit at the centre of edge security governance, and a broken admin authentication path can hand attackers privileged control over inspection, policy, and logging.

Context

CVE-2026-26035 is a management-plane authentication failure, not a content inspection bug. The issue matters because appliance administration is often delegated to central identity systems, which means a weakness in the login path can become a direct path to privileged control of the security device itself.

For IAM and PAM teams, the important question is not whether the appliance is internet-facing, but whether its administrative trust model is sound under remote authentication. When RADIUS-backed admin groups are used, the identity control becomes part of the attack surface, and the boundary between operational convenience and administrative exposure gets very thin.

Key questions

Q: What breaks when a WAF’s RADIUS admin path fails authentication?

A: The management plane breaks first. If the appliance accepts administrative sessions before proving identity, an attacker can reach the GUI or CLI with privileged access, change policy, and view sensitive logs. In practice, that means the security device’s control boundary fails at the exact point meant to protect it.

Q: Why do remote administrator authentication flows create high risk in appliance environments?

A: Because they concentrate control over the device that enforces policy for many downstream systems. If the authentication path is weak or exposed, one compromise can affect certificates, inspection rules, and visibility across multiple services. The risk is higher when the management plane is reachable from broad networks rather than a segregated admin segment.

Q: What do security teams get wrong about appliance admin bypass risk?

A: They often focus on the firmware version and ignore the authentication configuration. The vulnerable condition here depends on RADIUS-backed administrator groups, so a version-only check can miss the real exposure. Teams need to assess how the appliance authenticates administrators, not just whether it is on an affected branch.

Q: Should organisations keep RADIUS-backed appliance administration or move to local accounts?

A: That choice depends on operational need, but the key is to remove unnecessary trust paths. If centralised admin authentication is required, it must be tightly scoped and monitored. If it is not required, local accounts reduce one exposed dependency and simplify the attack surface on the management plane.

Technical breakdown

How the RADIUS admin path becomes the control-plane entry point

FortiWeb’s remote administrator workflow uses RADIUS to validate who may access the appliance management interface. In an improper authentication condition, the appliance accepts a login before correctly proving the user’s identity, which means the control intended to enforce administrative trust becomes the first thing an attacker targets. Because this is a control-plane path, success does not require exploiting the web traffic being inspected. It only requires reaching the management authentication flow and bypassing it. That distinction matters: the attacker is not breaking the firewall’s inspection logic, but its administrative gatekeeping.

Practical implication: Treat remote admin authentication as a privileged control plane and verify that the authentication decision is actually enforced before any session is established.

Why arbitrary credentials can still lead to privileged appliance access

The article describes pre-authentication access using arbitrary usernames and passwords. That pattern indicates the flaw is not about guessing a valid account, but about a broken acceptance condition in the login logic. Once the appliance incorrectly accepts the request, the attacker lands in the administrative context and inherits the same privileges as a legitimate operator. For a WAF, that can include policy changes, certificate access, key access, and log visibility. This is a classic example of management-plane identity collapse: the security device’s protection model is bypassed by the very mechanism that is supposed to protect the admin console.

Practical implication: Validate whether admin authentication is fail-closed under all configured identity paths, especially when central directory or RADIUS services are in use.

Why configuration state changes the real exposure profile

The article makes clear that the affected builds are not equally exposed in every environment. The vulnerable condition applies specifically where administrator logins are authenticated through a RADIUS admin group, while appliances using only local administrator accounts are in a different risk posture. That means version intelligence alone is insufficient. Exposure depends on how the management plane is wired, which is exactly why appliance administration cannot be assessed only from the firmware version or the product name. Identity architecture determines exploitability, not just code presence.

Practical implication: Build your exposure view from both software version and administrative authentication configuration, because the vulnerable condition is deployment-specific.

Threat narrative

Attacker objective: Gain privileged control of the FortiWeb management plane to change security policy, access sensitive appliance material, and reduce defensive visibility.

1. Entry occurs through the FortiWeb management interface when a remote attacker targets the RADIUS-backed administrator login path.
2. The authentication failure allows arbitrary credentials to be accepted, giving the attacker administrative access without valid identity proof.
3. With administrative control, the attacker can alter policies, access certificates and keys, and manipulate logs while observing protected traffic.
4. The impact is compromise of the appliance’s trust role at the network edge, which can weaken inspection and response across downstream applications.

Breaches seen in the wild

• LiteLLM MCP auth bypass 2026: An exploited LiteLLM MCP auth bypass and default sk-1234 master keys let attackers steal AI gateway master and provider API keys.
• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Management-plane identity is a high-value attack surface: When appliance administration relies on remote authentication, the identity path is no longer a simple access layer, it becomes part of the control plane itself. A flaw in that path can convert a security device into an administrative foothold. For practitioners, that means admin authentication design deserves the same scrutiny as the firewall policy it protects.

Configuration determines exploitability more than version labels do: The article’s key nuance is that affected builds are not uniformly vulnerable in practice. The exploitable condition depends on RADIUS-backed administrator groups, which means exposure is governed by deployment design, not just patch state. This is a reminder that effective governance needs configuration-aware asset inventory, not firmware inventory alone. Practitioners should map administrative trust chains explicitly.

Administrative trust collapse: This flaw illustrates what happens when the system that decides who may administer a device also becomes the system that fails to authenticate them. The governance assumption that centralised identity automatically strengthens appliance administration breaks down if the login gate is weak. Security teams should treat appliance admin flows as privileged identity systems that need separate verification and review.

WAFs inherit identity risk from the way they are operated: The appliance is deployed to reduce edge risk, yet its management plane often sits behind the same operational conveniences that make remote administration workable. That tension is not unique to FortiWeb. It applies anywhere privileged infrastructure depends on federated or external authentication. The practical conclusion is to separate administrative convenience from administrative assurance wherever possible.

RADIUS-backed administration needs tighter boundary control: The issue is not that RADIUS is inherently unsafe, but that any remote admin authentication path must be tested under failure conditions, bypass conditions, and configuration drift. Where the management plane can be reached remotely, the trust boundary is only as strong as the weakest auth decision. Practitioners should review these flows as part of PAM and device governance, not just network access policy.

What this signals

Administrative trust should be treated as a separate control domain: Appliance management is not just another access control problem. Once the admin path is exposed through remote identity infrastructure, a bypass can convert a perimeter control into an attacker-administered console. Teams should model management-plane identity as a privileged dependency, not a convenience feature.

The broader lesson is that security appliances can inherit the failure modes of IAM and PAM systems without inheriting their governance rigor. If a device can be administered remotely, the organisation needs explicit boundaries for authentication method, source network, and change accountability. That is where exposure is actually reduced.

RADIUS-backed admin flows need configuration-aware oversight: A version list alone does not answer whether a FortiWeb deployment is exposed. The decisive question is whether administrator access depends on the remote RADIUS path. That means exposure management has to join asset inventory, identity configuration, and privileged access review into one operational view.

For practitioners

• Inventory appliance admin paths Identify every FortiWeb instance and record whether administrator access uses a remote RADIUS admin group or only local accounts. Exposure depends on that configuration, so the inventory must capture the authentication method, not just the version.
• Restrict management-plane reachability Place the FortiWeb management interface behind a dedicated administration network and remove broad user-network reachability. This reduces the blast radius if authentication fails and keeps the control plane separate from production traffic paths.
• Disable unnecessary remote admin groups If local administrator accounts are sufficient for the operating model, remove RADIUS-based administrator groups to eliminate the vulnerable trust path. Keep only the authentication methods that are operationally required.
• Audit administrative activity for abnormal access Review FortiWeb administrator accounts, recent configuration changes, and login events for unexpected source addresses or unexplained privilege use. Administrative bypasses often show up first as changes that nobody planned.
• Confirm the fixed build directly with the vendor Use the advisory and upgrade path tool to verify the safe version for your branch before assuming a build is patched. Treat any affected branch as unpatched until the confirmed fixed release is installed.

Key takeaways

• The core issue is an improper authentication failure in the FortiWeb RADIUS admin path, which can let an unauthenticated attacker reach privileged management functions.
• The exposure is configuration-dependent, so version tracking alone is not enough to determine whether a deployment is actually at risk.
• Defenders need to inventory admin authentication methods, constrain management-plane reachability, and verify fixed builds directly before assuming the issue is remediated.

Key terms

• Management Plane: The administrative layer used to configure, govern, and enforce behaviour across many endpoints or services. A management plane is not the workload itself. It is the control layer above it, which makes it especially sensitive to privileged misuse and delegated automation.
• RADIUS Administrator Authentication: RADIUS administrator authentication is a remote login pattern where a device delegates admin verification to a central RADIUS service. It simplifies operations, but it also means the security of the admin path depends on the correctness of the device’s authentication handling and the trustworthiness of the upstream identity service.
• Pre-authentication Bypass: A pre-authentication bypass lets an attacker reach privileged functionality without first proving identity in the intended way. In practice, this means the control boundary fails before normal account checks, which is especially dangerous on appliances that govern traffic, certificates, or logging.
• Administrative Trust Boundary: An administrative trust boundary is the point where an organisation decides who may control a device, policy set, or management service. When that boundary is weak, the attacker does not need to defeat the business application, only the control path that governs it.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern credentials, privilege, and lifecycle control across modern identity estates.