Two databases score the same flaw 7.4 and 9.8. Your patch queue is sorted wrong.

On September 9, 2026, CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog. Three of them were edge kit:

• CVE-2026-20079 — a Cisco Secure Firewall Management Center authentication bypass.
• CVE-2026-19490 — a Citrix NetScaler ADC and Gateway authentication bypass.
• CVE-2025-25249 — a Fortinet heap-based buffer overflow.

Federal civilian agencies had until September 12 on all three.

Now try to sort that list the way most patch queues are sorted: highest severity first, work down. Start with the Fortinet one.

Fortinet's own advisory, FG-IR-25-084, calls it high severity and scores it 7.4. NVD scores the same bug 9.8 — critical.

Same CVE. Two authoritative records. A gap of more than two points that crosses a severity boundary, so the two sources don't just disagree on magnitude, they disagree on which bucket it belongs in. Depending on which database your tooling ingests, that flaw is either near the top of your queue or somewhere in the middle of it.

And it's the one with the campaign behind it

SOCRadar reported an attack chain against that Fortinet flaw delivering a Node.js remote-access trojan it named PivotC2: "The threat actors targeted more than 30,000 IP addresses, leading to the exploitation and infection of 178 devices with PivotC2." Attacks mainly hit US entities, with at least two resulting in data exfiltration, and the earliest evidence of exploitation dating to July 2026.

Read that as vendor research, because it is. But the shape isn't in dispute, and the shape is what matters: a flaw whose own vendor rates it "high" — not critical — on kit whose entire job is to sit at the edge and answer strangers, worked at scale for roughly two months before it reached the catalog.

The Cisco flaw isn't a paper tiger either. Cisco updated its own advisory for CVE-2026-20079 to note it became aware of active exploitation in August 2026 — not that exploitation began then — and Cisco Talos published three distinct clusters of post-compromise activity on Firewall Management Center instances, deploying web shells and malware.

So you have two real problems and a ranking input that two authorities can't agree on. Which raises the question nobody in the private sector seems to have noticed was already answered.

CISA re-sorted federal patching in June

Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued June 10, 2026. It supersedes and revokes both BOD 19-02 (internet-accessible systems, 2019) and BOD 22-01 (the one that created the KEV catalog in 2021), and it sets remediation urgency from four variables:

1. Asset Exposure — is the vulnerable asset publicly exposed?
2. KEV Status — is the CVE on CISA's Known Exploited Vulnerabilities catalog?
3. Exploit Automation — can an adversary automate all the steps necessary to exploit it?
4. Technical Impact — does exploitation yield partial or total control of the asset?

CVSS severity is not one of the four. It appears in the directive only by analogy — the text notes that technical impact is "similar to" the CVSS base score's concept of severity — and then the directive goes on to use its own four-variable model instead.

The honest bit, before you take this anywhere

A Binding Operational Directive is compulsory only for the Federal Civilian Executive Branch agencies it names. It does not bind your company, your MSP, or your clients. Not even a little.

CISA's own wording for the rest of us is the softer verb, and it is worth quoting rather than paraphrasing: it "encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities."

That distinction gets flattened constantly, usually by someone with something to sell — a federal requirement gets restated as an industry obligation, and suddenly there's a due date nobody actually set. So: nobody is making you do this.

One more caveat while we're being precise. The directive's actual day-count table — Table 1, Remediation Timelines — is published on CISA's page as an image rather than as text, so no number from it appears in this article. Everything below is structure, not schedule.

Which is fine, because the structure is the part worth stealing.

Steal this definition first

"Publicly exposed: Any agency-owned or agency-managed IT resource accessible to unauthenticated or untrusted entities via public networks, such as the internet, regardless of its physical or logical location."

The last clause is the whole gift. Regardless of its physical or logical location.

