COMMENTARY: CISA’s warning last week that attackers are actively exploiting
three Microsoft SharePoint Server vulnerabilities shows how far the threat landscape has moved beyond traditional patching timelines. The window between disclosure and exploitation has shrunk faster than many organizations can test, approve, and deploy updates.
The flaws —
CVE-2026-32201,
CVE-2026-45659, and
CVE-2026-56164 — can let attackers bypass authentication, execute code, steal IIS machine keys, establish persistence, and deploy malware. For the newest flaw, federal agencies were given only until July 17 to secure affected systems or discontinue them. A three-day deadline puts teams directly into incident-response mode.
[
SC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Read more Perspectives here.]
With some vulnerabilities now exploited within hours of disclosure, the question of how teams move beyond traditional 15- or 30-day patch schedules deserves a reframe. It’s almost never that a patch does not exist: the bottleneck is more organizational friction. Security teams cannot out-patch a threat actor who weaponizes a CVE in six hours. However, defenders can out-detect them, buying organizations coverage during the window where patching cannot..
Move beyond the patch race
Patching remains essential, especially for internet-facing systems. But no schedule guarantees an organization will deploy every update before working exploit code appears. Declaring every critical vulnerability an emergency only creates a backlog where everything is urgent and nothing truly gets prioritized.
Here’s what works in the defender’s favor: post-exploitation behavior is remarkably stable even when it’s a brand new CVE. A fresh zero-day still ends with familiar behavior — a reverse shell redirecting input and output to a remote socket, a webshell dropped into a web root, or a service daemon spawning interpreters it should never spawn. The exploit changes constantly. The follow-on tradecraft rarely does.
That’s why detection engineering buys teams time that patching schedules cannot. A defender may not have a rule for a new CVE on the morning it’s disclosed, but can already monitor for unusual activity, suspicious file creation, abnormal outbound connections, and persistence that does not belong on the server.
Endpoint visibility cannot stand alone either. EDR-killer and bring-your-own-vulnerable-driver tooling are common enough that mature enterprises should expect determined attackers to try and blind the sensor. When that happens, proxy logs, DNS rarity analytics, network telemetry, and authentication anomalies become the surviving witnesses.
In the SharePoint case, patching alone may not address access that an attacker has already established. Teams also need to determine whether a compromise occurred and fully remove the attacker from the environment.
For smaller teams, understanding every user and internal system can get overwhelming. Here’s where deception shines. Canary documents, tempting network shares, fake databases, domain admins with zero allowed logon hours, and SPNs that teams can Kerberoast but have access to nothing all make useful tripwires. And if the deception profile gets ambitious, set up a port-spoofing web server running Cowrie. That will drive an adversary insane.
Give AI the context scanners lack
Teams need to have the information early enough to act. Automated workflows built with tools such as
n8n or Claude Cowork can use AI agents, threat intelligence platform data, vendor advisories, public research, and social-media monitoring to spot early signs that something significant has developed.
The workflow can search, consolidate, and produce a prioritized report before full-fledged exploit code runs wild. AI really changes the game by shifting vulnerability prioritization from generic scoring to contextual risk.
A CVSS number tells a team almost nothing about its own environment. An AI agent can join asset inventory, exposure data, business criticality, CISA KEV, EPSS scores, and active exploitation intelligence to answer the question that actually matters:
Which of these 400 critical vulnerabilities is internet-facing, unpatched, and being exploited by a group that targets our sector this week? That’s the difference between a scanner report and a decision. The data needed to make that decision already exists.
Crowdsource the first few hours
No single team can investigate every disclosure, reverse-engineer every exploit, build detection logic, and publish guidance before attackers start scanning.
Our research team shares techniques, workarounds, and detections through Securonix Connect. Black Hills Information Security does the same through Antisyphon Training, Red Siege through Wednesday Offensive, and Detections.ai through its detection platform. John Hammond, Chuck Keith, and others also share practical knowledge through YouTube and their training platforms.
When one team publishes exploitation details and detection logic on day zero, everyone consuming that work can gain coverage before the patch window opens. Shared detections effectively crowdsource a period that no individual team can cover alone. It’s not a problem we solve by throwing more dollars and another product at it. It’s a skill issue and a bottleneck issue.
Treat AI output as evidence, not authority
AI can accelerate vulnerability and patch management, but the company will still hold the security team responsible if a bad patch brings down a revenue-generating system. It can surface dependencies, summarize compatibility concerns, and warn that a patch may affect production. It cannot remove the need for testing.
Hallucination presents itself as a particular risk during triage. An agent that confidently misidentifies an affected version or incorrectly summarizes a CVE’s prerequisites can send responders to the wrong system during a crisis. Teams need to verify material conclusions against primary sources, especially the vendor advisory, rather than being accepted because the report looks polished.
Data exposure matters just as much. Asset inventories, network diagrams, and vulnerability scans form a concentrated intelligence package about an organization’s weakest points. Teams need to know where that data goes, how it gets retained, and who can access it.
With a robust set of AI skills, workflows, and human approval gates, teams can automate much of their vulnerability remediation. I have seen teams build what amounts to an AI operating system for an analyst’s daily work, breaking a large remediation effort into smaller tasks and giving the analyst a structured set of actions to review.
Emergency change paperwork represents a big opportunity. It’s not usually a detection or patch availability bottleneck. It’s organizational friction. Someone still has to draft the ECAB form, document the risk, prepare the rollback plan, identify dependencies, and route the change to the right approvers. AI handles that kind of toil really well.
Still, teams need to get the change advisory board comfortable with an agent participating in a workflow that can touch production. It’s the same reason SOAR platforms make people nervous: it’s one thing to trust automated analysis; it’s another for people to trust automated changes.
Let the agent gather evidence, draft the change request, and recommend the next step. Keep testing, approval, and production authority with the people accountable for the outcome. Human approval should remain built into the design from the start.
The SharePoint warning does not mean patching has stopped working. It means patching cannot carry the entire defense by itself. Attackers may get the first six hours, but defenders have to make sure those six hours are not quiet.
Aaron Beardslee, manager of threat research, SecuronixSC Media Perspectives columns are written by a trusted community of SC Media cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.
