The patch is the disclosure.

The patch is the disclosure.

That sentence is the structural change a triage process has to absorb, and the SmarterMail timeline is a clean illustration of it. Build 9511 shipped on January 15, 2026 with the release notes line “critical security fixes” and no CVE identifier. No advisory was attached, no proof-of-concept was in circulation, and the watchTowr researchers who reported the vulnerability on January 8 were holding their writeup under coordinated disclosure. By January 17 an administrator had lost access to their own SmarterMail admin account and the server logs showed an external POST to /api/v1/auth/force-reset-password. Attackers had pulled the new build, run the .NET assemblies through a decompiler, diffed against the previous build, found the single added ValidatePassword call on the admin branch, and reconstructed the bug. Two days.

The bug itself is the kind of thing CVSS scores cleanly. The force-reset-password endpoint is marked AllowAnonymous. The request body carries an IsSysAdmin flag. When the flag is true the server branches to the administrator reset path and writes the new password without checking the old one; the user reset path validates correctly. Somebody wrote the permission check for users and forgot to write it for administrators. The score is 9.8 because the impact is total — pre-auth sysadmin password reset, then RCE via the built-in Volume Mount or System Events features through four API calls — and the score is right against the bug. What the score cannot represent is the dynamic underneath. The bug was patched before the bug was announced. The patch was the announcement. Operators learned about CVE-2026-23760 from the same artifact attackers learned about it from.

This is the same trust-assumption shape we have written about on disclosure-cadence cases like CVE-2024-41713 — the FortiOS, SAP NetWeaver, and Mitel MiCollab editorial entries name the gap between the clock the advisory runs on and the clock the operator runs on, in different directions. The SmarterMail case is the version of that gap that runs against the security community itself. The standard 14-day patch testing window — staging deployment, regression checks, change-window scheduling — is the discipline that turns “vendor shipped a patch” into “operator validated and rolled out a patch.” It is a real control, and on the cadence it was designed for it is the right control. The cadence it was designed for assumes the adversary needs longer to weaponize a patched vulnerability than QA needs to validate the fix. For closed-source code over a decompilable runtime in 2026, the assumption is empirically wrong. The companion field note carries the trend line: Mandiant tracked an average time-to-exploit of sixty-three days in 2018–2019, thirty-two days in 2021–2022, five days in 2023. VulnCheck’s 1H 2025 telemetry put thirty-two percent of newly exploited CVEs at on-or-before the disclosure date. The fourteen-day window is a planning artifact from an era the data has left behind.

The compliance clocks are calibrated to the older cadence too. PCI’s Requirement 6.3.3 gives operators one month from the vendor’s patch release. BOD 22-01 gives federal agencies twenty-one days from a KEV listing for entries with that interval. CISA added CVE-2026-23760 to KEV on January 26 with a February 16 federal due date — twenty-one days. The first in-the-wild exploitation was January 17, twelve days before the KEV listing and thirty days before the federal deadline. The deadlines reflect organizational change-management capacity, not threat reality, and the two numbers are visibly diverging. The auditing and authorization frameworks that anchor on those deadlines inherit the gap.

The narrow remediation is what SmarterTools’s release notes describe — upgrade to Build 9511 or later (current is 9610), check SmarterMail logs for external POSTs to /api/v1/auth/force-reset-password, look for result.txt in the webroot, look for MailService.exe spawning cmd.exe or powershell.exe. If any of those indicators are present the response is an incident-response engagement, not a patching ticket. The wider lesson is for the triage model the operator runs behind the patch. The tier where the patch is the disclosure now includes any .NET, Java, or otherwise decompilable closed-source product that ships through a quiet build channel without an attached advisory; the SmarterMail case is illustrative because the kinetics are well-documented, not because the kinetics are unique. The defensible posture is a tiered SLA where internet-facing assets and KEV-listed entries get a 24–72 hour emergency window, with the standard two-week testing cycle reserved for internal-only systems. The bar is no longer “did we patch within thirty days.” The bar is “did we patch before the diff was easier to read than the advisory we never received.”