That clause ends an argument every IT team has had. "Well, technically it's behind the firewall." "Technically that's on the management VLAN." Reachable by an unauthenticated stranger over a public network, full stop — where the box sits and what the diagram says are not the test.

You don't have one list. You have four.

Here's the problem with ranking by exposure: you can't rank what you've never enumerated, and almost nobody has actually written this list down. What they have instead is four partial lists, held by different people, that disagree with each other.

Route 1 — inbound from the edge. Firewall NAT and port-forward rules, load-balancer listeners, published services. Good at finding anything deliberately opened, including the rule from 2019 that nobody in the room will admit to. Misses anything cloud-hosted that never traverses your firewall.

Route 2 — outward from DNS. Your authoritative zone files and registrar account, every domain you own, including the ones you only redirect. Finds forgotten hostnames, staging subdomains, and records still pointing at IPs you released. Misses anything published on a bare IP with no DNS name.

Route 3 — cloud and tenant surface. Public IPs, public buckets, API gateways, public endpoints on managed databases, per cloud account. Finds exposure created by a deployment rather than a firewall change — which is precisely why the firewall team doesn't know about it.

Route 4 — vendor and portal surface. Every admin console you sign into over the internet: RMM, EDR, backup, email security, identity, payroll, ticketing. This is exposure you don't host, can't patch, and frequently can't even get logs for.

Run all four. The overlap is comforting. The non-overlap is the finding.

Route 4 is the one that changed this week

On September 8, CISA added CVE-2026-86218 in N-able N-central to the KEV catalog — in CISA's own words, a static code injection vulnerability "that could allow for pre-authentication remote code execution" — with a federal due date of September 11. Note what is not in that sentence: a CVSS number. CISA publishes none for it, N-able's own advisory rates it 10.0, and NVD rates the same CVE 9.8 — the identical problem this article opened with, on a different bug. N-able patched it in N-central 2026.3 Hotfix 4, released September 5, and told customers in an urgent notice that it "has been observed being exploited in the wild" — while its public release notes said there were no confirmations of exploitation in production environments. Both halves are the vendor's; read both.

Two things about that are worth more than the patch note.

Huntress said it opened an investigation following the compromise of a customer's fully patched N-central production environment on September 4, and stated plainly that it could not definitively confirm which specific exploit the threat actor used — in part because of limited historical logging available directly on the appliance.

Sit with that clause for a second. The appliance that manages an entire estate is the one that kept the least evidence about itself.

watchTowr, which reproduced the flaw, made the structural point: N-central is widely used by MSPs, MSSPs and large IT organizations to manage entire customer and corporate environments — so compromising it reaches every connected system downstream.

So there are two questions here, one for each side of a managed-services relationship. If you run a management platform: is that console reachable from the open internet, and does it appear anywhere as an internet-facing asset? If you buy from someone who does: which management platforms reach your estate, are they internet-facing, and when were they last patched? Ask in writing. Keep the answer with a date on it.

Then tag every row — four fields, plus one

BOD 26-04 tells agencies to continuously identify and tag every agency-owned asset reachable from outside the network on a routable IP address, and specifies the tags:

• Organization / sub-organization
• Environment — prod or dev
• Exposure — public or internal
• Asset type — server, application, or network device

Four fields, designed to work across an entire federal enterprise, published for free. Each earns its place:

Organization decides who gets the phone call — for an MSP, the client; internally, the business unit with an opinion about the maintenance window.

Environment matters because dev and staging get exposed for convenience and then never de-exposed, and they're the boxes carrying the fullest copy of production data behind the weakest credentials.

Exposure is what the entire ranking hangs off — and you confirm it from off your network, not from the config page.

Asset type decides whether the fix is a package update or a firmware window with a change board attached. Firmware is nobody's default job, which is exactly why it slips.

