CRITICAL: SM < build 9511 - Unauthenticated Admin Account Takeover possible!
Problem reported by J. LaDow - Today at 4:16 AM
Submitted
Sooooo apparently there were a lot more problems under the hood than we were initially told.

It seems anyone running SM builds < 9511 have some serious issues to contend with and most likely need to take them off line or completely firewall them until they are upgraded or you will be compromised. 

To quote the second article:
The vulnerability, which currently does not have a CVE identifier, is tracked by watchTowr Labs as WT-2026-0001. It was patched by SmarterTools on January 15, 2026, with Build 9511, following responsible disclosure by the exposure management platform on January 8, 2026.

It has been described as an authentication bypass flaw that could allow any user to reset the SmarterMail system administrator password by means of a specially crafted HTTP request to the "/api/v1/auth/force-reset-password" endpoint.

"The kicker of course being that said user is able to use RCE-as-a-feature functions to directly execute OS [operating system] commands," watchTowr Labs researchers Piotr Bazydlo and Sina Kheirkhah said."



ADDITIONALLY:

I was under the understanding that we were going to be alerted "privately" when things like this were discovered and going to be / were patched.  As of 6 days after the last release that stated "CRITICAL: security fixes" in it's description it's still radio silence on the severity of this issue.  The last communication received was telling us how build 9504 was going to solve all our problems but here we are. On top of this, we should be provided with details of the vulnerabilities and temporary mitigations - as not everyone can upgrade in the middle of the day to untested software while hosting one or a thousand domains. Hence, another reason there should be an LTS version that is not constantly adding "bleeding edge features" so that when (not if) situations like this happen, we have options and less fears of an upgrade. Forcing us all to essentially be beta testers is not sustainable. This is absolute insanity.
MailEnable survivor / convert --
Jack. Replied
Web.config rule

<rule name="Block force-reset-password endpoint" stopProcessing="true">
  <match url="^api/v1/auth/force-reset-password$" ignoreCase="true" />
  <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Blocked" />
</rule>


<rule name="Block force-reset-password (alt path)" stopProcessing="true">
  <match url="^api/auth/force-reset-password$" ignoreCase="true" />
  <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Blocked" />
</rule>

Jack. Replied
"The only remaining requirement is knowing the username of the administrator account. In most deployments, this is likely to be something predictable such as admin or administrator."
JerseyConnect Team Replied
Yeah we're seeing plenty of "User @ successfully force-reset-password" entries in the admin log. We cross checked our IIS logs and all of those POST requests got a 400, so we believe we're in the clear. 

Also went a step further and checked system admin logins by looking for instances of "Webmail Login successful: With user" where there was no @. Only seeing members of our team, so looking good for us.

Seems like anyone not on 9511 should rename the default sys admin account and set IP restrictions on their remaining sys admins.
Brian Kropf Replied
Can you remind me where to set the IP restrictions? 
J. LaDow Replied
Immediate advice builds < 9511 for mitigations would include blocking the API endpoint in the web.config, changing the current "default administrator" account password to something known (not re-used), then renaming the "default admininistrator" account username if you haven't yet at some point, and enabling the IP restrictions on the account (if possible) via the Settings -> Administrators -> <account> and there will be a box there for current builds.

For what it's worth: We are running 9511 and attempts to exploit found in the logs have been unsuccessful as this is patched in current release. They show success in the Administration log, but HTTP 400 in the web server logs (bad request).  We don't use EWS/MAPI - we moved our users off of it a while back - but the basics of what a mail server is expected to do (SMTP/IMAP) are stable in this build (9511) so far and we have no other user complaints.

It should be noted that there is no telling what other "issues" as they're called lately were fixed in this release that we don't know about yet.
MailEnable survivor / convert --
David Feuer Replied
Under settings -> administrators you can set the IPs there.

Reply to Thread

Enter the verification text