Report generation could stall at 1% due to a crash in the reportd process when processing Attack Details data.

In certain cases, the Web Vulnerability Scan (WVS) runtime directory was initialized in an incorrect filesystem path (/var/log/lib/ rather than /var/log/wvs/). When this occurred, the WVS engine could not locate required working files, resulting in scan-startup failures, template-creation errors, and “Internal Server Error” responses when accessing Web Vulnerability Scan > Scan History.

FortiWeb experienced high memory consumption due to a memory leak in proxyd. The module did not release svrnm_sess_hash and associated SNI domain data during SSL context cleanup, causing heap growth over time.

Remote administrator logins using RADIUS experienced GUI failures. In HA mode, the secondary unit rejected API calls because the access profile name was not passed correctly, causing the GUI to log out when loading HA Topology. An input-validation error also caused widget actions to fail.

In some deployments using 10-Gbps i40e interfaces, a link-down event on one v-zone member did not propagate to the other port. Although FortiWeb reported the interface as down, the physical link remained active, preventing expected failover behavior. The issue was caused by the i40e driver not bringing down the PHY on interface close. The driver has been updated to ensure v-zone members drop link correctly when any member fails.

When the Login Disclaimer banner is enabled, the GUI becomes inaccessible and returns an ERR_EMPTY_RESPONSE error. The issue occurs due to a null pointer condition during cookie handling in the login disclaimer process.

Important: FIPS users are advised not to upgrade to this release, as the login disclaimer cannot be disabled in FIPS mode. Upgrading under these conditions results in loss of GUI access, leaving only SSH and console access available.

In True Transparent Proxy (TTP) mode, significant latency occurs during OCSP and TSP traffic forwarding, leading to client timeouts. This delay is caused by a processing bottleneck in the URL record module, where the proxy engine stalls while managing a large SQLite3 database of learned URLs. Under high-volume traffic, this database interaction prevents the timely transfer of packets between frontend and backend interfaces.

The proxyd process crashes during HA failover or execute ha manage operations due to a double-finalization of SQLite statements during URL record database initialization. This memory corruption occurs when sqlite3_prepare() fails and the system attempts to manually finalize an already invalid statement pointer, leading to a segmentation fault and service disruption on the secondary unit.

OFTP log forwarding did not resume after the connection to FortiAnalyzer was disrupted. The OFTP client failed to re-establish the transport session following events such as a FortiAnalyzer reboot or HA role change, leaving the session in a persistent “not ready” state and causing logs to remain queued rather than forwarded.

The proxyd process became unresponsive due to a client-management operation that performed slow Redis writes while holding a lock. This caused the proxy to hang, preventing traffic from being processed until the unit rebooted or failed over.

FortiWeb failed to authenticate administrators using FortiCloud SSO on some appliances with identical firmware. The SAML login process stopped due to missing certificate handling, preventing completion of the FortiCloud SSO flow.

When the HTTP Header Security (HHS) module was enabled with no rules configured, FortiWeb continued to buffer response data, which caused Server-Sent Events (SSE) responses to be dropped.

FortiWeb reset HTTP/2 requests when content routing was enabled. Under high HTTP/2 request rates, the Session Management module incorrectly counted individual requests as separate TCP connections, causing the request counter to accumulate and triggering period-block actions. This resulted in unexpected connection resets for all routed hosts.