Fortinet October 2026 advisories patch FortiSandbox and FortiSIEM flaws

Fortinet's October 13, 2026 advisory batch closes thirteen vulnerabilities across FortiAnalyzer, FortiManager, FortiMail, FortiSIEM, and FortiSandbox, and two of them are critical and pre-authenticated. CVE-2026-106173, tracked as FG-IR-26-180, is a CWE-22 path traversal in FortiSIEM that lets an unauthenticated attacker execute unauthorized code or commands via specially crafted packets; Fortinet scores it 9.4, lists FortiSIEM 7.5.0 as the only affected release, and fixes it in 7.5.1. CVE-2026-107656, tracked as FG-IR-26-185, is a CWE-288 authentication bypass in the FortiSandbox GUI reachable with crafted HTTP requests, scored 9.6, affecting FortiSandbox 5.0.0 through 5.0.6 and 4.4.0 through 4.4.9. Both advisories say the flaws were found internally, both list Known Exploited as No, and the Canadian Centre's rollup AV26-1037 confirms the same fix branches government-side.

Both targets are appliances at the center of a security estate, not at its edge, which changes what a successful attack means. A FortiSIEM box ingests every log stream an organization emits, plus service credentials and network topology, so pre-auth RCE there is not a foothold but a takeover of the victim's own detection layer, with the attacker reading and potentially reshaping the telemetry defenders rely on. A FortiSandbox box detonates untrusted files and records what malware does, so an auth bypass on its GUI hands over a curated inventory of the samples and attacker tooling already under analysis. Fortinet marks both as not known exploited and neither sits in CISA's KEV catalog, but that label has a short shelf life with this vendor: the October 1 FortiMail advisory CVE-2026-104286, CVSS 9.8, moved from publication to a confirmed-exploitation flag within a week, and its PSIRT page still carries Known Exploited as Yes. Two unauthenticated criticals in one drop against management-plane products is the profile that historically gets weaponized fastest, which is why this batch matters more than the other routine patch Tuesday noise.

Patch order writes itself from the vendor data. Move FortiSIEM 7.5.0 to 7.5.1 or later, noting branches 7.6 and FortiSIEM Cloud are unaffected; if the patch window is tight, Fortinet's own workaround applies, restricting access on tcp port 27918, which it states prevents the path traversal. Move FortiSandbox to 5.0.7 or 4.4.10 depending on branch, and start the FortiSandbox PaaS 4.4 migration planning immediately because that line has no in-branch fix and Fortinet's only guidance is to migrate to a fixed release, making it the slowest item to close. After patching, audit perimeter exposure of tcp 27918 and the FortiSandbox web interface, then sweep pre-patch logs for external sources reaching the FortiSIEM phQueryMaster grpc service on 27918 and for FortiSandbox GUI sessions that lack a matching successful authentication record.

Two developments would change this assessment. A flip to Yes on Known Exploited in either PSIRT entry, or a KEV listing for either CVE, converts a patch sprint into a compromise assessment with log retention suddenly too short. And any updated timeline entry on FG-IR-26-180 or FG-IR-26-185, the way FG-IR-26-175 gained an update on October 7, would signal Fortinet sees pressure on these flaws; watch the advisory pages directly rather than feed reposts, since the reposts lag the flag that matters.