CVE-2025-25257: FortiWeb unauthenticated SQL injection

CVE-2025-25257 is a critical SQL-injection vulnerability in the FortiWeb administrative GUI. Fortinet states that an unauthenticated attacker can send crafted HTTP or HTTPS requests to execute unauthorized SQL code or commands. Fortinet observed exploitation in the wild, and CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on 2025-07-18.

The durable remediation is to move every affected FortiWeb appliance and HA peer to a vendor-supported release at or above the fixed threshold for its release branch. Fortinet's documented workaround is to disable the HTTP/HTTPS administrative interface while an upgrade is pending. That workaround affects management access and requires the appliance owner; it is not permission for a repository agent to change a live device.

Evidence basis and limits

I reviewed Fortinet PSIRT advisory FG-IR-25-151, Fortinet's FortiWeb CLI documentation, the CISA KEV feed, the CVE record, and the NVD record on 2026-07-22. I did not access a FortiWeb appliance, inspect private firmware source, send a crafted request, or validate a customer deployment. The version, impact, workaround, and exploitation statements in this recipe are therefore official advisory facts, not observations from a live target.

The current official interfaces agree that the issue is critical, although the displayed CVSS value has varied between official records. This recipe does not depend on a particular score: the unauthenticated attack path, KEV status, and exact vendor version matrix establish the remediation priority. Re-check FG-IR-25-151 before approving a change because Fortinet can revise product or upgrade guidance.

When to use this recipe

Use it when a scanner, inventory, ticket, repository, or operator identifies a FortiWeb appliance that may run one of the affected 7.0, 7.2, 7.4, or 7.6 releases. The repository may own firmware targets, VM image references, FortiWeb Manager jobs, infrastructure definitions, inventory policy, upgrade runbooks, monitoring checks, or vulnerability exceptions.

Do not use this recipe to probe an administrative listener, reproduce SQL injection, copy an exploit, or make an unapproved firmware or interface change. Repository authority is not authority over a FortiWeb appliance. When the repository does not own the live device or its change path, produce a bounded triage and operator handoff.

Inputs

• A redacted inventory of every potentially affected appliance and HA peer: owner, environment, model or VM form factor, deployed firmware version, build, HA role, and evidence timestamp.
• Approved read-only version evidence from get system status, FortiWeb Manager, an authenticated asset inventory, or an operator-provided export.
• Administrative-interface evidence: whether HTTP and/or HTTPS management is enabled, listening interfaces, approved source networks, intervening access controls, and whether an untrusted network can reach the listener.
• Repository-controlled firmware/image references, deployment definitions, FortiWeb Manager jobs, runbooks, policy checks, generated artifacts, and vulnerability exceptions.
• The vendor-supported target release and upgrade path for each hardware/VM model, plus compatibility, storage, HA sequencing, maintenance-window, backup, health-check, and rollback evidence.
• Approved security evidence for the exposure window: relevant administrative and system logs, alerts, configuration-change records, incident owner, and Fortinet support status.

Do not commit appliance credentials, serial numbers, certificates, license files, full configuration exports, support bundles, raw logs, topology, or customer data. Preserve sensitive evidence only in an approved operational or incident-response system.

Affected and fixed versions

Fortinet publishes this exact version matrix:

FortiWeb branch	Affected releases	First fixed threshold
7.6	7.6.0 through 7.6.3, inclusive	7.6.4 or later
7.4	7.4.0 through 7.4.7, inclusive	7.4.8 or later
7.2	7.2.0 through 7.2.10, inclusive	7.2.11 or later
7.0	7.0.0 through 7.0.10, inclusive	7.0.11 or later
6.4	Not affected according to FG-IR-25-151	No CVE-specific upgrade required

Use a currently supported, vendor-approved target compatible with the exact appliance rather than treating an old minimum fixed release as a preferred long-term pin. Do not downgrade to 6.4 as a workaround. For any branch or model not represented in the table, consult the current Fortinet advisory and support guidance rather than inferring status.

Version evidence must cover every HA member, replacement image, disaster- recovery appliance, and generated deployment artifact. A fixed active peer is not evidence that its standby peer or next replacement instance is fixed.

How to determine exposure safely

Fortinet documents get system status as a read-only command that reports the firmware version, build, and HA information:

get system status

Run it only through an approved administrative channel, and redact serial numbers or other device identifiers before attaching evidence to a review. Then classify each target independently:

1. Confirm that the product is FortiWeb and record the exact release/build for every appliance or HA member.
2. Compare that release with the vendor matrix above. Desired-state files or a scanner string alone do not prove the deployed version.
3. Establish whether the HTTP or HTTPS administrative interface is enabled and which interfaces and source networks can reach it.
4. Trace the effective management path using approved configuration, firewall, load-balancer, VPN, and inventory evidence. An internal listener has reduced reachability, but it is not automatically unreachable to an attacker who has a foothold on that network.
5. Record the exposure window and whether existing logs or alerts indicate suspicious administrative requests, database activity, configuration changes, unexpected accounts, or other compromise concerns.

