CISA KEV Adds SharePoint and MikroTik: A CTEM Response Playbook

TL;DR

On September 25, 2026, CISA added two vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog based on evidence of active exploitation: CVE-2026-65660, a code injection vulnerability in Microsoft SharePoint, and CVE-2026-67279, an improper enforcement of behavioral workflow vulnerability in MikroTik RouterOS. Both target systems that sit on the perimeter or directly behind it — a collaboration platform that holds your documents and a router OS that carries your traffic.

The interesting part isn't the CVE numbers. It's the guidance layered on top: under BOD 26-04, prioritization is explicitly risk-based — patch KEV-listed CVEs on publicly exposed assets that grant total control post-exploitation first, defer lower-risk work, and check whether you were compromised before the patch went on. That's an exposure-management problem, not a scanning problem. Trusteed CTEM is built for exactly that loop: discover, validate, prioritize, remediate, and prove it.

What is risk-based vulnerability management under KEV and BOD 26-04?

The KEV Catalog is CISA's authoritative list of CVEs with documented evidence of exploitation in the wild. Inclusion means someone has already weaponized it — you are no longer reasoning about theoretical risk.

BOD 26-04 is the binding operational directive that requires Federal Civilian Executive Branch agencies to prioritize security updates based on risk. In practice it sets a hierarchy: KEV-listed CVEs on publicly exposed assets that grant total control after exploitation get rapid remediation; lower-risk findings can be scheduled later. It also establishes expectations for checking whether threat actors compromised a system before remediation was applied. BOD 26-04 binds only FCEB agencies, but CISA encourages every organization to adopt the same risk-based model — and auditors, insurers, and enterprise customers have noticed.

Risk-based vulnerability management is the operational discipline that follows: ranking work by exploitability × exposure × business impact instead of by CVSS score or scanner severity label alone. A CVSS 9.8 on an internal-only dev box nobody can reach is not the same risk as a CVSS 8.1 on an internet-facing VPN concentrator with a public exploit. KEV is one input. EPSS probability, public proof-of-concept availability, asset criticality, data sensitivity, reachability, and compensating controls are the others.

Important caveat: KEV is a floor, not a ceiling. Plenty of exploited vulnerabilities never get listed. Treat catalog membership as a strong signal, not the only one.

Why it matters now

Two KEV additions in a single week is a reminder of how unhelpful severity-only queues have become.

SharePoint is a data gravity problem. It is where contracts, HR records, engineering documents, and internal wikis live. Code injection that runs in the SharePoint application pool doesn't just compromise a web app — it hands an attacker a trusted identity inside your network, object-level access to document libraries, and a plausible pivot toward Active Directory through service accounts and farm credentials.

MikroTik RouterOS is an edge persistence problem. RouterOS runs on routers, VPN endpoints, wireless controllers, and branch gateways — including in retail, hospitality, manufacturing, and managed service provider environments where it is cheap, capable, and extremely common. Edge compromise is quiet: the device was probably never in your vulnerability management scope, it may sit outside your EDR coverage, and it can manipulate, mirror, or redirect traffic without tripping endpoint alerts. RouterOS devices have repeatedly been mass-recruited into DDoS botnets and used as anonymization infrastructure.

BOD 26-04 shifts the question you must answer. Not "how many criticals do we have?" but "which of our publicly exposed assets grant total control if exploited, and can we prove we checked for compromise before patching?" That is a question about inventory fidelity, exposure context, and evidence — three things scanner-only programs struggle to produce.

How attacks / risks work

SharePoint code injection. Code injection flaws in SharePoint typically let an attacker get attacker-controlled code into a processing path where it executes under the identity of the SharePoint application pool — usually w3wp.exe. From there, the standard playbook is:

• Drop a web shell into a web-accessible directory to establish durable, patch-surviving access.
• Enumerate site collections and document libraries; exfiltrate anything with credentials, PII, or IP value.
• Harvest connection strings and service credentials from configuration.
• Move laterally toward SQL Server or Active Directory using SharePoint's own service accounts.

The detection difficulty is the point: SharePoint legitimately writes files, spawns processes, and makes outbound requests. Without baselining, web shell activity blends into normal application noise. And because web shells survive patching, remediation isn't finished when the update is applied — the directive's pre-patch compromise check exists precisely because of this.

