Severity Daily

IT and AI security incidents, checked against the primary source

Tag: kev-due-2026-09-12

  • 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.

  • CISA put a 9.3 NetScaler authentication bypass on a three-day clock; Citrix offers no mitigation and the CVE record does not describe the flaw

    CISA put a 9.3 NetScaler authentication bypass on a three-day clock; Citrix offers no mitigation and the CVE record does not describe the flaw

    CISA added CVE-2026-19490 to the Known Exploited Vulnerabilities catalog on September 9, 2026 with a September 12 deadline; Citrix’s advisory, unchanged since August 19, says nothing about exploitation and lists its mitigations as “None.”

    What happened

    On September 9, 2026, CISA added CVE-2026-19490 to the KEV catalog under the name “Citrix NetScaler Authentication Bypass Using an Alternate Path or Channel Vulnerability.” The catalog entry sets dateAdded to 2026-09-09 and dueDate to 2026-09-12 — a three-day remediation window — and flags forensicTriage as Yes, which adds an obligation to check the asset for evidence of compromise rather than simply patch it. knownRansomwareCampaignUse is recorded as Unknown. The weakness is CWE-288.

    CISA’s own description of the flaw reads: “Citrix NetScaler ADC and NetScaler Gateway contain an authentication-bypass vulnerability involving an alternate path or channel. When the NetScaler appliance is configured as an AAA virtual server or as a Gateway (SSL VPN, ICA Proxy, CVPN, or RDP Proxy), an unauthenticated remote threat actor may be able to bypass authentication.”

    That sentence is the most detailed public description of what this vulnerability does, and it comes from the agency rather than from the vendor or the CVE record.

    Citrix published the underlying advisory, CTX696939, on August 19, 2026. It covers two flaws. CVE-2026-19489 is described in five words — “Memory overflow vulnerability leading to unpredictable behavior or Denial of Service” — and scored 8.8 on CVSS v4.0, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:L. CVE-2026-19490 is described in six — “Authentication bypass using an alternate path” — and scored 9.3, vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L. Under the heading for mitigations, the advisory says: “None.”

    The affected and fixed builds are specific. NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.32 are affected, fixed in 14.1-73.32 and later. The 13.1 train is affected before 13.1-63.21, fixed in 13.1-63.21 and later. NetScaler ADC FIPS is affected before 14.1-73.32 FIPS. NetScaler ADC FIPS and NDcPP on the 13.1 train are affected before 13.1-37.277, which is where that train’s fix lands — a lower build number than the mainline 13.1 fix, because the FIPS and NDcPP branches carry their own numbering.

    The advisory as published carries no statement about exploitation in the wild, and the copy retrieved for this story showed no revision note or last-updated date after August 19, 2026.

    Why it matters

    Start with the CVE record, because it is the artifact most organizations will actually consult, and it does not describe the vulnerability. The full text of the description on the NVD record for CVE-2026-19490 is: “Vulnerability in NetScaler ADC and NetScaler Gateway. This issue affects ADC: from 14.1 through 73.32 and from 13.1 through 63.21; Gateway: from 14.1 through 73.32 and from 13.1 through 63.21.”

    There is no verb describing an attack, no mention of authentication, no mention of AAA virtual servers or Gateway configurations. Someone triaging from that record alone learns only that a product is affected in some way. The one field that could have carried the meaning carries a version range instead, and the range itself is wrong in a way that matters operationally. “From 14.1 through 73.32” is not a coherent range — 14.1 is a train and 73.32 is a build within it — and read literally it says that build 14.1-73.32 is inside the affected set. Citrix says 14.1-73.32 is the fix. The same inversion applies to 13.1 and 63.21.

    That is not a pedantic complaint. Scanners and asset inventories consume these ranges. An operator who has already applied 14.1-73.32 and then checks the CVE record has a reasonable chance of concluding the appliance is still exposed, and an operator running an unpatched 13.1 build below 63.21 gets no clear signal of where to go. The vendor advisory is correct and unambiguous; the record built on top of it is neither. On this one, read Citrix.

    The scoring is similarly thin. The only CVSS entry on the record is a v4.0 vector supplied by the Citrix CNA, marked secondary, with no NIST primary score and no v3.1 vector at all. NVD lists the record as “Awaiting Analysis,” published August 19, 2026 and last modified September 1, 2026, and as of this writing it does not yet carry CISA’s cisaExploitAdd or cisaActionDue fields. Organizations whose vulnerability management still keys on CVSS v3.1 base scores will find nothing to key on here. This site has covered the v3.1-versus-v4.0 gap on other vendors’ records; the NetScaler case is a cleaner example than most, because there is no v3.1 score to disagree with.

    Then there is the three-week gap between disclosure and the KEV listing. Citrix shipped fixed builds on August 19 without describing what the bug does beyond six words and without any exploitation language. Three weeks later a US federal agency judged the flaw exploited and gave civilian agencies until Saturday to remediate it. Citrix has not, as of this writing, revised CTX696939 to say the same thing. Both statements can be true — CISA adds entries on evidence it does not always publish, and vendors update advisories on their own timelines — but the practical effect is that the only public authority calling this exploited is the government, and the vendor page a customer is most likely to open still reads like a routine August patch.

    NetScaler is also the wrong product to be vague about. An appliance configured as a Gateway or an AAA virtual server is, by definition, reachable from the internet and sitting in front of authentication for everything behind it. CISA’s description names four such configurations — SSL VPN, ICA Proxy, CVPN, and RDP Proxy — which is useful scoping that the vendor advisory does not provide. Appliances not in one of those roles are, on CISA’s wording, a different risk proposition from ones that are. That distinction only exists in the KEV entry.

    What to do

    Inventory NetScaler ADC and NetScaler Gateway builds and compare against the vendor list, not the CVE record: 14.1-73.32 and later, 13.1-63.21 and later, 14.1-73.32 FIPS and later, and 13.1-37.277 and later on the FIPS and NDcPP branch. Anything below those is unfixed. Because CTX696939 covers CVE-2026-19489 as well, the same upgrade closes the 8.8 memory overflow.

    Prioritize by role first. Any appliance configured as a Gateway — SSL VPN, ICA Proxy, CVPN, or RDP Proxy — or as an AAA virtual server is in the configuration CISA describes as exploitable, and should go first. There is no mitigation to fall back on: Citrix’s advisory says “None,” so the upgrade is the control. Restricting management-interface reachability is worth doing on general principles but does not address a flaw in the Gateway path itself.

    Federal civilian agencies have until Saturday, September 12, 2026, and because the entry carries the forensic-triage flag, patching alone does not discharge it. Everyone else running an internet-facing NetScaler in an affected build should assume the same urgency and check the appliance’s authentication logs for sessions that begin without a preceding authentication event, which is the shape an alternate-path bypass leaves behind.

    Sourcing note

    Checked: Citrix advisory CTX696939 at support.citrix.com for the CVE list, descriptions, CVSS v4.0 vectors, affected and fixed builds, and the mitigation statement; the NVD record for CVE-2026-19490 for description text, scoring, status, and dates; and CISA’s KEV catalog entry.

    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: CISA does not publish the evidence behind a KEV determination, and Citrix has not confirmed exploitation. The number of affected appliances is not public. The retrieved copy of CTX696939 showed no revision history, so it cannot be stated with certainty that the page has not been amended since August 19, 2026 — only that the version read for this story carried no exploitation language and no later date. NVD had not attached CISA’s KEV fields to CVE-2026-19490 at the time of writing.

  • Cisco confirmed exploitation of its 10.0 Firewall Management Center bypass on September 9; federal agencies have until September 12

    Cisco confirmed exploitation of its 10.0 Firewall Management Center bypass on September 9; federal agencies have until September 12

    CISA added CVE-2026-20079 to the Known Exploited Vulnerabilities catalog on September 9, 2026 with a three-day remediation deadline, the same day Cisco revised a six-month-old advisory to say attackers had been exploiting the flaw since August.

    What happened

    Cisco first published advisory cisco-sa-onprem-fmc-authbypass-5JPp45V2 on March 4, 2026. It describes an authentication bypass in the web interface of Cisco Secure Firewall Management Center. On September 9, 2026, Cisco issued version 2.5 of that advisory. The revision history records a single changed section, “Exploitation and Public Announcements,” and a one-line description of the change: “Updated to indicate that active exploitation has been observed.”

    The advisory now states: “In August 2026, the Cisco PSIRT became aware of active exploitation of this vulnerability. Cisco strongly recommends that customers upgrade to a fixed software release to remediate this vulnerability.”

    CISA added the CVE to the KEV catalog the same day. Catalog version 2026.09.09, released at 7:00 p.m. UTC on September 9, 2026, carries a dateAdded of 2026-09-09 and a dueDate of 2026-09-12 — three days. The entry’s forensicTriage field is set to Yes, which under BOD 26-04 obliges federal civilian agencies not only to remediate within the window but to carry out a forensic triage of the asset to assess whether it has been compromised. knownRansomwareCampaignUse is Unknown.

    Cisco scores the flaw 10.0 on CVSS v3.1, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, with a security impact rating of Critical. The weakness is CWE-288, authentication bypass using an alternate path or channel. Cisco attributes the flaw to an improper system process initialized at boot time, and says an unauthenticated, remote attacker can send crafted HTTP requests to “bypass authentication and execute script files on an affected device to obtain root access to the underlying operating system.”

    Affected releases are Cisco Secure Firewall Management Center Software 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0. Cisco says Security Cloud Control Firewall Management, the hosted equivalent, has already been patched on Cisco’s side. Remediation for on-premises deployments is a hot fix rather than a maintenance release, one per train: Cisco_Firepower_Mgmt_Center_Hotfix_GB-7.0.9.1-3.sh.REL.tar for 7.0, Cisco_Secure_FW_Mgmt_Center_Hotfix_HL-7.2.11.1-4.sh.REL.tar for 7.2, Cisco_Secure_FW_Mgmt_Center_Hotfix_HG-7.4.7.1-3.sh.REL.tar for 7.4, Cisco_Secure_FW_Mgmt_Center_Hotfix_CY-7.6.5.1-2.sh.REL.tar for 7.6, Cisco_Secure_FW_Mgmt_Center_Hotfix_AM-7.7.12.1-2.sh.REL.tar for 7.7, and Cisco_Secure_FW_Mgmt_Center_Hotfix_P-10.0.1.1-2.sh.REL.tar for 10.0. On workarounds the advisory is explicit: “There are no workarounds that address this vulnerability.”

    The revision history is worth reading in full. Version 1.0 was the initial public release on March 4. Version 2.0, on July 31, added Cisco Bug ID CSCwt95974, indicators of compromise, and the hot fixes. Versions 2.1 and 2.2 landed the same day, refining a code example and, in Cisco’s words, making it “clear to contact TAC if compromise is suspected.” Versions 2.3 and 2.4 followed on August 5, updating a CLI command and the customer-action text around the hot fixes. Then nothing until version 2.5 on September 9.

    In between, a working exploit went public. On August 20, 2026, a post to the Full Disclosure mailing list from an author using the name Banks Tools published an independently reproduced proof-of-concept against Secure Firewall Management Center 10.0.1-1, describing it as an authentication-bypass-to-root-RCE chain and shipping Python modules for fingerprinting, bypass validation, root verification, exploitation, and cleanup. The post says it reproduces an exploit that had already been documented elsewhere. NVD carries that mailing-list post as a reference on the CVE record.

    Why it matters

    The interval that matters here is not March to September. It is August to September 9. Cisco’s own sentence places its awareness of exploitation in August 2026 and its publication of that fact on September 9 — a gap of somewhere between nine and forty days, depending on where in August the PSIRT learned of it. The advisory does not narrow it, and a reader cannot narrow it either. What can be said is that for at least part of that window, defenders reading the most recent version of Cisco’s advisory would have seen a critical bug with hot fixes available and no indication that anyone was using it.

    That reading understates a signal Cisco had already sent. On July 31 — four months after initial disclosure, and before any statement about exploitation — Cisco added indicators of compromise to the advisory, then amended it twice more the same day to make sure customers knew to contact TAC if they suspected compromise. Vendors do not usually write compromise-detection guidance and a call-TAC instruction for a bug nobody is touching. The artifacts to hunt with were published on July 31; the reason to prioritize the hunt was published on September 9. An organization that patches by severity would have had the hot fix by early August. An organization that patches by observed exploitation would still be waiting on Tuesday.

    The asset is the second reason this one is worth moving on. Secure Firewall Management Center is not a firewall — it is the console that configures them, pushes policy to them, and holds the credentials and objects that describe an organization’s whole enforcement posture. Root on the manager is not equivalent to root on one appliance. It is administrative reach over every device the manager owns, plus whatever else the box can see from its position inside the management network. The S:C element of Cisco’s vector, scope changed, is doing real work in that 10.0 rather than inflating it.

    The score is Cisco’s own, and it is the only one on the record. NVD still lists CVE-2026-20079 as “Awaiting Analysis,” last modified August 26, 2026, with a single secondary CVSS entry sourced to [email protected] and no NIST primary score. As of this writing, NVD has also not attached CISA’s KEV fields to the record: there is no cisaExploitAdd and no cisaActionDue there. The deadline in this story is read from CISA’s own catalog data file, not from NVD, and the two will agree in a day or so.

    One pattern is visible in that catalog file and is worth stating plainly, because it is measurable rather than transcribed. BOD 26-04 defines four remediation bands — three days, 14 days, 60 days, and a deferral tier that waits for the next scheduled upgrade. Of the 86 catalog entries added since the directive took effect on June 10, 2026, 65 carry a three-day deadline and 21 carry 14 days. Not one has carried 60 days, and not one has been deferred. The short clock is not the exception under this directive; in practice it is the only other option besides two weeks. Which combination of internet exposure, KEV listing, exploit automation, and technical impact produces which band is a question this publication cannot answer from the primary source, because CISA publishes that mapping only as images in Appendix A and the public transcriptions of it disagree with one another. The counts above need no table.

    What to do

    Identify every on-premises Secure Firewall Management Center, including standalone virtual appliances and any instance parked in a management VLAN that nobody has looked at since it was built. Cisco lists 7.0, 7.2, 7.4, 7.6, 7.7, and 10.0 as affected. Apply the hot fix matching the train, by the file names above, from the Cisco Software Center. There is no configuration change that closes this, so do not spend time looking for one; restricting network reachability to the web interface reduces exposure but is not a fix and Cisco does not offer it as one.

    Federal civilian agencies have until Saturday, September 12, 2026. The forensicTriage flag means patching alone does not discharge the obligation — the asset also has to be triaged for evidence of compromise. Everyone else should treat the same date as a sensible target, and should run the triage regardless of sector: given a public proof-of-concept dated August 20 and vendor-confirmed exploitation beginning sometime in August, an unpatched manager exposed to the network has been reachable by a known-good exploit for weeks. Cisco’s advisory carries the indicators of compromise and the CLI command added in the July 31 and August 5 revisions; use that section, and contact Cisco TAC if the check comes back positive rather than reimaging over the evidence.

    Sourcing note

    Checked: Cisco’s advisory cisco-sa-onprem-fmc-authbypass-5JPp45V2 at sec.cloudapps.cisco.com, including its revision history, exploitation statement, hot fix list, and workaround statement; the NVD record for CVE-2026-20079; the Full Disclosure post of August 20, 2026 carried as a reference on that record; and CISA’s KEV catalog data.

    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. The band counts cited above were computed from that same file.

    Unresolved: Cisco does not say when in August its PSIRT learned of exploitation, how the exploitation was detected, how many customers are affected, or whether the activity is related to the August 20 public proof-of-concept. Cisco names no threat actor and this publication does not attribute the activity. NVD had not attached CISA’s KEV fields to CVE-2026-20079 at the time of writing and still shows the record as “Awaiting Analysis” with no NIST primary score; the 10.0 is Cisco’s own figure.