The gap between disclosure and exploitation has closed faster than the gap between disclosure and patching. This issue is about what that does to a defense strategy built on "we'll patch it in the next window," and what proving otherwise actually requires.
Seven internet-facing enterprise platforms were exploited in a single window this summer: Cisco Catalyst SD-WAN Manager and Unified CM, Splunk Enterprise, Microsoft SharePoint, Oracle PeopleSoft and E-Business Suite Payments, and Ubiquiti UniFi OS. Two of the seven fell entirely outside the timing assumption most patch programs run on. Cisco SD-WAN was exploited as a zero-day roughly two months before the vulnerability was ever disclosed, while Oracle E-Business Suite Payments was exploited about six weeks after its patch had already shipped. The other five were compromised inside the normal window, but by attackers who moved fast enough that the window barely mattered.
The shared mechanism across all seven is unremarkable on its own: unauthenticated or default-credential access to a public-facing system (T1190), followed by execution, privilege escalation, and, in the more capable intrusions, deliberate anti-forensic cleanup. What is not unremarkable is what this reveals about patch cadence as a control. A defined SLA answers whether a fix was applied. It does not answer whether an organization knew the instance was exposed, whether an exploitation attempt in the interim would have been detected, or whether the exploited path is verifiably closed after the patch lands.
This issue maps all seven incidents, the ATT&CK techniques they share, and the three verification steps (continuous exposure discovery, interim detection, and post-patch re-verification) that turn "we patched it" into a defensible answer.
Two dates, one lesson.
Cisco Catalyst SD-WAN Manager was exploited as a zero-day as early as March 2026: threat researchers place the activity roughly two months before the vulnerability was publicly disclosed in early June and tracked as CVE-2026-20245. Attackers were operating inside edge management infrastructure before the industry knew the flaw existed.
Oracle E-Business Suite Payments was exploited in the wild about six weeks after its patch shipped, under CVE-2026-46817. A fix existed. Organizations had it available. Attackers exploited it anyway, in production, against teams who had every reason to believe they were covered.
One flaw was weaponized before there was anything to patch. The other was weaponized long after there was. Between those two points sits the assumption most security programs still run on: that a patch, applied on a reasonable cadence, is the control that closes the exposure. This past window said otherwise across seven different internet-facing enterprise platforms at once.
Cisco Catalyst SD-WAN Manager (CVE-2026-20245). Threat researchers reconstructed the intrusion end to end. The actor reached a service provider's SD-WAN fabric through unauthorized peering connections, then used SSH against default accounts on the management plane. From that foothold they uploaded a malicious CSV file crafted to exploit the flaw, escalating from administrative access to full root on the SD-WAN Manager. What happened next is the tell: the actor restored the original configurations, deleted the files they had introduced, and ran validation scripts to confirm their own cleanup held. This is the seventh Cisco SD-WAN vulnerability exploited in 2026. For these actors, edge management infrastructure is not a footnote to the attack surface. It is the objective, because it sits in the monitoring blind spot where endpoint agents do not run.
Cisco Unified CM (CVE-2026-20230). An unauthenticated server-side request forgery flaw in the WebDialer component. When WebDialer is enabled, an attacker can trigger the SSRF without credentials. Observed activity showed automated sweeps over Tor abusing the chain to stand up a rogue Apache Axis service, write a first-stage payload, and mass-deploy webshells for remote code execution, with a documented path toward root on the underlying server. CISA ordered immediate remediation and added it to the Known Exploited Vulnerabilities catalog on a compressed timeline.
Splunk Enterprise (CVE-2026-20253). An unauthenticated path through Splunk Web reaches PostgreSQL sidecar recovery endpoints, letting an attacker create or overwrite files and ultimately execute code without valid credentials. The detail that matters most: reporting notes the flaw can enable log tampering and alert suppression. This is the monitoring system itself, the platform a SOC relies on to see everything else, turned into both an entry point and a blindfold. An attacker who reaches this position can degrade the very telemetry a defender would use to catch the rest of this list.
Microsoft SharePoint (CVE-2026-45659). Deserialization of untrusted data leading to remote code execution on a platform that sits at the center of enterprise collaboration and identity. CISA confirmed active exploitation and added it to KEV shortly after the patch. SharePoint's blast radius is wide because it is rarely just a document store. It is wired into authentication, workflows, and internal data.
Oracle PeopleSoft (CVE-2026-35273). An unauthenticated deserialization flaw reached through the /PSEMHUB/hub endpoint. Reporting ties a broader campaign, linked to the ShinyHunters cluster, to roughly 100 targeted organizations. Confirmed impact includes exposure of Nissan employee data, and the knock-on effects were severe enough that some ratings agencies temporarily suspended data feeds tied to affected workflows, a reminder that an HR platform breach does not stay inside HR.
Oracle E-Business Suite Payments (CVE-2026-46817). In-the-wild exploitation began about six weeks after the patch shipped: unauthenticated takeover paths against the Payments module of a core financial system. The exposure was not a missing fix. It was the interval between "patch released" and "patch applied, verified, and monitored," an interval most programs cannot measure precisely.
Ubiquiti UniFi OS. Added to KEV after multiple flaws that can be chained without authentication into remote compromise of the management plane, the same pattern as the rest of the list, on network infrastructure that rarely carries an EDR agent.
Many readers will file each of these under its own headline: track the CVE, apply the fix, close the ticket, move on.
The pattern underneath is more uncomfortable. Every one of these was an internet-facing or perimeter-adjacent enterprise system: SD-WAN managers, VoIP call managers, collaboration servers, HR and payments platforms, network management planes. And in this window, the timing assumption failed at both ends. Cisco SD-WAN was exploited two months before disclosure. Oracle EBS was exploited six weeks after the fix. Splunk, the tool a defender would use to catch the others, was itself a target.
A patch cadence protects you only inside a specific assumption: that exploitation follows disclosure, and follows it slowly enough that a maintenance window closes the gap first. That assumption is now the exception, not the rule. When exploitation precedes disclosure, there is no patch to apply. When exploitation trails the patch by weeks, the fix was available and the exposure was still open, because "patch available" and "patch applied, verified, and detecting attempts on the unpatched interim" are not the same state, and many programs cannot tell, on any given day, which state they are actually in.
Strip away the product names and the shared shape is plain. These are not exotic exploit chains. They are exposed systems, known-or-soon-to-be-known flaws, and time.
Initial access is T1190 - Exploit Public-Facing Application in every case: an unauthenticated request or a default credential reaching a service exposed to the network. The Cisco SD-WAN intrusion layered T1078.001 - Valid Accounts: Default Accounts on top, using SSH to default management-plane accounts before the CSV upload. The Unified CM and Splunk cases are SSRF-and-deserialization variants of the same public-facing-application problem: the attacker never needed to authenticate.
Execution and escalation follow immediately. The SD-WAN CSV upload achieved arbitrary command execution (T1059 - Command and Scripting Interpreter) and escalated to root (T1068 - Exploitation for Privilege Escalation). Unified CM's SSRF chain wrote a first-stage payload and stood up a rogue Apache Axis service to reach RCE.
Persistence most visibly took the form of webshells in the Unified CM campaign (T1505.003 - Server Software Component: Web Shell), a durable foothold on the underlying server that survives a session and provides a command channel over ordinary web protocols (T1071.001 - Application Layer Protocol: Web Protocols).
Defense evasion is where the SD-WAN actor showed real tradecraft: restoring configurations and deleting introduced files (T1070 - Indicator Removal, T1070.004 - File Deletion) to erase the trail, then validating the cleanup. The Splunk path aims at the same goal from the other direction: enabling indicator removal and alert suppression at the telemetry source itself.
None of this requires the defender to face a novel technique to be in danger. It requires an exposed instance the defender may not have in inventory, a flaw the attacker already holds, and a window of time the attacker controls at both ends. The one variable the organization actually owns is the exposed instance, and many organizations do not have a current, complete picture of which of these platforms they run internet-facing, in what version, behind which unmonitored management plane.
Here is the honest part. "We patch on a defined SLA" is a real control, and it is not enough on its own against this window, not because teams patch too slowly, but because patching answers only one of the three questions that decide the outcome.
The three questions are: Do we know every internet-facing instance of these platforms we run, at their current version? For the ones we cannot patch immediately, would our controls actually detect an exploitation attempt in the interim? After we patch, can we prove the exploited path is closed and monitored, not just that a version number changed?
Compliance-grade evidence answers the first with an asset list that is usually stale, and the second and third with an assumption. The SD-WAN case is the clearest rebuke of assumption-based confidence: the actors ran their own validation scripts to confirm their cleanup held. They verified their work against reality. The defenders, in most environments, have no equivalent routine: nothing that confirms detection and response actually fire against the specific technique, on the specific exposed surface, before an adversary tests it for them.
Three actions a regulated CISO can take that do not depend on a faster patch cycle:
Treat exposure discovery as continuous, not quarterly. The exploited platforms this window were edge and management systems that drift in and out of inventory: a new SD-WAN node, a re-exposed SharePoint instance, a forgotten Unified CM interface, a UniFi management plane nobody remembers exposing. An asset list assembled last quarter cannot tell you what is exposed today.
Instrument the interim, not just the patch. For any of these platforms you cannot patch within hours, the meaningful question is whether an exploitation attempt against the unpatched interface would surface an alert. Establish that with evidence, on the actual exposed surface, rather than assuming the correlation rule that exists on paper would fire.
Re-verify after remediation. A patched version number is not proof the path is closed and watched. Where you safely can, reproduce the technique against the remediated instance and confirm both that it fails and that the attempt is detected and correlated.
This is where continuous validation earns its place in the stack, and it works as a loop rather than a single tool. Discovering what is exposed and proving whether that exposure would break through are two halves of one motion. The first is what an external attack surface capability like HELIOS is built for: continuous, high-frequency discovery of internet-facing assets, subdomains, certificates, and services, with change detection that surfaces a newly exposed instance in minutes rather than at the next quarterly sweep. The second is what a security validation platform like ATLAS is built to answer: it deploys validation agents in the real environment and executes the relevant attack techniques against the actual controls, then compares what the security stack did against what it should have done, quantifying which techniques were detected, which went unseen, and generating remediation output such as Sigma and Suricata rules where applicable. Used together as a discover-then-validate loop, they help turn "we applied the patch" into a supportable statement: which exposures are closed, which remain open, and whether an attempt on the open ones would actually be seen. That evidence is the difference between a patch record and a defensible answer to the question a board asks after the next disclosure lands early.
The patch window was never the whole control. This past month made that visible across seven platforms in a single stretch. The organizations that stay ahead of the next one will not be the ones that patch fastest. They will be the ones that already knew what was exposed, and could show what their defenses would do about it.