MikroTik RouterOS behavioral workflow flaw. "Improper enforcement of behavioral workflow" describes a class of bug where the device fails to enforce the expected sequence or state of an operation, allowing a crafted request to push the system into a state it should have refused — an authentication transition, a configuration change, or a management action that should have required a prior step. On edge infrastructure the consequence is position, not just access: an attacker who controls the router can intercept or redirect traffic, tunnel inward, harvest credentials from management sessions, or conscript the device into a botnet.

The attacker lifecycle looks the same either way: mass-scan for the version and exposure signature, exploit opportunistically, establish persistence, then monetize — ransomware staging, data theft, or infrastructure rental. KEV publication tells you the exploitation step is already solved and circulating. Assume scanning against your external footprint began before you finished reading the advisory.

Detection and visibility

Good telemetry answers four questions: do we have it, is it reachable, is it exploitable here, and were we already hit?

• Asset and version inventory. A current list of SharePoint farms and RouterOS devices with versions, patch levels, and business owners. If your CMDB cannot tell you which RouterOS devices expose Winbox (8291) or the API (8728) to the internet, you don't have inventory — you have a guess.
• External reachability. Which of those assets actually answer from the public internet, on which ports, with which TLS and authentication posture. Reachability is what turns a vulnerability into a KEV-priority item under BOD 26-04's framing.
• Host-level artifacts. On SharePoint: w3wp.exe spawning cmd.exe, powershell.exe, or net.exe; newly created .aspx/.ashx files outside change windows; outbound connections to unfamiliar destinations.
• Edge-device integrity. RouterOS configuration drift: unexpected users, scheduled scripts, SNMP or wireless changes, new firewall rules, altered DNS settings, unexplained traffic patterns.
• Finding validation. A raw scanner hit means "a version matched a signature." A validated finding means "this asset is reachable, this condition is exploitable, and it matters to the business." Only the second belongs in an analyst queue.

Reduce risk / best practices

1. Reconcile inventory against both CVEs within 24 hours. You cannot prioritize what you cannot enumerate. Sweep for SharePoint instances and every RouterOS device by version fingerprint, not by hostname.
2. Determine true exposure before determining urgency. Internet-facing status, total control post-exploitation, and reachable management interfaces go to the front of the line.
3. Order the work by exploitability, not CVSS. KEV membership, EPSS probability, public exploit availability, and reachability belong in the same score. A severity column alone will misrank your backlog.
4. Patch as mitigation, not closure. Apply the fix, then treat the asset as potentially compromised until you have hunted for persistence — web shells in SharePoint, config drift and rogue accounts on RouterOS.
5. Shrink reachability while you patch. Put SharePoint behind an authenticated reverse proxy or WAF, restrict Winbox/API/SSH to a management jump host, and remove direct internet exposure from edge management planes.
6. Segment and least-privilege. Keep the SharePoint farm out of Tier 0, limit app pool and farm account rights, and keep router management traffic on an isolated VLAN.
7. Define KEV SLAs. Hours for internet-facing, total-control findings; days for everything else that is KEV-listed. Publish the SLA so the business understands the trade-off.
8. Make the loop continuous. Re-scan when things change — a new subdomain, a new cloud IP, a new service, a new certificate. Point-in-time assessments go stale the moment your infrastructure moves.
9. Keep evidence. Retain scan results, validation records, patch timestamps, and compromise-hunt findings. BOD 26-04-style expectations are becoming audit expectations everywhere.

How Trusteed CTEM helps

• Continuous attack surface and asset inventory. Trusteed CTEM discovers domains, IPs, services, and technologies across your external and internal footprint using passive and active discovery, then keeps scan plans running so KEV-day questions are answered from live data instead of last quarter's spreadsheet.
• CVE-enriched vulnerability findings. Scanner-driven detections are correlated with catalog CVE data and enriched with EPSS, KEV, and exploit references — so a new catalog addition maps to the assets it actually affects.
• A validation gate instead of a raw alert firehose. Trusteed validates exploitability and business context before a finding becomes an alarm, so SOC queues and dashboards reflect actionable should_alarm risk rather than every signature match.
• Depth where it counts. A dedicated API surface testing worker and deep DAST coverage for critical web applications extend exposure visibility beyond generic network and web checks.
• Compliance and reporting views. Framework-oriented reporting turns remediation work into evidence you can hand to auditors, customers, and insurers.
• Vulnerability intelligence. Trusteed tracks KEV and emergent-threat narratives in-product and on the public blog, so teams get context alongside the finding instead of a bare CVE ID.

