FortiWeb CVE-2025-64471

Exploitation requires the attacker to already possess a valid password hash for a FortiWeb account (administrator or user), obtained out-of-band such as from a leaked configuration/backup, exposed credential store, or a chained disclosure bug - the flaw itself does not reveal the hash. Given that hash, no cleartext password, prior session, or user interaction is needed: the attacker sends crafted HTTP/HTTPS requests to the FortiWeb management/authentication endpoint (AV:N/AC:L/PR:N/UI:N) and the appliance accepts the hash as proof of identity. The primary limiting factor is acquisition of the hash; the primary exposure factor is FortiWeb management interfaces reachable over the network. Affected versions: 8.0.0-8.0.1, 7.6.0-7.6.5, 7.4.0-7.4.10, 7.2.0-7.2.11, and 7.0.0-7.0.11.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N, base 7.5 HIGH) indicates a network-reachable, low-complexity, unauthenticated flaw with high integrity impact and no confidentiality or availability impact - Fortinet scored it purely as an integrity issue, though authenticating as a user via a stolen hash would plausibly also expose data (C:H), so the C:N/A:N scoring is arguably conservative. This is CWE-836 (use of password hash instead of password): the login flow accepts the stored password hash in place of the cleartext password, a classic pass-the-hash weakness. Critically, the vector rates PR:N because no session/credential is needed to send the request, but exploitation is gated on the attacker ALREADY possessing a valid password hash (e.g., from a database leak, config/backup exposure, or a chained vulnerability) - this precondition is not reflected in the CVSS score and materially lowers real-world likelihood versus a pure unauthenticated RCE. No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active exploitation: exploitation status is 'no public exploit identified at time of analysis.' Net assessment: a genuine and serious authentication-integrity weakness in an internet-facing Fortinet security appliance (a heavily targeted vendor class), but its practical priority hinges on whether an attacker can obtain the hash - making it a strong patch candidate rather than a confirmed mass-exploitation emergency at this time.

An attacker who has obtained a FortiWeb administrator or user password hash - for example from a leaked configuration backup, exposed database, or a separate disclosure flaw - sends crafted HTTP/HTTPS authentication requests to the management interface, submitting the hash directly where the password is expected. Because the appliance validates the hash instead of a cleartext password, the attacker authenticates without ever cracking it. No public exploit code is identified in the provided data.