FortiManager Authentication Bypass CVE-2026-22572 Response Guide

A centralized firewall-management platform solves an important operational problem: it gives security teams one place to control policy across a large estate. That same concentration of authority also changes the risk equation. If the management plane is compromised, an attacker may be positioned close to the controls that organizations depend on to protect networks and enforce security policy.

That is why Fortinet's disclosure of an authentication weakness affecting FortiManager deserves prompt attention from operators. Fortinet advisory FG-IR-26-090 identifies CVE-2026-22572 as a multifactor-authentication bypass involving an alternate path or channel (CWE-288). According to Fortinet, an attacker who already knows an administrator's password may be able to bypass multifactor-authentication checks by submitting multiple crafted requests.

Organizations should use the Fortinet PSIRT advisory portal and the product-specific advisory as the authoritative sources for affected releases and remediation instructions. Because vulnerability information can be updated after initial publication, security teams should verify their exact deployed versions against the current advisory rather than relying on a static vulnerability summary.

For many organizations, a firewall is a control point. FortiManager is a control point for those control points.

Fortinet positions FortiManager as centralized management for Fortinet security infrastructure, supporting policy administration, configuration and automation across managed devices. That makes authentication around the management layer especially important.

An authentication bypass is a weakness that can allow normal authentication controls to be circumvented under particular conditions. "Alternate path or channel" is the terminology associated with CWE-288, where access may be possible through a route that does not enforce authentication in the expected way. In CVE-2026-22572 specifically, Fortinet states that exploitation requires knowledge of an administrator's password and can bypass multifactor-authentication checks.

The business question is therefore broader than whether a management server can be accessed. Security leaders need to consider what authority that server holds and which systems, policies and administrative workflows depend on it.

A compromised management plane can create risks around configuration integrity, administrative control and security visibility. Even where exploitation has not been observed, a vulnerable system with broad security-management privileges warrants a faster response than its position in a normal patching queue might suggest.

Fortinet published remediation information through its Product Security Incident Response Team (PSIRT). The relevant advisory is FG-IR-26-090, concerning CVE-2026-22572 and multifactor authentication in FortiManager and FortiAnalyzer.

Fortinet rates the vulnerability Medium severity with a CVSS v3 score of 6.8. The advisory classifies the attack type as authenticated because an attacker must know an administrator's password. Fortinet lists affected FortiManager releases in the 7.2, 7.4 and 7.6 branches and provides fixed-release or migration guidance for each affected branch.

Security teams should be careful not to mix this issue with other Fortinet authentication vulnerabilities disclosed during 2026. Fortinet has issued multiple separate advisories concerning authentication and management functionality, with different prerequisites, affected versions and exploitation statuses.

Fortinet's advisory currently lists CVE-2026-22572 as not known to be exploited. That distinction matters. Absence of verified exploitation is not evidence that a vulnerable deployment is safe, but neither should organizations label the vulnerability a zero-day campaign without supporting evidence.

The appropriate response is disciplined remediation and monitoring rather than speculation.

Before examining logs, a security team needs an accurate inventory.

Centralized management environments can include physical or virtual FortiManager appliances, multiple administrative domains and systems at different software levels. Acquisitions, branch deployments and infrastructure operated by separate IT teams can make the actual footprint less obvious than the configuration-management database suggests.

Start by identifying every FortiManager instance under organizational control. Record its software version, management interfaces, network exposure, administrator configuration and the devices or environments that depend on it.

Then compare those versions directly with Fortinet's current PSIRT information and follow the remediation specified for the relevant release branch.

Do not infer that an older or newer release is vulnerable solely from its version number. Use Fortinet's affected-version and solution tables.

Installing a fixed release addresses the vulnerability itself. Hardening the paths to FortiManager reduces the opportunities available to an attacker before and after this particular issue.

Fortinet's own FortiManager security best practices recommend limiting administrator access, including through trusted hosts and interface access controls. Fortinet also recommends disabling unused interfaces, keeping firmware current and placing FortiManager behind a firewall to limit access attempts.

Trusted hosts can restrict where an administrator is permitted to connect from. Fortinet documentation notes that when trusted hosts are configured for all administrators, administrative access can be restricted to specified hosts or networks.

That principle translates into a simple architectural goal: administrative services should be reachable only from networks and systems that genuinely need them.

For an enterprise, that can mean placing the management plane behind appropriate network controls, restricting administration to approved management networks or jump systems and reviewing privileged access rather than exposing administrative interfaces broadly.

