DEV Community

StarkMan
StarkMan

Posted on

Four SQL injection bugs in the appliance that keeps your firewall logs

#security #vulnerabilitymanagement

Four SQL injection bugs in the appliance that keeps your firewall logs

Fortinet published advisories on 13 October 2026 covering SQL injection defects in FortiAnalyzer and FortiManager: CVE-2026-23705 (7.2), CVE-2026-23706 (6.5), CVE-2026-23707 (7.2) and CVE-2025-46773 (8.8). All four are classified CWE-89, and all four carry the same closing phrase in their published descriptions: a low-privileged user may be able to execute arbitrary commands through crafted requests.
The affected ranges cover branches from 7.2 through 7.6, with cloud variants named in the same bulletins.

Why SQL injection on a log manager is not a routine finding

An SQL injection in a web application exposes whatever the application's database user can read. In most products that is a bounded set of tables.
FortiAnalyzer is different in two ways that both matter. Its core function is storing and querying the logs of the estate it monitors, so the database holds the security record itself: traffic logs, event logs, and the analytics built from them. And the appliance's role in a Fortinet deployment is central: a firewall that cannot log is a firewall whose policy cannot be demonstrated.
The advisory phrase "execute arbitrary commands" is more expansive than data access. The published description does not detail the mechanism, and this analysis should not invent one. What the severity and the wording support is a defensive conclusion: a defect in the query layer of a log manager is a defect in the integrity of the record, which is the asset the appliance exists to protect.
On the management side, FortiManager holds the configuration of the firewalls it manages, including policy, objects and in some deployments credentials for device access. An injection there has a different blast radius with a similar shape.

The CWE-89 pattern in vendor appliances

Vendor appliances built around a web console accumulate query-construction code over years and across acquisitions. The 7.2 rating and the PR:H in the vector for CVE-2026-23705 and CVE-2026-23707 indicate that the attack requires privileges, which narrows who can reach the flaw but not what it grants.
The distinction worth carrying into a risk statement is between an authenticated admin and an authenticated operator. Many Fortinet deployments provision read-only or reporting accounts for compliance staff, helpdesk, and integration services. Those accounts hold the privilege level the advisories describe, and an integration account with a valid token is not an attacker who needed to break in.
CVE-2025-46773 carries the same description with a 2025 identifier and a 2026 publication date. That gap is a reminder that advisory dates are not disclosure dates, and patch status should be read from the product build rather than from a ticket that says "October updates applied".

The single-packet path that is easier to miss

CVE-2026-106173 is a separate Fortinet advisory published in the same window. It is rated 9.8 and describes a path traversal in FortiSIEM 7.5.0 that may allow an attacker to execute unauthorised code or commands through specially crafted packets.
The contrast with the SQL injection set is useful. The FortiSIEM issue is described at the packet level and does not require privileges. Where the log management appliance and the SIEM sit in the same network segment, the lower-privilege path is the one that determines the segment's risk.

Verification steps

Read the build number from each appliance and match it to the advisory's affected list. The 7.2 through 7.6 range is broad enough that an organisation's estate will contain a mix, and a per-device check is the only reliable method.
Inventory the accounts. The set of accounts that can authenticate to FortiAnalyzer and FortiManager, with their associated roles, is the population that can reach these defects on an unpatched build. Integration accounts with reporting roles are the ones most often forgotten.
Check the log path separately. Ingestion from the FortiGate fleet should be authenticated at the transport or by source address, and the check is whether the appliance would accept a log from an address it has never seen.
Confirm retention. An appliance whose analytic retention is shorter than the organisation's detection latency cannot answer the question an incident raises, and that gap is measurable without a CVE.

The monitoring question the appliance cannot answer

There is an uncomfortable recursion here. The appliance that records what happened to the estate is also software whose own activity should be recorded.
Fortinet's documentation describes administrative event logging to a remote syslog destination. Where that is not configured, the record of who changed a policy on FortiManager, or who ran a query against FortiAnalyzer's database, exists only in local storage that an attacker with command access could alter.
The comparison worth running: take a change made on FortiManager last month and try to attribute it to a person from a system the appliance does not control. Where that is impossible, the log path has a single point of failure that predates any of these CVEs.

References

Top comments (0)