CRITICAL: SM < build 9511 - Unauthenticated Admin Account Takeover possible!

Problem reported by J. LaDow - 1/22/2026 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."

https://labs.watchtowr.com/attackers-with-decompilers-strike-again-smartertools-smartermail-wt-2026-0001-auth-bypass/

https://thehackernews.com/2026/01/smartermail-auth-bypass-exploited-in.html

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 --

20 Replies

Reply to Thread

Jack. Replied

1/22/2026 at 5:29 AM

Web.config rule

</rule>

</rule>

Jack. Replied

1/22/2026 at 6:29 AM

"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

1/22/2026 at 7:16 AM

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

1/22/2026 at 7:21 AM

Can you remind me where to set the IP restrictions?

J. LaDow Replied

1/22/2026 at 8:30 AM

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

1/22/2026 at 8:31 AM

Under settings -> administrators you can set the IPs there.

Sabatino Replied

1/22/2026 at 9:21 AM

They reset my admin password a few hours ago too.

They didn't do much, though, because I have either IP or 2FA records for all the admins.

Sabatino Traini Chief Information Officer Genial s.r.l. Martinsicuro - Italy

Giorgio Borra Replied

1/22/2026 at 9:48 AM

I can’t connect to the server anymore as a local administrator—only as a domain administrator. I manage six domains and I can’t manage them anymore. What happened? What can I do? SM Professional 9511

Giorgio Borra

Derek Curtis Replied

1/22/2026 at 9:51 AM

Employee Post

As Tim stated in another thread, we will notify customers of security issues, and also let them know what a fix is available. For this issue, we sent that email on the same day the fix was released, on January 15th. That was literally 2 days after working with watchTowr and getting details of the issue, testing ourselves, getting the fix applied, then verifying the fix.

watchTowr says they have a 90 day disclosure window, and they made that apparent in their initial communication with us. We worked with them in good faith, letting them know when the fix was released, and then offered them the ability to re-test to ensure the issue was resolved. We assumed their 90 day disclosure would be respected, but that's not to say they are necessarily bound to it. However, posting copy/paste PoC code that can be used to facilitate the exploit is, in our opinion, irresponsible, especially for a security company.

We don't detail security fixes because we don't want that information known and potentially exploited before customers can get their systems patched. We work with companies and fix issues, then push those fixes, as quickly as we can. (In most cases, within mere days of being notified.) Publishing code that anyone can use is just mind-boggling, especially when it's done by the company who specialize in security. Posting about the issue is one thing, but posting code that can be used to actively exploit a system is flat out irresponsible as it puts customers and servers at risk.

Derek Curtis CCO SmarterTools Inc. www.smartertools.com

Derek Curtis Replied

1/22/2026 at 9:51 AM

Employee Post

Giorgio -- we'll get a ticket started with you.

Derek Curtis CCO SmarterTools Inc. www.smartertools.com

Mark Thornton Replied

1/22/2026 at 10:09 AM

I've read, re-read, and handed the message off to others to show me what I missed. But nowhere in the email I read on the 15th indicated a new significant failure mode that wasn't addressed in 9504. The message did not convey a sense of urgency, just a sense that you were trying to tell me you were on top of things. So here we are...

I have a ticket open already and the first solution offered failed. Now I am waiting on the next response.

J. LaDow Replied

1/22/2026 at 10:20 AM

If I was in an emergency situation and couldn't wait for an official response, this is what I would do:

Get logged into your server via RDP
Block the web endpoint they're hitting for hosts other than localhost/127.0.0.1 in the public facing webserver

Restore an older administrators.json file from backups - you'll have to find in your log files when the first time was the endpoint had unauthorized access to know how far back you need to go. (thanks to Mark Thornton for this)

That at least gets gets you back into the system, while keeping the endpoint blocked from the outside world.

Then you can login from local browser on server while on RDP and apply some or all of the mitigations I noted halfway back in this thread or upgrade to 9511.

The longer you don't have admin control of your server, the closer you are to having to re-image everything and be totally compromised if you don't get ransomed first. It is obvious at this point full scans of servers will be required due to how much access the default admin account has if you've lost control of the account for any period of time.

Other than edits/corrections I won't post on this further.

Dear Derek: We're not asking for the details - but when you guys find out about something like this, the email should include something like "you should block this endpoint until you are able to upgrade" not just leaving everyone hanging or not saying anything at all. Additionally, and we're still reviewing logs - the only emails we received claimed that 9504 fixed all the issues - nothing has been received regarding the urgency to move to 9511. Just a heads up.

MailEnable survivor / convert --

Mark Thornton Replied

1/22/2026 at 10:51 AM

So I'm dead in the water here. Official responses aren't fixing this and I really don't want to play hacker on my own system but that sounds like where this is going. Either that or a reformat, restore backups, and deal with lost data. The pitchforks are already outside my door after I shut down access to the mail server.

I'm being told my server was compromised on 1/17/26 and loading administrators.json from a date prior to that would address the issue. That has not worked so far. I'm waiting on the next suggestion while reading through how to hack my machine. I really didn't have anything else to do today, nothing at all.

Mark Thornton Replied

1/22/2026 at 10:58 AM

Still trying to figure out why, but I can get in now. I restored an older administrators.json file from my backups. It didn't work initially when I started the smartermail service, but when I came back after explaining to others why mail was down I was able to log in.

Sébastien Riccio Replied

1/22/2026 at 12:44 PM

Holy crap, what is this again ... We're on 9511 but I'm seeing a lot of:

[2026.01.22] 10:13:17.789 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:13:17.835 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:13:17.843 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:13:19.233 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.155 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.270 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.298 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.303 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.389 [180.210.220.54] User @ successfully force-reset-password
[2026.01.22] 10:14:03.454 [180.210.220.54] User @ successfully force-reset-password

In our administrative log.

If the issue was patched in 9511, why are we seeing such "successfully" messages in the log ??

We need a clear explanation about what is going on here!

Thanks

Sébastien Riccio System & Network Admin https://swisscenter.com

Mark Thornton Replied

1/22/2026 at 12:53 PM

I'm seeing the same thing in my logs. Who is "User"?

Andreas Huber Replied

1/22/2026 at 12:53 PM

@Mark Thornton

I think You need this: https://portal.smartertools.com/kb/a2739/reset-administrator-username-and-password.aspx

J. LaDow Replied

1/22/2026 at 12:58 PM

Build 9511 will show "successful" the Administration log, but if you check the web server logs - the HTTP response code will be 400 - which is a "BAD REQUEST" result - this means the actual request was unsuccessful. SmarterTools will fix the erroneous log entry in a later build, I'm sure.

Build 9511 is safe from this -- but anything older is NOT.

MailEnable survivor / convert --

Mark Thornton Replied

1/22/2026 at 12:59 PM

I'm on 9511, I've already recovered my primary admin password. The server is currently being fully scrubbed by my AV software. I've looked for things in the administrative logs as suggested in previous posts but there is no "from country China" or "Show Password" to be found. I did find "force-reset-password" but only for "User".

Thanks J.Ladow for the additional info. My server is going to be scrubbing into the night but so far nothing has been found amiss.

J. LaDow Replied

1/22/2026 at 1:04 PM

You're very welcome -- in addition - be SURE to check your configuration in the "Volume Mounts" section to be sure nothing has been executed that might download something.

I would scan the system for files created/modified during the time-frame when the password was not in your control just in case the AV scans don't detect something "too new" that's been dropped.

MailEnable survivor / convert --

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text