Fortinet has published two critical advisories for unauthenticated remote code execution paths in FortiAuthenticator and FortiSandbox. CVE-2026-44277 affects FortiAuthenticator API endpoints and carries a CVSSv3 score of 9.1; Fortinet says crafted requests may let an unauthenticated attacker execute unauthorized code or commands [1]. CVE-2026-26083 affects the FortiSandbox, FortiSandbox Cloud, and FortiSandbox PaaS web UI with the same 9.1 score and unauthenticated attack type [2].
Fortinet marks both issues as not known exploited at publication time, but they still deserve fast treatment. FortiAuthenticator can sit near identity workflows, VPN access, MFA, and certificate-backed services, while FortiSandbox is often trusted to inspect suspicious files and network artifacts. A bug in either control plane can become more valuable than a normal application flaw because the product already lives in a security-sensitive path.
What Admins Should Prioritize
The first step is inventory, not panic. Check whether FortiAuthenticator is running versions 8.0.0 or 8.0.2, 6.6.0 through 6.6.8, or 6.5.0 through 6.5.6, then plan upgrades to 8.0.3, 6.6.9, or 6.5.7 respectively. Fortinet says FortiAuthenticator Cloud is not impacted. For FortiSandbox, check appliance, Cloud, and PaaS deployments against the advisory table: affected branches include FortiSandbox 5.0.0-5.0.1, 4.4.0-4.4.8, several FortiSandbox Cloud branches, and multiple PaaS releases that require migration to a fixed release.
The second step is exposure review. These products should not have broad management or web UI access from untrusted networks. Confirm which interfaces are reachable from the internet, VPN user ranges, partner networks, monitoring systems, and jump hosts. If the vulnerable service was reachable, preserve access logs before rotating or rebuilding anything. Useful triage artifacts include unexpected API or GUI requests, failed authentication bursts that are followed by unusual administrative actions, new local users, changed connectors, exported configuration files, modified certificates, and unexplained outbound traffic from the appliance.
Gridinsoft has covered several Fortinet incidents where the risk moved quickly from advisory to exploitation, including CVE-2024-47575 exploitation, a FortiClient EMS SQL/RCE issue, and older Fortinet VPN RCE flaws. The practical lesson is consistent: patch the affected product, but also look for evidence that the device was already used as a pivot point.
If a vulnerable system was exposed before patching, treat the appliance as a possible foothold. Export and preserve logs, compare configuration snapshots, review admin account changes, check integrations that receive tokens or credentials from the product, and rotate downstream secrets only after the appliance is updated or isolated. For security appliances, a clean version number is necessary, but it is not the same as a clean environment.
References
- Fortinet PSIRT, “Improper access control on API endpoints,” FG-IR-26-128 / CVE-2026-44277, May 12, 2026. Advisory
- Fortinet PSIRT, “Incorrect global authorization,” FG-IR-26-136 / CVE-2026-26083, May 12, 2026. Advisory
Related infrastructure risk: Cisco also patched an actively exploited Catalyst SD-WAN authentication bypass, another case where edge or control-plane systems need log review before routine patching.
For edge-service patching context, Gridinsoft also covered NGINX CVE-2026-42945, where rewrite-rule configuration determines whether a public-facing server is actually exposed.