Trusteed CTEM vs point tools

Capability	Typical point tool	Trusteed CTEM
Asset discovery	Scan targets you supply	Continuous discovery of domains, IPs, services, and technologies
Vulnerability detection	Template- or signature-based checks	Scanner-driven findings enriched with catalog CVE data
Prioritization	Severity score or CVSS	KEV, EPSS, and exploitability context applied to your assets
Validation	Every hit becomes an alert	Validation gate that separates actionable risk from raw signal
Application depth	Generic web checks	Dedicated API surface testing and deep DAST workers
Cadence	Point-in-time scans	Ongoing scan plans that re-evaluate on change
Reporting	Raw scan exports	Framework-oriented views and customer-ready reporting
SOC workflow	Findings land in a spreadsheet or ticket	Actionable queue at app.trusteed.io

Point tools aren't the problem — they're components. Nuclei, Trivy, and similar scanners are excellent at what they do: template checks, CI gates, container and dependency scanning. What they don't provide is the CTEM workflow around them: inventory, exposure context, validation, prioritization, and continuous re-evaluation. That's the gap a KEV week exposes.

FAQ

What exactly did CISA add to the KEV Catalog? Two entries with evidence of active exploitation: CVE-2026-65660, a Microsoft SharePoint code injection vulnerability, and CVE-2026-67279, an improper enforcement of behavioral workflow vulnerability in MikroTik RouterOS. Both were published as additions on September 25, 2026.

Does a KEV listing mean we must patch immediately? For FCEB agencies under BOD 26-04, yes — with priority given to publicly exposed assets that grant total control post-exploitation, and lower-risk items deferred. For everyone else, KEV is a strong, well-evidenced signal that the vulnerability is already being exploited. Treat it as a same-day triage item, not next quarter's backlog.

How is BOD 26-04 different from earlier vulnerability management directives? It explicitly frames remediation as risk-based rather than universal: prioritize high-risk KEV items on exposed, high-impact assets, defer lower-risk work, and establish expectations for checking whether attackers compromised systems before the patch was applied. That last requirement is the one most programs are least prepared for.

Is CTEM just a rebranded vulnerability scanner? No. A scanner is one input into CTEM. Continuous Threat Exposure Management adds persistent asset discovery, exposure context (is it reachable? does it grant total control?), validation that separates exploitable findings from version matches, prioritization against exploit intelligence, and continuous re-evaluation as your infrastructure changes. Scanners produce signals; CTEM produces decisions and evidence.

How do we check for pre-patch compromise? Baseline what normal looks like first. On SharePoint, hunt for unexpected .aspx/.ashx files, w3wp.exe child processes, and anomalous outbound connections. On RouterOS, compare the running configuration to a known-good baseline and look for new users, scripts, scheduled jobs, firewall rules, or DNS changes. If you have no baseline, capture one now — before the next KEV entry forces the question.

What if we can't patch right away? Reduce reachability before you reduce risk. Pull management interfaces off the internet, restrict them to a jump host, front SharePoint with an authenticated proxy or WAF, segment the affected systems, and monitor harder. Document the compensating controls — that's what an auditor or insurer will ask for.

Do these two CVEs affect everyone equally? No. Exposure is asset-specific: an organization with a single on-premises SharePoint farm behind a proxy has a very different risk profile than one with thirteen internet-facing farms, and a RouterOS-heavy branch or MSP environment carries more edge risk than a cloud-only shop. Prioritization only works when it is grounded in your actual footprint.

How often should exposure data be refreshed? Continuously, and always on change. New subdomains, cloud IPs, services, and certificates appear between quarterly scans, and each one can reintroduce a KEV-listed exposure you already believed you had closed.

Related resources

• Trusteed CTEM platform overview — how continuous threat exposure management fits your team's workflow.
• Trusteed vulnerability intelligence blog — KEV analysis and emergent threat narratives for practitioners.
• CISA Known Exploited Vulnerabilities Catalog — the authoritative source for the entries discussed here.
• CISA Binding Operational Directives — the directive text and the risk-based prioritization model behind it.
• NIST SP 800-40 Rev. 4: Enterprise Patch Management Planning — practical guidance on prioritizing and scheduling remediation.
• OWASP Vulnerability Management Guide — building a vulnerability program that survives contact with reality.
• Start a scan in the Trusteed app — inventory your external footprint and map KEV-listed CVEs to reachable assets.