Do not send a crafted HTTP/HTTPS request, SQL fragment, path, callback, or other active probe. The deployed version and management-interface evidence are sufficient to decide that remediation is required.

Incident-response gate

Because Fortinet observed exploitation and CISA classifies this CVE as known exploited, resolve the incident-response question before routine patching:

• If approved evidence suggests attempted exploitation or compromise, stop the patch-only workflow. Preserve relevant logs and configuration evidence, notify the incident owner, and engage Fortinet support through the approved channel.
• Do not reboot, erase logs, rotate credentials, remove accounts, or clean artifacts until the incident owner decides what evidence must be retained.
• Do not conclude that an appliance is clean because a single indicator or alert is absent.
• A fixed firmware release closes the vulnerable entry point; it does not by itself establish the trustworthiness of an appliance that may already have been compromised.

This gate is conservative incident handling derived from the confirmed in-the-wild exploitation status. FG-IR-25-151 does not publish a complete forensic checklist for every deployment.

Temporary containment

Fortinet's documented workaround is to disable the HTTP/HTTPS administrative interface. Treat that as a temporary, owner-approved containment while the fixed firmware is being prepared, not as permanent remediation.

Before applying it, document the alternate management path, availability and support impact, HA implications, approving owner, exact scope, validation, expiry, and restoration plan. Do not disable the only safe management path or lock operators out of an appliance. If the repository cannot prove that the workaround is safely applicable, record it as an operator decision in TRIAGE.md; do not invent a FortiWeb CLI change.

Network isolation or source restriction can be considered as defense in depth by the responsible network owner, but it is not the workaround named in FG-IR-25-151 and it does not make affected firmware fixed.

How to remediate CVE-2025-25257

1. Inventory every affected appliance, HA peer, VM image, and recovery artifact before selecting a target release.
2. Resolve the incident-response gate. When compromise is suspected, preserve evidence and follow the incident owner's recovery decision before an ordinary upgrade.
3. Select a currently supported Fortinet release at or above the correct branch threshold. Validate the model-specific upgrade path and each required hop against current Fortinet documentation and support guidance.
4. Back up configuration and other required recovery data through the existing approved process. Keep sensitive backup artifacts outside Git, and confirm that the recovery owner can use them.
5. Update every repository-controlled firmware target, VM image reference, FortiWeb Manager job, inventory rule, runbook, policy check, and generated artifact consistently. Do not leave a standby or replacement path pinned to an affected build.
6. Document the human operator's HA sequence, expected management and traffic impact, stabilization checks, maintenance window, and rollback decision. The agent must not execute an appliance upgrade unless the task explicitly grants that exact live-device authority.
7. Remove temporary containment only after an authorized operator verifies the fixed release on every target and confirms that the approved management exposure is restored as intended.

How to verify remediation

• Re-run the read-only get system status check on every appliance and HA peer and compare the deployed release/build with the applicable fixed threshold.
• Confirm the running artifact, not only the desired-state pin, inventory target, or uploaded firmware image.
• Confirm all repository-controlled images, jobs, generated outputs, and recovery definitions resolve to the reviewed fixed target.
• Run the existing non-adversarial FortiWeb health checks for normal proxy/WAF traffic, administrative access, monitoring, logging, HA state, and failover readiness. Do not use a SQL-injection or crafted-request test.
• Confirm temporary interface containment was either retained with an owner and expiry or removed through the approved plan after fixed-version evidence was collected.
• Record target, HA role, before/after release, build, evidence timestamp, verifier, health-check results, and unresolved incident-response actions.

Do not suppress the finding until every controlled target and reinstall path has fixed-version evidence. Do not call the appliance uncompromised based only on a successful upgrade and ordinary health checks.

Rollback and stop conditions

Prefer forward recovery to another vendor-supported fixed release. If an operational regression requires restoring a prior artifact, the rollback may restore vulnerable firmware. Reapply the approved HTTP/HTTPS administrative- interface containment before returning that appliance to its former exposure, retain an incident and upgrade owner, and set a time-bounded path back to fixed firmware.

Stop and write TRIAGE.md when:

• product identity, live release/build, HA membership, or administrative- interface reachability cannot be proved;
• the repository does not own the appliance, image, deployment definition, or upgrade runbook needed for remediation;
• suspicious activity creates an evidence-preservation or incident-response decision;
• a vendor-supported target, model-specific upgrade path, required intermediate hop, compatibility, storage requirement, backup, HA sequence, maintenance window, or rollback cannot be validated;
• disabling HTTP/HTTPS administration would remove the only approved management path or requires authority not granted by the task;
• remediation requires a live upgrade, reboot, failover, interface change, credential rotation, or outage outside the authorized boundary; or
• meaningful verification would require a crafted request, active probing, sensitive-data access, or a destructive test.

TRIAGE.md must name CVE-2025-25257, the inspected files and evidence, redacted target and owner, observed and required release, HA state, management-interface reachability, temporary containment, compromise concern, authority or compatibility blocker, next responsible human, and safest next action.

