رأس القلم

Fortinet November 2026 Updates: FortiOS and FortiManager Checks

Fortinet’s November 10, 2026 advisories require several distinct remediation decisions. The affected paths include FortiOS OSPF, FortiManager FGFM, fortilogd high-availability state and dmserver authorization across VDOMs. One product’s fixed release cannot be copied into another product’s ticket.

This review reconciles four official advisories checked November 11. Each currently displays Known Exploited: No. That vendor field is a dated assessment, not proof that a particular deployment was never targeted. The matrices below are proposed patch-verification aids, not exploit reproductions.

Map the vulnerable component before choosing a release

AdvisoryVerified condition and impactOwner evidence
CVE-2026-126253, FG-IR-26-267Authentication weakness in FortiOS/FortiSASE OSPF daemon; an unauthenticated attacker may broadcast LSA.Product, release, OSPF deployment and routing owner.
CVE-2026-126261, FG-IR-26-275Unauthenticated attacker able to reach FortiManager FGFM may execute code or commands.Manager release and approved FGFM network paths.
CVE-2026-126184, FG-IR-26-229Spoofing-related authentication bypass in fortilogd may disrupt HA state.Exact affected product, release and HA topology.
CVE-2026-126229, FG-IR-26-244An authenticated administrator may access other VDOMs through dmserver.Administrative role, intended VDOM scope and active release.

المصادر: OSPF advisory, FGFM advisory, fortilogd advisory و dmserver advisory. Their component labels are not substitutes for the technical summaries: the FGFM entry is labeled GUI while its summary specifically requires FGFM reachability. Inventory the service described in the summary.

FortiOS: use the OSPF advisory’s branch mapping

FortiOS branchAffected range in FG-IR-26-267First listed fixed release
8.08.0.0–8.0.18.0.2
7.67.6.0–7.6.77.6.8
7.47.4.0–7.4.127.4.13
7.27.2.0–7.2.137.2.14

These thresholds apply to this OSPF advisory. They do not certify the entire appliance against all Fortinet vulnerabilities. Match FortiGate hardware to its actual FortiOS release, then use Fortinet’s supported upgrade path. Check routing health and the intended OSPF relationships after deployment through ordinary administrative views.

FortiSASE has its own rows. The advisory says Fortinet remediated the listed 26.3.1 and 26.3.1_a releases in 26.3.2 without customer action; several earlier listed branches require migration. Preserve the tenant’s exact branch and applicable vendor statement rather than applying FortiOS firmware numbers to the cloud service.

FortiManager: compare fixes across advisories

الفرعFGFM 126261fortilogd 126184dmserver 126229
8.08.0.18.0.28.0.2
7.67.6.87.6.87.6.8
7.47.4.67.4.127.4.12
7.27.2.97.2.13Migrate to a fixed release

The table lists first fixed releases for FortiManager from those three advisories. A manager updated to 8.0.1 can meet the cited FGFM threshold while still falling within the affected range for the other two issues. Similarly, 7.2.13 fixes the cited fortilogd issue, but the dmserver advisory lists all FortiManager 7.2 versions as affected and requires migration. Closing a batch on the lowest threshold would leave unresolved work.

A later supported build containing the required corrections may be appropriate, subject to compatibility and the documented upgrade path. The matrix is an intersection of the cited requirements, not approval to skip intermediate upgrades or a complete release recommendation for every appliance.

Keep FortiAnalyzer and cloud products separate

FG-IR-26-229 and FG-IR-26-244 also cover FortiAnalyzer and specified cloud products. The former lists FortiAnalyzer 7.2.13 as fixed; the latter requires migration for the 7.2 branch. This same difference matters when a manager and analyzer are upgraded in one maintenance window.

Do not extend the FortiManager-only FGFM threshold to FortiAnalyzer. Where the fortilogd summary names additional products without a visible product/version solution row, obtain the applicable vendor guidance rather than inventing a build. Keep the unresolved row assigned to its service owner.

Verify deployment and security boundaries separately

Before maintenance, retain product identity, branch, all relevant advisory IDs, cluster members, approved management paths and backup/change references. Use existing configuration and network-policy records to assess reachability. An Internet scan that cannot see FGFM does not establish that every internal route is controlled.

After the supported upgrade, capture the active release on each serving and standby member. Check ordinary manager-to-device registration and HA health. For dmserver, use approved test administrators and synthetic objects in a controlled environment to compare allowed access with access outside the administrator’s intended VDOM scope. Record expected and observed results without collecting customer data.

Keep the version check, configuration assessment and authorization observation as separate evidence. No single healthy dashboard proves all three. Investigate unexplained historical administrative changes through the incident-response process independently of the upgrade.

Method: AI-assisted research and drafting from the four Fortinet advisories, checked November 11, 2026. This article provides source reconciliation and proposed acceptance criteria. It does not claim appliance testing, active exploitation or a Fortinet integration in Penligent.

شارك المنشور:
منشورات ذات صلة
arArabic