48 hours from patch to exploitation: CVE-2026-23760 and the window that doesn't exist anymore

On January 29, Storm-2603 breached SmarterTools, the company that makes SmarterMail, using a vulnerability in SmarterMail. The entry point was an employee-managed VM on the company’s internal network that had never been updated to the build that fixed CVE-2026-23760. The vendor that wrote the patch got popped because one internal machine didn’t have it.

That detail alone would be worth a writeup. But the more structurally important number is 48: the hours between the patch shipping and the first confirmed exploitation in the wild. No public proof-of-concept existed. No advisory to reverse-engineer from. Attackers decompiled the patched .NET assemblies, diffed them against the previous build, found the fix, reconstructed the vulnerability, built a working exploit, and started using it. Two days.

The bug, briefly

SmarterMail’s force-reset-password API endpoint at POST /api/v1/auth/force-reset-password is marked AllowAnonymous. The request accepts an IsSysAdmin boolean. When set to true, the server branches to the administrator reset path and updates the admin password without verifying the old one. One unauthenticated POST request gives you the sysadmin account.

The regular user reset path correctly validates the existing password. The admin path does not. Somebody wrote a permission check for users and forgot to write one for administrators. CVSS 9.8.

The fix in Build 9511 (January 15, 2026) adds a ValidatePassword call on the admin branch. watchTowr decompiled the assemblies and confirmed the diff was exactly one method call. From diff to exploit is mechanical, not creative.

From admin access, attackers reach RCE through SmarterMail’s built-in Volume Mount or System Events features. Huntress documented the in-the-wild chain: reset the password, authenticate, register a malicious system event hook, create a dummy domain to trigger it. Four API calls, unauthenticated to SYSTEM. The attackers then cleaned up after themselves, deleting the event hook and dummy domain to reduce forensic artifacts.

The timeline

• January 8, 2026: watchTowr reports the vulnerability to SmarterTools under responsible disclosure.
• January 13: SmarterTools acknowledges.
• January 15: Build 9511 ships. Release notes say “critical security fixes.” No CVE assigned yet.
• January 17: First confirmed exploitation. An administrator reports losing access to their own admin account. Logs show the force-reset-password endpoint was used. Forty-eight hours after the patch.
• January 22: Huntress publishes their analysis. watchTowr’s writeup follows.
• January 26: CISA adds CVE-2026-23760 to the KEV catalog. Remediation deadline: February 16.
• January 29: Storm-2603 breaches SmarterTools’ own infrastructure via an unpatched internal VM.

watchTowr titled their blog post “Attackers With Decompilers Strike Again.” The thesis is in the title. No public PoC existed when the January 17 attacks began. The threat actors independently reverse-engineered the patch and weaponized it before the security community had even published an analysis.

The trend line

The 48-hour window is not exceptional. That’s the point. Mandiant and VulnCheck have been tracking time-to-exploit (TTE) across the industry, and the numbers have collapsed:

• 2018-2019: Average TTE was approximately 63 days.
• 2021-2022: 32 days.
• 2023: 5 days. Of 138 vulnerabilities Mandiant tracked, 12% were exploited within one day, 29% within one week.
• 2024: Average TTE went negative. Attackers were exploiting vulnerabilities, on average, before patches were publicly available.
• 1H 2025: VulnCheck found 32.1% of newly exploited CVEs showed exploitation on or before the disclosure date. Roughly 28% of all observed exploits launched within 24 hours.

Most organizations run patch testing cycles of 9-14 days. That testing window was designed for a world where exploit development took longer than testing. The assumption was valid when TTE was measured in months. It is not valid when TTE is measured in hours. A two-week patch cycle means your testing environment had the fix for twelve days while the exploit was already in production use against systems like yours.

CISA’s federal remediation deadline for this CVE was February 16, a full month after the patch shipped. The exploit was live on January 17. That gap is not CISA being slow; it’s the acknowledgment that their deadlines reflect organizational capacity, not threat reality. Those two numbers are on a collision course.

What Storm-2603 did

Storm-2603 (tracked by Secureworks as Gold Salem) did not exploit CVE-2026-23760 on January 17. They waited until January 29, two weeks after the patch shipped. Their target was SmarterTools itself.

The entry point was an employee-managed SmarterMail VM on the company’s internal network, stood up without IT oversight and never updated to Build 9511. After resetting the admin password via the unpatched API, Storm-2603 used the Volume Mount feature for initial command execution, downloaded a malicious MSI installer from Supabase (a legitimate cloud backend, used for delivery evasion), and installed Velociraptor as their C2 tool. They moved laterally across the office network and QC datacenter, compromised Active Directory, and detonated Warlock ransomware approximately 6-7 days later. Roughly 12 Windows servers were encrypted.

SmarterTools stated customer-facing services were unaffected. The breach originated from one unmanaged shadow VM out of roughly 30 SmarterMail installations in their environment. One shadow VM is all it takes when the exploit is four API calls and the patch window is measured in hours.

The group has a broader operational profile. Microsoft attributes Storm-2603 as China-based with “moderate confidence,” though Sophos assesses the motivation as financial. They previously operated LockBit Black campaigns and actively target Veeam, ESXi, and SharePoint environments. Their target list includes US government agencies (NNSA, Department of Education, NIH) and European government networks.

What this means for prioritization

The two-week patch cycle is a planning artifact from a period when exploit development was slow. The data no longer supports it as a universal SLA.

The emerging model is tiered: internet-facing assets and CISA KEV entries get 24-72 hour emergency windows. Internal-only systems retain longer testing cycles. The distinction is not about severity scores; it is about exposure. A CVSS 9.8 on an internal-only system behind a VPN has a different risk profile than the same score on an internet-facing mail server.

For SmarterMail specifically: Build 9511 or later patches CVE-2026-23760, CVE-2026-24423, and subsumes the earlier fix for CVE-2025-52691. Current release is Build 9610. If you have not patched, the exposure is not theoretical. Check your SmarterMail logs for POST requests to /api/v1/auth/force-reset-password from external IPs. Look for result.txt in the SmarterMail webroot. Look for MailService.exe spawning cmd.exe or powershell.exe. If any of those indicators are present, this is an incident response engagement, not a patching ticket.

What to watch

The .NET decompilation pipeline is reproducible and requires no zero-day research capability, only the ability to read a diff. Any .NET-based infrastructure product (mail servers, management consoles, monitoring tools) that ships a security patch is simultaneously publishing an exploit development guide to anyone with dnSpy and a few hours.

The more structural question is whether the industry’s vulnerability disclosure model can survive a world where every patch is also a disclosure. The answer is probably yes, but not with a 14-day testing window sitting between the patch and the deployment. CVE-2026-23760 is a clean illustration of what happens in that gap.

PatchDay Alert has covered the full SmarterMail cluster this week: CVE-2026-24423 (ConnectToHub RCE) and CVE-2025-52691 (silent patch file upload). If you run SmarterMail, all three apply.