Data Leak Prevention (DLP) configurations and predefined sensor settings were lost after upgrading from versions 8.0.3 or 8.0.4. This occurred because the internal storage path for the DLP Database (DLDB) changed, causing the system to default to version 0.00000 upon reboot if an active internet connection was unavailable to fetch a new update. Version 8.0.5 now includes a bundled DLDB image (v1.00055) to ensure configurations persist during the migration process for licensed units.

FortiWeb intermittently failed to forward HTTP GET requests to backend servers, resulting in page timeouts. This issue occurred on policies where specific Lua scripts were enabled, causing the proxy engine to stall during request processing.

GeoIP configurations were lost during the upgrade to v8.0.4. This occurred because the system failed to automatically back up the GeoIP database during the upgrade process, causing the subsequent configuration restore for country lists to fail with a Parsing error at 'country-name'. Users can restore the settings by reapplying a configuration backup after the GeoIP database has automatically updated on the new version.

Creating a VLAN on an aggregate interface failed with an error stating the interface name was too long, even if the user-defined name was short. This was caused by a kernel limitation where the combined length of the parent interface and the VLAN ID exceeded 15 characters.

The REST API returned a generic "500 Internal Server Error" instead of a meaningful error message when a PUT request was sent to the /server-policy/policy endpoint without the required mkey parameter. The API has been updated to handle missing parameters gracefully and return an appropriate "400 Bad Request" response.

FortiWeb units experienced a total loss of configuration and unexpected HA failovers due to a memory leak in the configuration database service (cmdbsvr). The leak occurred during shared memory mapping (mmap), eventually preventing the system from allocating enough memory to load the configuration. This resulted in "CLI parsing errors" during synchronization and service outages.

FortiWeb units occasionally displayed erroneous Bot Protection error messages on the console following an upgrade or HA failover. These false-positive logs were caused by stale session data and incomplete bot analysis synchronization between cluster members.

Requests containing internal /fwb URL paths were intermittently forwarded to backend servers instead of being intercepted by FortiWeb. This occurred because a JavaScript file used by the AJAX Block module exceeded its maximum size limit, causing the module to fail and pass the traffic directly to the backend.

"FortiWeb DLDB is unauthorized" event logs are incorrectly generated on devices without a Data Leak Prevention (DLP) license. This issue results from the update daemon attempting to validate the Data Leakage Database (DLDB) contract status and logging a failure despite the service not being purchased or enabled.

In monitor mode, high memory usage occurs within the proxyd process when the HTTP Protocol Constraint (HPC) module encounters malformed requests. This depletion of system memory is caused by the HPC module triggering custom error responses for abnormal traffic while the proxy engine fails to parse or release the response context under monitor mode constraints.

CAPTCHA and reCAPTCHAv3 challenges failed to validate, leading to unexpected client blocks. This was caused by two primary factors: background browser requests for favicon.ico triggering unintended Real Browser Enforcement (RBE) redirections, and overlapping bot confirmation settings between Custom Access and Threshold-Based Detection policies. The RBE engine now handles favicon requests as empty data to prevent verification failure, and session management logic has been improved to ensure correct bot confirmation state across multiple policy types.

FortiWeb intermittently used TLS v1.0 to communicate with backend servers even when the server did not support that version, leading to "Fatal Protocol Version" alerts and connection failures. This occurred in True Transparent Proxy (TTP) mode when specific intermediate TLS versions were disabled, creating a gap in the supported protocol list.

IP group imports through the GUI fail without a visible error message when the destination group name contains spaces. This issue occurs because the CGI API incorrectly parses the management key (mkey) as only the first string before the whitespace rather than the full name, causing the system to attempt the import on a non-existent group.

URL rewrite rules fail to modify response headers, such as the Location header, when the server response body is empty. This issue occurs because the URL rewrite module incorrectly blocks all rewrite operations for responses with a body size of zero, preventing necessary header transformations (e.g., rewriting HTTP to HTTPS) even when the regex patterns match successfully.

Periodic CPU spikes occur during background Redis data persistence, particularly in high-traffic environments. This performance degradation is caused by the RDB compression mechanism consuming excessive CPU resources while saving client management data to disk. These intermittent spikes can reach critical levels on the primary unit in HA clusters, leading to resource exhaustion.

SQL/XSS Syntax Based Detection incorrectly triggered "Arithmetic Operation Based Boolean Injection" blocks for legitimate traffic containing domain names (e.g., uae.abd-dymgabcd.com). This regression occurred in version 7.6.5 due to an overly sensitive parsing of hyphenated domain strings. The detection engine has been tuned to correctly distinguish between domain name formatting and arithmetic SQL injection attempts.

gRPC traffic over HTTP/2 experienced intermittent failures and "Bad Firstline" parse errors during streaming sessions. This occurred because the internal parser incorrectly attempted to reset the HTTP/1.1 selector while processing gRPC request bodies, causing subsequent streams to be misinterpreted and closed. The parser logic has been updated to correctly maintain the HTTP/2 state for gRPC body data.

When a client initiated an HTTPS request to a port configured for plain HTTP, FortiWeb failed to parse the encrypted headers and automatically fell back to a "no-parse" mode, forwarding the raw traffic to the backend server. A new allow-nonstd-http option has been added at the policy level to control this behavior. While traffic is still forwarded by default, administrators can now configure the policy to close the connection if the initial request cannot be parsed as standard HTTP.

Disabling a Server Pool member did not consistently terminate existing HTTP sessions. This occurred because abnormal or malformed TCP segments, such as continuation packets, caused the HTTP parser to enter a "no-parse" state. This state bypassed the server-status check and allowed traffic to continue flowing to the disabled backend server. The proxy engine has been updated to ensure that once a server is disabled, all associated sessions are terminated immediately regardless of parsing state.