The prompt

You are remediating CVE-2025-25257, a critical, known-exploited SQL-injection
vulnerability in the FortiWeb HTTP/HTTPS administrative GUI.

Return exactly one output:

- a reviewer-ready change set that updates every repository-controlled
  FortiWeb target to a vendor-supported fixed release and documents safe
  operator verification, containment, incident handling, and rollback; or
- `TRIAGE.md` when ownership, deployed state, evidence preservation, upgrade
  safety, live-device authority, or verification cannot be resolved here.

### Guardrails

- Scope only CVE-2025-25257 and directly related FortiWeb inventory, firmware
  targets, administrative-interface exposure, containment, upgrade artifacts,
  safe verification, and incident-response handoff.
- Do not connect to, scan, probe, or mutate a live FortiWeb appliance unless
  the task explicitly grants that exact authority.
- Do not generate, copy, or send a SQL-injection payload, crafted HTTP/HTTPS
  request, exploit path, callback, file, or proof-of-concept.
- Do not treat a desired-state pin or scanner string as deployed-version proof.
- Do not store credentials, serial numbers, certificates, license files, full
  configurations, support bundles, raw logs, topology, or customer data in Git.
- Do not reboot, fail over, upgrade, disable an interface, rotate credentials,
  or remove suspected artifacts automatically.
- Do not describe a fixed release as proof that prior compromise did not occur.

### Steps

1. Inventory repository-owned FortiWeb firmware/image targets, VM definitions,
   FortiWeb Manager jobs, HA/recovery definitions, runbooks, policy checks,
   generated artifacts, and vulnerability exceptions. Record files inspected.
2. Build a redacted target matrix with product/model, owner, environment,
   deployed version/build and evidence date, HA role, HTTP/HTTPS administrative
   state, effective reachability, desired fixed release, and repository control
   point. Use approved evidence; do not query a live device without authority.
3. Compare each target with the exact fixed thresholds:
   - 7.6.0-7.6.3 -> 7.6.4 or later
   - 7.4.0-7.4.7 -> 7.4.8 or later
   - 7.2.0-7.2.10 -> 7.2.11 or later
   - 7.0.0-7.0.10 -> 7.0.11 or later
   Fortinet lists 6.4 as not affected. Do not infer the status of another
   release or downgrade to 6.4.
4. Resolve the incident-response gate using only approved, already-available
   evidence. If suspicious activity exists, stop routine patch work, preserve
   evidence, and name the incident owner and Fortinet support handoff.
5. For repository-controlled targets without an incident stop, update all
   firmware/image references, jobs, policies, runbooks, generated artifacts,
   HA peers, and recovery definitions to a currently supported release at or
   above the applicable threshold.
6. If rollout cannot be immediate, document Fortinet's workaround to disable
   the HTTP/HTTPS administrative interface as a human-owned, time-bounded
   containment. Do not execute it or invent a CLI command.
7. Add or update static policy checks that fail when a controlled target, HA
   peer, generated artifact, or reinstall path remains below its threshold, or
   when an exception lacks owner, expiry, evidence, and fixed target.
8. Run only repository schema, formatting, rendering, and policy tests plus
   existing normal service health checks. Verification must never exercise the
   SQL-injection path.
9. Document operator-only actions: upgrade path/hops, backup, HA sequencing,
   maintenance impact, read-only `get system status` verification, normal
   health checks, temporary-containment removal, and rollback.

### Stop conditions

Stop with `TRIAGE.md` if ownership or live state is unknown; compromise is
possible; the fixed target or upgrade path is unvalidated; temporary
containment would remove safe management; a live change exceeds authority; or
verification would require exploit-like traffic, sensitive evidence, or a
destructive test.

The output must distinguish repository evidence, operator-supplied evidence,
and unverified live state. It must not claim a device was patched, protected,
or clean without authorized execution evidence.

Output contract

Return one of:

• A reviewer-ready PR/change request that inventories every controlled target, updates all firmware/image/job/policy references to an approved fixed release, covers HA and recovery artifacts, documents temporary containment, supplies safe tests, and records human-owned upgrade, verification, rollback, and incident-response actions.
• TRIAGE.md containing the bounded evidence, owner, observed and required release, HA state, administrative-interface reachability, containment, compromise concern, authority or compatibility blocker, and next action.

The output must state what was verified from repository artifacts, what came from an operator, and what remains unverified. It must not contain exploit material or claim that a live appliance is fixed or trustworthy without approved execution evidence.

Primary references

• Fortinet PSIRT advisory FG-IR-25-151
• Fortinet FortiWeb get system status CLI reference
• CISA Known Exploited Vulnerabilities catalog entry
• CISA KEV JSON feed
• CVE Program record for CVE-2025-25257
• NVD record for CVE-2025-25257

Related recipes

• CVE intelligence intake gate
• Vulnerable Dependency Remediation
• How to remediate vulnerabilities with AI agents