Severity Daily

IT and AI security incidents, checked against the primary source

Tag: CVE-2025-25249

  • In all nine of today’s stories the patch already existed — what arrived today was the record

    In all nine of today’s stories the patch already existed — what arrived today was the record

    Four vulnerabilities entered CISA’s Known Exploited Vulnerabilities catalog today, and three of them come due Saturday, September 12. The one to deal with first is Cisco’s. CVE-2026-20079 is a 10.0 authentication bypass in Secure Firewall Management Center, and Cisco revised a six-month-old advisory on the same day to say active exploitation has been observed. Advisory revision, exploitation confirmation, KEV listing, and a three-day federal clock all landed together, on the box that administers the firewalls.

    It is not the day’s biggest number. That belongs to Mathspace, which says 1,079,819 people were exposed after attackers reached its self-hosted Metabase. But that breach is over: the intrusion ran from August 10, the data left on August 27, the patch went on August 29, and individual notifications began September 6. There is nothing in it for a defender to do tonight. The Cisco deadline is in three days, and the appliance is reachable from the network.

    The thread today is not the KEV batch, and it is the more uncomfortable one. In all nine of today’s stories, a fix already existed before the thing that finally made anyone look. Open WebUI’s 0.11.1 shipped 15 days before the 16 CVEs it closes were published inside a single hour, and its release notes say plainly that some security fixes were being withheld. AWS’s 1.1.7 reached PyPI 76 days before the bulletin disclosing the 9.6 it fixes, and 71 days before a separate bulletin credited that same release with a 6.5. Tencent patched a wormable zero-click WeChat flaw on August 21, and it still has no CVE and no advisory. Metabase’s advisory was August 6. The F5 BIG-IP rootkit Sophos took apart runs on a flaw whose federal remediation deadline passed on March 30, 2026, and Shadowserver still counts 795 vulnerable hosts. The gap this publication keeps finding is not between the flaw and the fix. It is between the fix and the record that would tell an administrator the upgrade was worth taking a window for.

    After Cisco, the other two Saturday deadlines. The 9.3 NetScaler authentication bypass is harder to act on than to read about: the CVE record carries no description at all, only a mangled version range, and Citrix’s advisory, unchanged since August 19, lists its mitigations as “None.” The 2025 FortiOS heap overflow scores 9.8 in the record and 8.1 from Fortinet, and CISA names FortiSASE among the affected products while the record does not; FortiOS 6.4 has no fixed build in either source. The exploited Chrome V8 zero-day runs to September 23, which is time you will want, because Google rates it Medium and the release note CISA links to still says its security section is coming.

    The two evening records are patch-soon work behind all of that: the AWS Postgres MCP server, where AWS’s advisory and AWS’s own patch comment disagree about which mode was exposed, and Open WebUI, where the 8.1 OAuth bypass only bites SQLite deployments — which is the default one.

    What is still open. Fortinet’s own advisory could not be read at all from here, so its affected list, fixed builds, and any exploitation language are missing from our story rather than absent from the world. Citrix has said nothing about exploitation three weeks after publishing. Google’s release note has now been blank for two days on a flaw CISA lists as exploited. And the WeChat flaw, patched on August 21, remains invisible to every scanner in every fleet, because there is no identifier to scan for.

    Sourcing note: this recap introduces no facts beyond the nine stories it links, each of which carries its own sourcing note. The KEV dates above are carried from those pages, which verified them against CISA’s own cisagov/kev-data mirror on GitHub, since cisa.gov returns 403 to automated retrieval. A re-read of that mirror during this run returned an older catalog version and truncated content, and the NVD records for CVE-2026-20079 and CVE-2026-87491 do not yet carry cisaExploitAdd or cisaActionDue — NVD lags the catalog by hours.

  • CISA added a 2025 FortiOS heap overflow to KEV with a September 12 deadline, and named a product the CVE record does not list

    CISA added a 2025 FortiOS heap overflow to KEV with a September 12 deadline, and named a product the CVE record does not list

    CISA added CVE-2025-25249 to the Known Exploited Vulnerabilities catalog on September 9, 2026 with a September 12 deadline; the CVE record scores it 9.8, Fortinet scores it 8.1, and CISA names an affected product the record does not list.

    What happened

    On September 9, 2026, CISA added CVE-2025-25249 to the KEV catalog as “Fortinet Multiple Products Heap-based Buffer Overflow Vulnerability.” The entry sets dateAdded to 2026-09-09 and dueDate to 2026-09-12 — three days — and marks forensicTriage as Yes, adding an obligation to assess the asset for compromise rather than only remediate it. knownRansomwareCampaignUse is Unknown. The listed weaknesses are CWE-122 and CWE-787.

    CISA describes the flaw this way: “Fortinet FortiOS, FortiSwitchManager, and FortiSASE contain a heap-based buffer overflow vulnerability that allows an attacker to execute unauthorized code or commands via specially crafted packets.”

    The CVE itself is not new. It carries a 2025 identifier, and the vendor advisory it points to, FG-IR-25-084, is a 2025-series FortiGuard bulletin. NVD published the record on January 13, 2026 and last modified it on September 9, 2026, within the hour after the catalog entry appeared. The record’s status is “Modified.”

    The description on the record, supplied by Fortinet as the CNA, reads: “A heap-based buffer overflow vulnerability in Fortinet FortiOS 7.6.0 through 7.6.3, FortiOS 7.4.0 through 7.4.8, FortiOS 7.2.0 through 7.2.11, FortiOS 7.0.0 through 7.0.17, FortiOS 6.4 all versions, FortiSwitchManager 7.2.0 through 7.2.6, FortiSwitchManager 7.0.0 through 7.0.5 allows attacker to execute unauthorized code or commands via specially crafted packets.”

    Two products appear there. Three appear in CISA’s sentence. FortiSASE is named by the agency and appears nowhere in the CVE record — not in the description, and not in the configuration data that lists affected version ranges.

    The record also carries two conflicting scores. NIST’s primary entry is 9.8 critical, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Fortinet’s PSIRT secondary entry is 8.1 high, vector CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. Every metric is identical except one. NIST assesses attack complexity as low; Fortinet assesses it as high. That single letter is the whole 1.7-point gap.

    A third primary source describes the same flaw from downstream. Siemens ProductCERT advisory SSA-864900, covering the RUGGEDCOM APE1808 application hosting platform, lists CVE-2025-25249 among the Fortinet issues affecting the FortiGate NGFW software those devices host. Siemens’ advisory was published May 13, 2025 and last updated August 11, 2026. Its remediation instruction is to update FortiGate NGFW to V7.4.9 or later, or V7.6.6 or later, depending on the branch. For CVE-2025-25249 specifically, Siemens records a mitigation: “For each interface, remove ‘fabric’ access.”

    Why it matters

    The mitigation line from Siemens is the most operationally useful sentence available on this flaw right now, and it did not come from Fortinet. Removing fabric access per interface points at the Security Fabric management channel as the reachable surface, which is a far more actionable piece of scoping than “specially crafted packets.” It is worth being precise about what that means and does not mean: Siemens is describing a mitigation for its own hosted FortiGate software, and a mitigation named in an OEM advisory is not the same thing as a vendor-published workaround for every deployment. It is a strong hint about where to look, not an instruction from Fortinet.

    The reason that matters is that Fortinet’s own advisory could not be read for this story. FG-IR-25-084 at both fortiguard.fortinet.com and fortiguard.com returned a connection-verification interstitial to automated retrieval rather than the advisory text. So the authoritative statement of affected builds, fixed builds, workarounds, and any exploitation language exists, and this publication could not reach it. That is a sourcing limit, not a claim that the advisory is deficient.

    It does, however, leave the fixed versions less certain than they should be on a bug with a three-day federal clock. Reading the CVE record’s ranges, the implied fixes are FortiOS 7.6.4, 7.4.9, 7.2.12, and 7.0.18, and FortiSwitchManager 7.2.7 and 7.0.6. Siemens’ advisory instead requires 7.4.9 or later — which agrees — and 7.6.6 or later, which is two builds beyond where the CVE record’s 7.6 range stops. Siemens bundles many Fortinet CVEs into one advisory, so its floor may be set by a different issue in the same bundle rather than by this one. Both numbers are published; they do not reconcile from the sources available, and an operator should treat the higher one as the safer target rather than assume the lower one is sufficient.

    FortiOS 6.4 is a separate problem. The description says “6.4 all versions” and the configuration data caps the range at 6.4.16, with no fixed build above it in either place. On the sources readable here there is no upgrade path within 6.4 — the remedy is moving off the train, which is a project rather than a patch, and one that a Saturday deadline does not accommodate.

    The score disagreement deserves attention beyond record-keeping. Attack complexity in CVSS v3.1 is the metric that captures whether an attacker needs conditions outside their control — a race won, a value guessed, a specific configuration present. When the CNA that wrote the code says those conditions exist and the national database says they do not, the two are describing different attacks, or one of them is describing the wrong one. A vulnerability now confirmed as exploited is empirical evidence in that argument, and it does not obviously favor the vendor’s reading. Fortinet’s 8.1 is the figure a customer sees on the vendor’s own materials; 9.8 is the figure most feeds inherit from NVD. Neither has been revised in light of the KEV listing.

    Finally, FortiSASE. It is a cloud-delivered service, which means a customer cannot patch it and cannot verify from outside whether the version they are reaching is fixed. CISA names it as affected. The CVE record does not. Under BOD 26-04, agencies are directed to follow the applicable guidance for cloud services or discontinue use where mitigations are unavailable — but which of those applies to FortiSASE depends on a question neither source answers, which is whether FortiSASE is affected at all. That gap is not academic for anyone who has routed their remote access through it.

    What to do

    Inventory FortiOS and FortiSwitchManager builds against the ranges on the record: FortiOS 6.4.0 through 6.4.16, 7.0.0 through 7.0.17, 7.2.0 through 7.2.11, 7.4.0 through 7.4.8, and 7.6.0 through 7.6.3; FortiSwitchManager 7.0.0 through 7.0.5 and 7.2.0 through 7.2.6. Treat FG-IR-25-084 as the authority on fixed builds and read it directly in a browser; where a 7.6 device is concerned, Siemens’ 7.6.6 floor is the more conservative target until Fortinet’s own list is confirmed.

    Where an immediate upgrade is not possible, review Security Fabric exposure interface by interface, following the shape of the Siemens mitigation, and confirm against Fortinet’s advisory before relying on it. Devices running 6.4 should be treated as unremediable in place.

    Federal civilian agencies have until Saturday, September 12, 2026, and the forensic-triage flag means the asset must also be assessed for compromise. For everyone else, a heap overflow reachable over the network on a perimeter device, now formally listed as exploited, is worth pulling forward past whatever else is queued. Organizations using FortiSASE should ask Fortinet directly whether the service is affected and what was done about it, since the public record does not say.

    Sourcing note

    Checked: the NVD record for CVE-2025-25249 for description text, both CVSS entries and their sources, weaknesses, configuration ranges, status, and dates; Siemens ProductCERT advisory SSA-864900 for the downstream product scope, remediation floors, and mitigation text; and CISA’s KEV catalog entry.

    Could not reach: Fortinet’s own advisory FG-IR-25-084. Requests to fortiguard.fortinet.com and fortiguard.com returned a connection-verification screen rather than advisory content, so Fortinet’s published affected list, fixed builds, workarounds, and any exploitation statement are not represented here except as they appear in the CVE record Fortinet supplied as CNA.

    cisa.gov returns 403 to automated fetching, so the KEV entry was read from cisagov/kev-data on GitHub, which CISA maintains as a mirror of the cisa.gov/kev data files. The file used is catalog version 2026.09.09, dateReleased 2026-09-09T19:00:50.2591Z.

    Unresolved: whether FortiSASE is affected, and if so in what form. Why NIST and Fortinet disagree on attack complexity, and whether either will revise. The correct fixed build on the 7.6 branch, where the CVE record and Siemens do not agree. Whether any fix exists for FortiOS 6.4. CISA does not publish the evidence behind a KEV determination, and no attribution is offered or implied here. A third-party analysis of an implant associated with this CVE is referenced on the NVD record; it was not used as a source for this story.