FortiGate IPS Engine High CPU After a FortiOS Upgrade: Diagnosis and Fix

Fortinet has documented at least two instances of this pattern, one affecting FortiOS v7.2.9 and v7.2.10 with IPS engine version 7.00342, and the underlying trigger is the same combination of conditions in each case: proxy-mode inspection with an Application Control security profile enabled, combined with the SSL/SSH Inspection profile's "inspect-all" option turned on, either in the SSL/SSH profile or in protocol options. When all of those conditions are present, the IPS engine's process-level CPU consumption climbs sharply, with individual ipsengine processes reported consuming anywhere from roughly 19 percent up to 99 percent of a core depending on traffic load and the specific build. A FortiGate running flow-based inspection instead of proxy-based, or one without Application Control enabled on the affected policies, will not trigger this regression even on the same FortiOS and IPS engine version, which is why the same upgrade can look completely fine on one deployment and severe on another with a different policy profile.

Before treating any post-upgrade CPU spike as this specific IPS engine regression, rule out the more mundane explanation that traffic volume or the number of concurrently inspected sessions has genuinely grown past what the appliance was sized for, independent of anything the upgrade changed. An upgrade that coincides with a seasonal traffic increase, a newly added SSL inspection policy covering more of the network than before, or additional security profiles enabled during the same maintenance window as the upgrade can all produce a CPU increase that has nothing to do with an IPS engine defect. The distinguishing diagnostic detail in Fortinet's own documentation is that the affected regression shows CPU load concentrated specifically in the ipsengine processes and, at the system level, CPU time reported as system space rather than user space, which is a different signature from a firewall that is simply processing more legitimate traffic across all its inspection processes evenly.

Run get system status to confirm the exact FortiOS build and get system auto-update versions to confirm the currently running IPS engine version, since the regression is tied to specific version combinations, not to FortiOS upgrades generically. If the FortiOS version and IPS engine version match a documented affected combination, proceed to process-level confirmation rather than assuming the match alone proves the cause, since a device can be running an affected version combination without the triggering policy configuration also being present.

Use get sys perf stat for a system-wide performance snapshot and diagnose sys top 2 50 to view CPU consumption broken out by process across cores. If multiple ipsengine processes appear individually consuming a large share of a core each, and get sys perf stat shows the load concentrated in system space, that is consistent with the documented regression rather than ordinary traffic growth. To confirm the IPS engine specifically, rather than inferring it from process names alone, run diagnose test application ipsmonitor 5 with bypass mode enabled, which allows IPS to pass traffic without inspecting it; if CPU usage drops meaningfully with bypass enabled, the IPS engine's inspection workload is the cause, and if CPU stays high with bypass enabled, the bottleneck lies elsewhere and this specific regression is not the explanation. Bypass mode disables inspection entirely while enabled, so treat it as a diagnostic step for a brief, controlled test window, not a standing configuration, and re-run the same command with bypass disabled to restore normal inspection once the test is complete.

The fastest way to stop the CPU spike without waiting for a new IPS engine build is to remove one of the three triggering conditions from the affected policies: switch the policy from proxy-based to flow-based inspection where that is acceptable for the traffic being inspected, disable Application Control on the affected proxy-mode policies, or disable inspect-all in the SSL/SSH Inspection profile and protocol options in favor of a narrower inspection scope. Each of these is a real reduction in inspection coverage, not a cosmetic change, so weigh which one is least disruptive to the organization's actual security requirements rather than defaulting to whichever is fastest to click through. A separate, lower-risk workaround documented by Fortinet is downgrading specifically the IPS engine, independent of the FortiOS version, back to a known-good build such as 7.00341, which can be done without a TAC-issued engine file in some cases via diagnose autoupdate downgrade enable, or disabling automatic IPS engine updates under config system autoupdate schedule to prevent the affected engine version from being pulled down again during the investigation.

Fortinet's permanent fix for the documented regressions is an updated IPS engine version, not a FortiOS patch, specifically 7.00345 or later (shipped alongside FortiOS v7.2.11), 7.00551 or later for the v7.4.6 branch, or 7.01021 or later for the v7.6.1 branch. Apply the update through the normal IPS engine update mechanism once available, or through Fortinet's manual IPS engine upgrade process if automatic updates are disabled as part of the temporary workaround above. Re-enable automatic IPS engine updates only after confirming the fixed engine version has actually been applied, since leaving automatic updates disabled indefinitely as a permanent state means the appliance stops receiving IPS signature updates as well as engine updates, which is a materially different and larger risk than the CPU regression it was disabling to avoid.

After applying either the workaround or the permanent engine update, re-run get sys perf stat and diagnose sys top 2 50 under representative production traffic, not immediately after a reboot when session counts and inspection load are artificially low, since a CPU measurement taken minutes after a change with light traffic will look fine regardless of whether the underlying issue was actually resolved. Confirm the fix across a realistic sample of the traffic patterns the firewall handles, not just a single test flow, since the regression is triggered by specific inspection profile combinations that may only be exercised by certain traffic types or times of day. If a policy-level workaround was applied, such as disabling inspect-all, confirm the intended scope of SSL inspection coverage is still acceptable to the security team, not only that CPU usage dropped, since a fix that reduces CPU by silently reducing inspection coverage below what policy requires is not actually resolved.

Disabling automatic IPS engine updates as a temporary workaround and then forgetting to re-enable them once the permanent fix is applied leaves the appliance permanently behind on both engine and signature updates, which can surface much later as an unrelated gap in intrusion prevention coverage that has nothing to do with the original CPU issue. A policy-level workaround, such as switching from proxy-based to flow-based inspection, can resolve CPU load while quietly changing what the SSL/SSH inspection profile is actually able to inspect, which may not be noticed until a separate security review flags reduced visibility into encrypted traffic. Applying the updated IPS engine to only some of a cluster or HA pair while the CPU-monitoring alert continues to fire on unpatched members can also look like the fix failed when in fact it was applied incompletely, since Fortinet's fix is delivered per-device through the IPS engine update mechanism, not automatically synchronized across an HA pair by the fix itself.

Escalate to whoever manages the organization's security policy and inspection standards before applying a policy-level workaround such as disabling Application Control or inspect-all on production traffic, since that is a real reduction in inspection scope that should be a security-team decision, not a unilateral performance fix. Escalate to Fortinet TAC directly when the documented workaround and engine update do not resolve the CPU load, when the affected FortiOS or IPS engine version does not match a publicly documented Technical Tip, or when a manually issued IPS engine file is needed for a downgrade rather than the standard update mechanism, since TAC support is the path Fortinet documents for obtaining those files. Escalate to capacity planning if diagnostics rule out the IPS engine specifically, per the ipsmonitor bypass test, and CPU load remains high, since at that point the cause is more likely genuine traffic growth or appliance sizing rather than a version-specific regression, a distinction covered in more depth in our firewall platform migration guide for organizations evaluating whether current hardware still fits current traffic.