Patching answers one question: "Are we still vulnerable?"

Monitoring answers another: "Did anything suspicious happen before we patched?"

Because CVE-2026-22572 concerns bypass of multifactor-authentication checks by an attacker who already knows an administrator's password, teams should review FortiManager administrative authentication for unusual activity, particularly unexpected source addresses, abnormal login patterns, privileged-account activity and configuration changes that cannot be tied to approved operational work.

Attention should also extend to FortiGate-to-FortiManager communication as part of the broader management-plane review. FGFM is the protocol used for communication between FortiGate and FortiManager. Because that relationship supports centralized device administration, unexplained changes in FGFM connectivity or management relationships deserve investigation. However, Fortinet's advisory for CVE-2026-22572 identifies the affected component as the GUI rather than FGFM.

This is also where a security information and event management (SIEM) platform becomes useful. Instead of leaving Fortinet administrative events isolated on individual systems, organizations can correlate them with identity, endpoint, network and other security telemetry.

A suspicious administrator login becomes considerably more meaningful when it coincides with an unusual source system, privileged-account activity and unapproved firewall-policy changes.

Organizations running potentially affected infrastructure should treat remediation as both a vulnerability-management task and a management-plane security review.

1. Inventory FortiManager infrastructure. Identify FortiManager deployments, their versions, administrative interfaces and the infrastructure under their control.
2. Check the current Fortinet advisory. Review FG-IR-26-090 and the wider Fortinet PSIRT portal for current affected-version and remediation information.
3. Upgrade to the appropriate fixed release. Follow Fortinet's supported remediation and upgrade guidance, with the normal configuration backup, change-control and rollback precautions required for security-management infrastructure.
4. Reduce management exposure. Restrict FortiManager administration to trusted management networks and approved administrator systems wherever operationally practical.
5. Review privileged access. Validate administrator accounts, access profiles, multifactor authentication and trusted hosts. Investigate unexpected accounts or unexplained privilege changes.
6. Examine recent authentication and configuration activity. Look for abnormal administrative logins, unusual sources and policy or configuration modifications that do not match authorized changes.
7. Review management relationships. Investigate unusual FGFM activity and unexpected changes involving managed FortiGate devices as part of the broader management-plane assessment.
8. Escalate suspicious evidence. If the review identifies unexplained privileged access or security-policy changes, move beyond patch management into incident-response procedures and preserve relevant logs and configuration evidence.

For long-term hardening, see our guide to Managed Cybersecurity for GCC SMBs.

Centralized security management is particularly useful for organizations operating distributed environments across the GCC. A business may have headquarters in Saudi Arabia, cloud workloads in the UAE, branches in Oman or elsewhere in the region, and infrastructure teams administering security controls across multiple sites.

That distribution makes centralized management efficient, but it also means management-plane security can have consequences well beyond one server or office.

For organizations in Saudi Arabia, the UAE and Oman, the practical lesson is to treat firewall-management infrastructure as privileged security infrastructure rather than routine administrative tooling. Patch governance, network segmentation, privileged-access control, logging and incident-response readiness should reflect the authority these systems possess.

The same operational principle applies more broadly across MENA: fixing CVE-2026-22572 should not be the end of the exercise if a centralized management service can be reached from more networks than necessary, uses broadly accessible administrative interfaces or produces logs that are not actively monitored.

The better outcome is a smaller management attack surface and stronger visibility after the patch is installed.

Authentication vulnerabilities highlight a difficult reality for infrastructure teams: preventive security controls cannot be evaluated separately from the systems that administer them.

A well-configured firewall estate is stronger when its management platform is patched, tightly accessible and monitored. Conversely, good perimeter rules cannot compensate for unnecessary exposure of privileged management services.

This is where vulnerability management, firewall management and security monitoring need to work together. Cyberactics can support GCC and MENA organizations across these areas, including managed SIEM, network-security projects and incident-response support. The objective is not simply to close one CVE, but to understand whether the management environment remains appropriately protected around it.

Organizations operating affected FortiManager releases should verify their deployments against Fortinet's current advisory, apply the specified fixed releases or migration guidance, and review administrative activity for anything that cannot be explained by legitimate operations.

Fortinet currently lists CVE-2026-22572 as not known to be exploited. That should keep the response evidence-led, not slow it down.

For organizations unsure whether their Fortinet management plane is affected or adequately isolated, Cyberactics can help assess exposure, support remediation, strengthen firewall management and integrate relevant security events into ongoing monitoring and incident-response processes.