# ServiceNow's Patching Window Was Four Days. That Wasn't Enough.
A critical remote code execution flaw in ServiceNow's AI platform went from "patched" to "exploited" in less than a week. Whether that exploitation came from threat actors or the security research community is still unresolved — and that ambiguity is a story in itself.
CVE-2026-6875 is a sandbox escape in the ServiceNow AI platform that allows an unauthenticated attacker to execute arbitrary code under certain conditions. ServiceNow pushed patches to its hosted instances on July 14 and notified self-hosted customers to apply updates themselves. Also on July 14, cybersecurity firm Searchlight Cyber published full technical details including a working proof-of-concept.
By July 18 — four days later — threat intelligence firm Defused reported seeing exploitation in the wild.
## Four Days Is Not a Patching Window
For anyone who manages enterprise security, four days from patch-to-exploitation is a gut punch. But the more uncomfortable reality is that the attack surface here was asymmetric from the moment Searchlight dropped their PoC.
Hosted ServiceNow customers had patches deployed automatically. Self-hosted customers had to receive the advisory, validate it in their environment, test the patch, schedule a maintenance window, and apply it — a process that in most enterprises takes one to three weeks, minimum, under normal change management procedures. In large regulated industries, that timeline can stretch further.
Searchlight's decision to publish a working proof-of-concept on the same day as the patch release handed that gap to anyone paying attention. The intent was likely transparency — giving defenders the tools to understand what they were protecting against. The practical effect was a four-day countdown for organizations that couldn't patch instantly.
This is not a new dilemma. It's a recurring failure point in coordinated vulnerability disclosure, and the ServiceNow case illustrates it cleanly: when a sophisticated PoC drops simultaneously with a patch, the disclosure serves defenders in theory but attackers in practice.
## The Attribution Problem Nobody's Talking About
Here's where it gets more complicated. Defused issued a correction on Monday acknowledging that after closer analysis, the captured exploit payload was identical to Searchlight Cyber's own proof-of-concept. Not inspired by it — identical.
That's a materially different story than "attackers are exploiting CVE-2026-6875 in the wild."
What it actually means: someone scanned for vulnerable ServiceNow instances and fired Searchlight's own PoC at them. That could be a threat actor moving fast. It could just as easily be a security researcher checking exposure at scale, a penetration tester, or a bug bounty hunter sweeping for unpatched targets. ServiceNow itself said it has not observed evidence that the exploitation reached its hosted instances, and its own advisory has not been updated to reflect active exploitation.
This matters because the narrative trajectory in security reporting often locks in fast. "Exploited in the wild" lands as a headline, and the correction — "actually it might be researchers" — rarely travels as far. ServiceNow had this exact situation play out before, when CISA-flagged exploitation of a previous vulnerability turned out to be attributed to security researchers rather than attackers. We're potentially watching the same movie again.
None of this means defenders should relax. But it does mean the threat picture is genuinely uncertain, and acting on incomplete attribution intelligence has real costs — emergency change windows, vendor calls at 2 AM, audit trails, executive escalations. Organizations need to understand what they're actually responding to.
## What Self-Hosted ServiceNow Customers Should Be Doing Right Now
Self-hosted instances carry the full patching burden here, and they're almost certainly the target of any opportunistic scanning. The checklist is short but non-negotiable:
ServiceNow is a legitimate high-value target. It's embedded in IT service management, HR workflows, security operations, and procurement across some of the largest organizations on earth. A foothold in a ServiceNow instance isn't just RCE on one box — it's potential access to ticketing workflows, asset inventories, and internal service catalogs that can be weaponized for follow-on attacks.
## A Platform That Hasn't Been a KEV Staple — Until Now
Worth noting: ServiceNow vulnerabilities have historically not attracted heavy threat actor interest. CISA's Known Exploited Vulnerabilities catalog currently lists only two ServiceNow flaws, both from 2024. That's a thin track record compared to enterprise platforms like SharePoint, Citrix, or Fortinet products, which appear in the KEV catalog with depressing regularity.
That relative quiet might encourage some security teams to treat ServiceNow as lower-priority. CVE-2026-6875 is a reason to recalibrate. As ServiceNow has expanded its AI platform capabilities and deepened its integration into enterprise workflows, its attack surface has grown. Platforms that weren't attractive targets five years ago are attractive now.
---
## HackWire Analysis
The most underreported dimension of this story is the disclosure timing, not the vulnerability itself.
Searchlight Cyber releasing a working PoC on the same day as the vendor patch is the kind of decision that looks reasonable in isolation — give defenders full information, maximize transparency — and creates systemic risk in practice. The implicit assumption is that defenders and attackers have equal capacity to act on new information. They don't. Defenders need change management approval, patch testing, rollback plans, and maintenance windows. Attackers need a working exploit script and a scanner.
The four-day window from patch to reported exploitation is actually longer than we've seen in recent high-profile cases. The SharePoint vulnerability disclosed earlier this year was reportedly being exploited within 72 hours. SonicWall zero-days were in active use for weeks before the patch even existed. CVE-2026-6875 at least gave defenders a head start — barely.
What the security industry still hasn't resolved is when simultaneous disclosure is irresponsible versus essential. The current informal norm — publish PoC with patch, trust defenders to move fast — systematically disadvantages organizations with mature change management processes. There's an uncomfortable irony in that: the enterprises most likely to have formal patching procedures are also the most likely to be lagging in those first four days.
The Defused correction also deserves wider attention. Intelligence firms correcting themselves on attribution is more common than published corrections suggest. The incentive to be first with "in-the-wild exploitation" is real; the incentive to update that claim when new analysis points elsewhere is weaker. Security teams building response decisions on unverified attribution claims are flying on bad instruments. Verify before you escalate internally — and check for corrections before you cite anything in an incident brief.
For defenders right now: patch it, check your exposure, and don't let the attribution uncertainty become an excuse to deprioritize the remediation.
— HackWire Editorial
---
## Related Coverage