Then add a fifth field of your own: the named human. Not a team, not a mailbox, not someone who left. In advisory AA26-237A — CISA's write-up of two authorised red team assessments — a true alert on genuine red team activity was closed as a false positive because defenders could not establish who owned the system it came from. CISA attributes that outcome to missing procedures and limited analyst authority as well as to the unknown owner, which is the honest version: an asset with no owner is one input to an alert that doesn't survive triage, not the whole story.

The cross-check takes twenty minutes

Open the KEV catalog. It's free, public, machine-readable, and requires no account.

Search it by vendor and product name — the firewall, the VPN appliance, the router, the RMM, the file-transfer box, the mail gateway. Product first, version second. For each hit, record the version you're actually running, read off the host, not off the management dashboard. Dashboards report what they were last told; appliances get rebooted, restored, and half-upgraded. That's a two-minute difference in effort and the entire difference between a record and a guess.

Then rank by the directive's logic: publicly exposed and on KEV and automatable and total control goes to the front, regardless of how its CVSS number compares to something internal.

Where no patch exists yet, write down the mitigation — restrict the source addresses, take the interface off the internet, disable the feature. "Waiting on the vendor" is a status, not a control.

And for anything that was both exposed and on KEV before you patched it, note whether you reviewed the box for signs it had already been used, with the date you looked. Patching closes a door; it doesn't tell you who came through it.

The step that makes it a control

BOD 26-04 doesn't ask agencies to build this list once. It asks them to keep swearing to it: update or attest publicly exposed IP addresses and owned domain names once per quarter, including a list of every asset added and removed since the previous quarter.

That last clause is the clever part, and it's the one most people would skip if they were designing this themselves. A list you rewrite every quarter tells you nothing. A list plus a delta tells you how fast your own attack surface is growing and who is growing it — because attack surface expands by deployment, not by decision. Nobody holds a meeting to approve new exposure. It just appears.

The artifact is the point

The rule carries over from every review in this series: every claim gets a number and a date.

"Our perimeter is locked down" is a mood. Something shaped like "41 externally reachable assets confirmed Sep 17 from off-network; 6 on KEV, 5 patched, 1 mitigated by source restriction; 3 dangling DNS records removed; 2 vendor consoles still unanswered; next attestation Dec 17" is an artifact. It's also the shape of answer that cyber-insurance applications and client security questionnaires keep asking for.

And the re-ordering itself is free. It's a change of sort order, not a change of budget — which makes it the cheapest thing on any security roadmap this quarter.

Severity is a number two authoritative records can disagree about by 2.4 points. Exposure is a fact about your network, and exploitation is a fact about the world. Sort by the facts.

The worksheets are free. The Exposed Edge Kit (Gatorbyte #013) is a self-contained offline app — the four discovery routes, the four-field tag with the named-owner column, the KEV cross-check by product, an exposure register, the four exposed things nobody counts, and a quarterly attestation sheet that records additions and removals — plus CSV and Excel export of every worksheet. No account required — thesecuritygator.gumroad.com/l/gb013-exposed-edge-kit

This is a review format and a practical starting point to adapt for your organization. It supports asset-inventory and vulnerability-management documentation and audit-preparation workflows; it is not legal, compliance, or audit advice, and not a substitute for managed security, penetration testing, or incident-response services. CISA Binding Operational Directives are compulsory only for the federal agencies they name — nothing here creates an obligation on a private organization.

Sources: CISA BOD 26-04 — "Prioritizing Security Updates Based on Risk" · CISA KEV catalog · KEV additions, Sep 8 · KEV additions, Sep 9 · KEV additions, Sep 10 · Fortinet PSIRT FG-IR-25-084 · SecurityWeek on the PivotC2 campaign (SOCRadar figures, Sep 10)

A note on the two scores, because it is the article's whole premise: CISA's KEV alert pages publish no CVSS figures at all. The 7.4 is Fortinet's own, as reported by SecurityWeek from advisory FG-IR-25-084; the 9.8 is NVD's. Some trade coverage of the same flaw has reported 7.3. That spread is the point, not a footnote.