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

J

Jack. Replied

1/22/2026 at 5:29 AM

Web.config rule

</rule>

</rule>

J

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.

B

Brian Kropf Replied

1/22/2026 at 7:21 AM

Can you remind me where to set the IP restrictions?

J

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

D

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

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.~~ We find an email in our server logs that most likely contained the notification but it never made it to the destined inbox - still chasing that issue. Our main concern is when your company was notified of the vulnerability, we should have gotten an email with mitigation instructions until a fixed build was released. Security by obscurity does not work. 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"?

A

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

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

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

Gabriele Maoret - SERSIS Replied

1/22/2026 at 2:07 PM

@Derek Curtis:

We never received any emails from you (SmarterTools) with vulnerability reports...

I also checked my spam folder and found nothing...

So the warning email you said you sent on January 15th never reached us...

EDIT:

After searching further, I found the notification email, which only arrived at our "acquisti@" address... unfortunately, this address reaches the secretaries who manage purchasing (..."acquisti" in Italian...) and not the technical staff.

However, we have two other registered and authorized email addresses in our SmarterTools portal account (my personal one and the general one for the technicians). Nothing has arrived at these two email addresses.

I therefore ask you to modify your internal procedures and send notification emails to ALL registered email addresses, including additional and/or secondary ones.

P.S.: P.S.: I must honestly say that the email sent to our "acquisti@" address clearly states that it is STRONGLY RECOMMENDED to update to v. 9511 (and not just 9504, as someone else above says).

So I think the warning was correct and not fallacious.

I'm reporting here the screenshot of the warning email, for confirmation:

Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

John Quest Replied

1/22/2026 at 3:44 PM

I can also report that I never received any notification from SmarterTools about this.

Heimir Eidskrem Replied

1/22/2026 at 3:55 PM

We are on an older version than 9511 and are seeing the

successfully force-reset-password log entries

Who are the USer in the log entry, how do we find out?

Derek Curtis Replied

1/22/2026 at 5:17 PM

Employee Post

Regarding emails:

Authorized Logins for an account don't have the same communications settings as primary account holders because Authorized Logins were intended to have access to certain areas of an account, like for billing or AP/AR logins. They weren't intended as communication outlets. That said, we will be making a change to our mailing list to include those accounts moving forward. At a later date, we'll give Authorized Logins the ability to manage their communication/email preferences just as the primary account login can.

For customers who did not receive the notification, primarily you, John Quest, according to our SMTP logs, we did attempt to deliver that email but were met with an exception when attempting to connect to your server. You may want to review the logs on your mail server, on any gateway or appliance you may have in front of your mail server, etc. Our initial attempt was actually at 3:45 a.m. on 16 Jan 2026. (It's a big mailing list.)

Derek Curtis CCO SmarterTools Inc. www.smartertools.com

Derek Curtis Replied

1/22/2026 at 5:20 PM

Employee Post

For anyone running 9511 who sees the "Successfully force-reset-password" entry in administrative logs, check your web server logs. As J LaDow mentioned earlier in this thread (thanks, by the way), those attempts will actually fail. We'll clean up those logs in a future release.

Derek Curtis CCO SmarterTools Inc. www.smartertools.com

Derek Curtis Replied

1/22/2026 at 6:24 PM

Employee Post

And speaking of emails, as we've done the last couple of weeks, we just sent another email regarding today's release and a fix for a security issue we received yesterday. This email will get to all Account logins: primary and authorized.

Derek Curtis CCO SmarterTools Inc. www.smartertools.com

D

David Feuer Replied

1/22/2026 at 7:28 PM

So, but a bit of humor in all of this.

I installed today's build and in an abundance of caution changed the admin user and password.

And could not log in.

Did the reset process in the json file.

And could not log in.

Called someone over to look.

0.2 seconds later, "I know what you wanted to type in for the admin user name, why did you put in dave?"

Yeah....go me.

D

David Maggard Replied

1/22/2026 at 10:22 PM

Few questions, is there a quick thing to look for in the logs to see if any passwords were changed?
None were revealed so that is a relief, but I want to make sure none of the accts were changed so ppl can relay or whatever.
If after following the directions to change the password in administrators.json I can't login what should I check?

This couldn't have come at a worse time, our main business was effectively shutdown for the past few months so I had to let maintenance lapse earlier this month until things pick up, so were are SOL support wise, luckily 9511 was released just before it ended so I should be able to at least update to that.

Edit:

Well I spoke too soon, most recent patch I can use is 9504, so I am assuming I have to block webmail completely until I can switch to something else :/

J

J. LaDow Replied

1/22/2026 at 10:25 PM

9511 has an unknown vulnerability that will most likely be exploited at scale within 48 hours.

Just a heads up.

MailEnable survivor / convert --

D

David Maggard Replied

1/22/2026 at 10:45 PM

Does anyone know what version this bug started?

J

J. LaDow Replied

1/22/2026 at 10:50 PM

Unfortunately that won't matter - as any version prior to 9518 has major security flaws and should not be running on a production server at this point. Even if you went back to before one bug existed, one of the other bugs will be there and leave you just as vulnerable.

MailEnable survivor / convert --

echoDreamz Replied

1/22/2026 at 10:51 PM

For some of the other servers we manage, I assume having IP restrictions as well as 2FA will prevent a successful login even if the password change is successful?

J

J. LaDow Replied

1/22/2026 at 11:07 PM

IP Restrictions are said to help - can't speak for 2FA as there's no telling if the force-password-reset blows out the 2FA when it's triggered - but it leaves IP restrictions in place.

MailEnable survivor / convert --

Stefano Replied

1/23/2026 at 1:53 AM

@echoDreamz I can say that 2FA has saved my life 😉

Jade B Replied

1/23/2026 at 2:48 AM

Just an FYI for those that have patched, Smartermail is still reporting these auth attempts as successful despite the password not being changed.

Smartertools may want to resolve this false positive.

[2026.01.23] 10:33:15.666 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:26.488 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:27.252 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:28.037 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:28.818 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:29.599 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:30.377 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:31.167 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:31.940 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:32.711 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:33.486 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:33:34.242 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:38:56.240 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:38:57.902 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:38:59.542 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:01.206 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:02.850 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:04.481 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:16.139 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:17.740 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:19.362 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:20.978 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:22.611 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:39:25.569 [176.88.174.226] User @ successfully force-reset-password
[2026.01.23] 10:39:41.624 [176.88.174.226] User @ successfully force-reset-password
[2026.01.23] 10:42:45.615 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:42:57.244 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:08.921 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:10.527 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:12.171 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:13.812 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:15.447 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:17.063 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:18.685 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:20.314 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:21.946 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 10:43:33.590 [146.70.199.170] User @ successfully force-reset-password
[2026.01.23] 11:35:10.779 [57.128.74.124] User @ successfully force-reset-password

Gabriele Maoret - SERSIS Replied

1/23/2026 at 7:57 AM

David, this is a human error, and we all make mistakes... The important thing is to acknowledge it, learn from it and apply it for the future, and try to fix it quickly...

Far be it from me to justify SmarterTools, but I know of other very large companies that have made similar mistakes despite being MUCH stronger, larger, and more organized than SmarterTools (a few examples, but the list is very long: Microsoft, Fortinet, 1Password, CrowdStrike, SolarWinds MSP AKA N-able, etc.).

If I had to stop using all the products of anyone who made one or two serious mistakes, then I wouldn't use anything anymore...

Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Jay Altemoos Replied

1/23/2026 at 8:15 AM

So what I am getting from all this is the API seems to be the problem here correct? For those of us that don't use that feature or care to, can SmarterTools give us the option of turning that feature off? I am still going to patch my server with the latest release tonight and I appreciate ST addressing the issue.

J

J. LaDow Replied

1/23/2026 at 8:24 AM

It can't be turned off - the web interface runs on it.

MailEnable survivor / convert --

Jay Altemoos Replied

1/23/2026 at 8:33 AM

Thank you for that bit of information J.LaDow. Shoots that idea down.

J

J. LaDow Replied

1/23/2026 at 8:49 AM

You can sometimes block the vulnerable endpoints - but that would mean we have to know what they are - which is the problem. We don't find out what's vulnerable until exploitation shows up in the wild. After 30+ years in IT, one thing I learned is security by obscurity doesn't work.

MailEnable survivor / convert --

Josip Meglaj Replied

1/23/2026 at 9:44 AM

Just FYI, I had two compromized Servers.

The small one is from a tiny SME with three users and FREE Edition (don't ask why I didn't migrated it), they were in since 22th January 2026 03:10 CET, so before the information of this incident from SmarterTools.

I had to re-create my admin via the JSON Patch from "portal.smartertools.com/kb/a2739/reset-administrator-username-and-password.aspx"

The big one is mine, and due to a hurry, I have not screenshottet the admin-panel, but the oldes Password Age was "two days", so the vulnerability was active on Wednesday, 21st January 2026.

I could, if someone is interested, restore the compromised Server to a different location and update this, but I think I have better to do, like inform the users that they should recreate their password.

J

Jay Dubb Replied

1/23/2026 at 9:58 AM

Is anyone else thinking that with the number of recent CVEs that were reported as Critical-- as in "patch immediately"-- that instead of waiting for security firms to find problems on their own and report them to ST, it might be time for ST to engage an outside security vendor to perform a full code audit? We've now rushed multiple new builds into production, out-of-cycle, because of critical security flaws.

Jade B Replied

1/23/2026 at 10:10 AM

@Jay Dubb

I said the same thing in another thread

https://portal.smartertools.com/community/a97681/new-user-on-google_abc_com.aspx

Every feature that is available needs to reconsidered and the thought process should always start with “how can this be compromised and what can we do to mitigate it.”

Playing catchup and being reactive vs proactive is no longer viable.

J

Jay Dubb Replied

1/23/2026 at 10:23 AM

@JerseyConnectTeam wrote: 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.

We're seeing "User @ successfully force-reset-password" entries in the IIS logs as far back as Jan 18. Thankfully we had admin access restricted by IP, but it's sobering to realize the potential scope of this.

Richard Laliberte Replied

1/23/2026 at 10:54 AM

@Jay Dubb

it was my understanding from various threads and feedbacks that SM is already actively working with a few vendors to lock down everything. A bigger question would be is it because SM started working with these vendors to find and fix flaws that everything is being released. I find it hard to believe that just out of the blue these vendors decided to do full audits on SM without some kind of financial incentive...

If it was the SM team actively engaging with these vendors to find all these issues, then they at least deserve credit for that.

John Quest Replied

1/23/2026 at 11:05 AM

OK, I found out why I was not receiving notices. The IP you are sending from belongs to Google. Sadly, we get a lot of FUFU from Google IPs. I have made an allowance.

J

Jay Dubb Replied

1/23/2026 at 11:07 AM

I'll be on record that security flaws happen, even when great teams develop code with good security in mind. Nobody is perfect and things can be exploited in ways nobody could necessarily have predicted. Where I draw the line is carelessness-- the kinds of vulnerabilities were the community is left wondering how something so sloppy could have passed QC reviews.

I am NOT making any representation as to the root of any of these Smartermail CVEs, that was just a comment in general and I have no insight to ST source code. What matters is how a vendor responds to flaws-- promptness, correctness, not rushing out a patch that breaks more things, and just as importantly, is transparent with their customers when something like this happens. (in other words, the opposite of how Microsoft responds after major outages)

R

Ryan Sinclair Replied

1/23/2026 at 11:15 AM

I’m genuinely concerned about the current SmarterMail situation and the recurring vulnerabilities being discovered. It raises serious questions about whether a professional third-party security audit of the code has ever been conducted, or if regular penetration and exploitation testing has been performed on the software. Given the critical role SmarterMail plays in business communications, these vulnerabilities undermine trust and expose customers to significant operational and data-security risks.

Today, as a direct result of the delayed notification email that SmarterTools sent last night regarding this vulnerability, one of our clients forwarded the message to us. After reviewing their server, we were able to determine that it had already been compromised for at least three days. During that time, attackers created administrator users, downloaded the company’s emails via SMTP, and sent out several emails from the compromised server, confirming that the breach had active and real-world impact well before the official notification was received.

I tried to upload the image of the hack, but it wasn’t possible.

Today we decided to migrate to Google Workspace after having purchased an expensive SmarterMail license and paid for the update over the past year. What makes the situation even worse is that, after all the problems caused by the code vulnerabilities, there are still many customers who trusted the product, paid for a license, and today are unable to update due to the high costs. How much has SmarterTools earned from upgrades as a result of this vulnerability?

John Quest Replied

1/23/2026 at 11:20 AM

This is making me glad we didn't renew, this bug is so egregious I don't know if I can ever trust SmarterTools products again. How anyone could write an api that allows changing the primary admin password with zero authentication is unbelievable.

Well, then you better not use anything from Microsoft, Google, CloudStrike, Symantec, Amazon, etc so forth and so on.

John Quest Replied

1/23/2026 at 11:24 AM

Today we decided to migrate to Google Workspace after having purchased an expensive SmarterMail license and paid for the update over the past year.

Yes, because relying upon a global cloud conglomerate will guarantee safety and no problems.

(COUGH COUGH)

R

Ryan Sinclair Replied

1/23/2026 at 11:41 AM

@John Quest

Relying on Google Workspace is not about assuming “guaranteed safety” or believing any platform is immune to vulnerabilities. It is about risk reduction, security maturity, and incident response capability.

In contrast, the recent SmarterMail vulnerabilities were actively exploited in the wild for days before customers were formally notified, and remediation required costly license upgrades that many customers cannot afford. The delayed communication, combined with the lack of clear guidance during the active exploitation window, significantly increased exposure.

I ask you this: did SmarterTools at least try to provide any mitigation guidance in the emails they sent or in this forum? The answer is no, and this allowed the vulnerability to remain exposed for an additional three days. What mattered most was that everyone paid to upgrade their SmarterMail version.

Jade B Replied

1/23/2026 at 11:43 AM

Well said Ryan on both of your posts.

Richard Laliberte Replied

1/23/2026 at 11:44 AM

@John Quest

the part i love about this is all the ones that say they didn't renew, or switched away, yet still find time to come into the threads and moan and groan instead of actively trying to submit useful details to help the community get over these issues.

yes, i believe a few balls were dropped somewhere, but let's get over this problem then go back and revisit how things can be done better to make this product better. People are missing some really good hardening advice because so many people, some of which don't even use SM anymore, are in here doing nothing but complaining...

Jade B Replied

1/23/2026 at 11:49 AM

There’s absolutely nothing to love about this situation Richard, the reality is that bad code has lead to multiple vulns all disclosed within the same month. Whether those were by accident, negligence or any other reason is irrelevant.

The email that was sent out today was a waffle approach without any direct approach at the severity of the issue.

The what, the why and the how is what was required.

We’re sending this email because we are aware of yet another vulnerability in our code and we advise you patch immediately using the link below.

That’s clear instruction which emphasizes the severity, and get the message out asap.

John Quest Replied

1/23/2026 at 11:51 AM

In contrast, the recent SmarterMail vulnerabilities were actively exploited in the wild for days before customers were formally notified, and remediation required costly license upgrades that many customers cannot afford.

ANYBODY relying upon third party software in a production environment that, if a problem occurs, will significantly impact it's business, and DOES NOT HAVE ACTIVE SUPPORT on the software, is simply asking for problems.

I have been in IT for 26 years, and dealing with email availability and flow for 25 years.

Email is a field that REQUIRES proper attention and support all the time. I have seen so many companies treat email as an afterthought, including running their own email server on free versions of software, that then end up with major problems, including causing major problems for the rest of us.

If a company can not afford to have continuous active responsible support on their email server, they have no business having their own email server.

J

J. LaDow Replied

1/23/2026 at 11:57 AM

THIS IS THE REAL PROBLEM:

The moment a vulnerability is discovered. I mean the MOMENT - not days later - not when it's patched - the moment it's discovered / reported and verified - there should be detailed temporary mitigation instructions sent to every registered customer. That should be done out of respect alone for the thousands of customers who have spent millions over the years supporting this company. Period.

You want people to keep your customer base growing, stop leaving them in the dark when something like this happens and get the word out there immediately about what to do. IT is an arms race, and your adversary is anything from a teenager in a basement with nothing better to do to a nation state that would love nothing more than unfettered access to all the secrets stored on your enterprise mail server cluster.

I don't care how many CVE(s) software has - what I care about is how they're handled.

/end rant.

MailEnable survivor / convert --

G

George To Replied

1/23/2026 at 12:46 PM

For interest, I personally put a few product ChangeLog web pages in my Chrome Startup page. Whenever I start Chrome, I can "browse" any new updates.

N

Nathan Replied

1/23/2026 at 4:31 PM

The bugs raised so far really appear to indicate a sloppy approach, sure no one is perfect but given what has been disclosed so far you have to wonder what else will be found in the coming days. With price increases in recent years I would have expected QC would be covered but alas not. The fact that Microsoft et al have their problems is no defence.

In situations such as this the only saviour is total transparency.

J

J. LaDow Replied

1/23/2026 at 6:27 PM

So there are actually TWO CVE(s) for builds older than 9511 and yet undisclosed CVE(s) affecting build 9511.

https://www.cvedetails.com/cve/CVE-2026-24423/

and the one that resets the passwords:

https://www.cvedetails.com/cve/CVE-2026-23760/

MailEnable survivor / convert --

J

Jack. Replied

1/23/2026 at 7:27 PM

Hi @J.LaDow

Do you know what the API endpoint for ConnectToHub is? In the meantime, I will block everything related to ConnectToHub.

;-) Now we can’t sleep peacefully

J

Jack. Replied

1/23/2026 at 7:39 PM

I don’t know the ConnectToHub endpoint, but I hope this rule can help.

<rule name="Block any ConnectToHub endpoint" stopProcessing="true">
  <match url=".*" />
  <conditions>
    <add input="{URL}" pattern="connecttohub" ignoreCase="true" />
  </conditions>
  <action type="CustomResponse"
          statusCode="403"
          statusReason="Forbidden"
          statusDescription="Blocked" />
</rule>

J

J. LaDow Replied

1/23/2026 at 8:16 PM

It'll be more complicated than that - The hub system in there is part of the real-time communication between the SM webmail interface and the API/web application -- poking around like that without more information could cause all kinds of unknown problems.

The only failsafe mitigation without actual endpoint details is to get updated to 9518.

Whatever the unknown CVE(s) are for 9511 will be getting exploited within hours - as 9518 has been available for a little while and it doesn't take adversaries long to figure out what was patched/changed between the two builds.

MailEnable survivor / convert --

D

David Maggard Replied

1/24/2026 at 9:37 AM

Anyone that hasn't read https://labs.watchtowr.com/attackers-with-decompilers-strike-again-smartertools-smartermail-wt-2026-0001-auth-bypass/ should read it to know how the exploit works and why it is such a ridiculous vulnerability.

The previous file upload exploit is understandable, but not validating a password change request in my opinion is an obvious issue and indicts the competence of everyone involved, the main irony is that it DOES/DID validate password changes for regular users, but fails to on system admin accts(which is FAR more of a risk).

Roger Replied

1/25/2026 at 5:39 PM

I would generally recommend that affected individuals update as soon as possible. Websites such as https://leakix.net/search?scope=service&q=SmarterMail make it easy to see who is running which version of SmarterMail and could therefore be affected by the vulnerability.

Zach Sylvester Replied

1/26/2026 at 5:47 AM

Employee Post

Hey guys,

Another thing I would recomend is enabling 2fa on your admin account. This should help prevent unauthorized access.

Kind Regards,

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com

Rod Strumbel Replied

1/26/2026 at 8:11 AM

Zach... 2FA on Admin accounts is only available after a certain release level though correct? I don't see it as an option in 8451.

Zach Sylvester Replied

1/26/2026 at 9:52 AM

Employee Post

Hey Rod,

Admin 2FA was introduced in a later release last year, so it isn’t available in build 8451. That’s why you won’t see the option there. An upgrade would be needed to enable it.

Kind regards,

Zach Sylvester Software Developer SmarterTools Inc. www.smartertools.com

V

Vince Replied

1/26/2026 at 11:26 AM

I tried replacing the administrators.json file with a previous version 2 days old that was not compromised, but I still cannot login. says username or password incorrect.

Any ideas?

J

J. LaDow Replied

1/26/2026 at 11:35 AM

That might indicate that it was compromised more than once. The password reset exploit started getting exploited in the wild on our about 2026-Jan-9 --

MailEnable survivor / convert --

J

Jack. Replied

1/26/2026 at 11:55 AM

If you are not able to update at this time, you can add the following rule to the web.config file inside the MRS folder to prevent this endpoint from being invoked.

If you already have rewrite rules configured, you only need to add this 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>

If you do not have any rewrite rules configured yet, you must add the full block as follows:

<rewrite>
  <rules>
    <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>
  </rules>
</rewrite>

Richard Laliberte Replied

1/26/2026 at 12:31 PM

@Jack

Even if we are fully updated, would it affect anything to be overly protective and add this rule regardless? assuming we ever needed to reset the password this way we could always remove it.

J

J. LaDow Replied

1/26/2026 at 12:57 PM

The force-password-reset endpoint is part of the password reset system that relies on "third party" such as outside recovery email address. It's for resetting user passwords via token - and is validated differently. Researchers stated that method was properly validated. This is why the "user" endpoint was never exploited.

The only part of it that was vulnerable was if the HTTP POST to the endpoint contained a particular flag in the data. The patch validates POSTs with that flag using additional checks.

MailEnable survivor / convert --

V

Vince Replied

1/26/2026 at 1:10 PM

Thank You Jack.

I have restored a previous version and now can log in. I have added the rewrite rules. Will the rewrite rule stop a password change?

DRKZA Replied

1/26/2026 at 2:00 PM

You can test it with this curl call. You should get 403 or 404 depending on the rules you are using.

curl -X POST https://yourmailserveraddress.whatever/api/v1/auth/force-reset-password -d '' -v

Look for this in the response at the bottom:

< HTTP/2 404

< content-type: text/html

This also works well, drops those attempts to 404 and stops it before it hits the SM app.

<rules>

</rule>

</rule>

V

Vince Replied

1/26/2026 at 2:11 PM

Thank You DRKZA and everyone for chiming in.

Andrew Barker Replied

1/26/2026 at 3:21 PM

Employee Post

So everyone is aware, be careful adding the rule that Jack described. It might be a good temporary measure until you can If you have not upgraded yet to build 9511 or later, it may mitigate the issue. However, once you do upgrade, you should remove that rule. Blocking that API will cause issues for anyone who has an expired password or with a password that no longer meets the requirements.

J. LaDow somewhat touched on this, but I wanted to make it clear since some people were asking about using it after upgrading.

Andrew Barker Lead Software Developer SmarterTools Inc. www.smartertools.com

J

J. LaDow Replied

1/26/2026 at 3:31 PM

Thank you @Andrew for the clarification!

MailEnable survivor / convert --

Jade B Replied

1/26/2026 at 7:59 PM

Correction Andrew, version 9511 is susceptible to an authenticated administrator password reset and users should upgrade to 9518.

One of our honey pots running SmarterMail 9511 had their password reset, new admin users added and then further compromised using the volume mount feature (which has no consideration for validation and accepts os commands)

CISA has just sent out notice regarding both CVE’s for smartermail

t

terry fairbrother Replied

1/27/2026 at 3:02 AM

Do you think the windows version more susceptible over linux? Thinking of IIS and VBS, not something the Linux versions use (general question)

J

J. LaDow Replied

1/27/2026 at 7:06 AM

They contain the same vulnerabilities regardless of underlying operating system. All the attacker needs to do is adjust paths and tactics for one operating system or the other. If you fall victim to the password reset bug in versions older than 9511 - then you have a rogue unknown attacker with full admin rights to your mail server - doesn't matter which OS it's on - that's bad enough.

MailEnable survivor / convert --

Roger Replied

1/28/2026 at 2:37 AM

Hello everyone,

If you have an intrusion detection system (IDS/IPS) such as Snort or Suricata available on your firewall, you can use the following pattern to detect and immediately block this attack attempt.

alert http any any -> $HOME_NET any (msg:"SmarterTools SmarterMail Authentication Bypass (WT-2026-0001)"; flow:established,to_server; http.uri; content:"/api/v1/auth/force-reset-password"; fast_pattern; http.request_body; content:"|22|IsSysAdmin|22 3a|"; content:"|22|true|22|"; within:7; reference:url,labs.watchtowr.com/attackers-with-decompilers-strike-again-smartertools-smartermail-wt-2026-0001-auth-bypass/; classtype:web-application-attack; sid:00000001; rev:1; metadata:affected_product SmarterTools_SmarterMail, attack_target Server, tls_state TLSDecrypt, created_at 2026_01_27, deployment Perimeter, deployment Internal, deployment SSLDecrypt, confidence High, signature_severity Major, updated_at 2026_01_27, mitre_tactic_id TA0001, mitre_tactic_name Initial_Access, mitre_technique_id T1190, mitre_technique_name Exploit_Public_Facing_Application; target:dest_ip;)

Best regards,

Roger

YS Tech Replied

1/28/2026 at 4:57 AM

I updated to 9518 a couple of days ago, enabled 2FA on the admin account and changed the admin username and password. I thought everything was ok but this morning, can't login again!!!

I've now reset and added the rule to see how long that lasts!

What a nightmare.

I also can't reset my password from within webmail (is this the rule I've just set stopping me from doing this?) I just get a red "Incorrect Password" box, bottom right of the screen. But I am using the password I just logged in with?!

I've also noted in the logs that it says:

Webmail Attempting to login user: newadminname

Webmail Login failed: User [newadminname] not found

And looking at the hash, this looks correct as it's what I added there the other day, so is it that the system isn't recognising the admin user, not an issue with the password?

DRKZA Replied

1/28/2026 at 6:54 AM

That is potentially very concerning, the first thing I would check is in your IIS logs, look if they got a 200 success on the /api/v1/auth/force-reset-password endpoint.

Andrew Barker Replied

1/28/2026 at 7:09 AM

Employee Post

YS Tech,

Based on similar reports in the community, it looks like there is currently a bug preventing system admins from changing their password when 2FA is enabled. We have someone looking into it now, and we will hopefully have a fix soon. In the meantime, it looks like you will need to temporarily disable 2FA in order to change your password.

Andrew Barker Lead Software Developer SmarterTools Inc. www.smartertools.com

YS Tech Replied

1/28/2026 at 7:38 AM

DRKZA,

I can't find anything in the logs relating to the force-reset-password endpoint.

So maybe that's not my issue.

Perhaps i've found another bug where SM just doesn't let admin login because it doesn't recognise the user?

As I said before the password hash was the same as i'd added before, so that should have been the correct password. The only way for me to login was to manually hash the password to admin again (not ideal) and then go in, create a new account, logout, update the hash with the new password i just created on the new account, then it recognises me.

DRKZA Replied

1/28/2026 at 7:44 AM

Correct, if that was a problem it would show up with status code 200.

Montague WebWorks Replied

1/28/2026 at 8:14 AM

I did the same as you all a few days ago. Woke up this morning to find that my server was down. This is what greeted all visitors to my webmail (see image, below). On the server itself, there are a bunch of files dated this morning between 7:30 and 8:00 am eastern time US, and the administrator.json file had been modified, so I guess the password had been changed yet again. Third time in a week, despite adding an IP restriction on the admin account.

I have shut the service down and am waiting for a call back from my contracted admins. I don't know where to begin. Thankfully all the domains are still there with their accounts.

Mik MullerMontague WebWorks

M

Marc Frega Replied

1/28/2026 at 8:48 AM

I am having the same issue. Im still on the older build because Im stuck on 2012R2

I working on the move to another server but my current one is compromised and had the same issue as

Montague WebWorks

J

J. LaDow Replied

1/28/2026 at 8:48 AM

Those experiencing issues who are on build 9518 may want to start a fresh topic, as this one was originally for builds older than 9511 --

MailEnable survivor / convert --

YS Tech Replied

1/28/2026 at 8:54 AM

DRKZA,

Having said that, i've just found a load of these in another log:

All are 404.

Only started getting these on 22nd Jan, can't find any before this.

J

J. LaDow Replied

1/28/2026 at 8:55 AM

Anyone running builds older than 9518 will get compromised one way or another.

FULL STOP.

There is no real way to avoid it. Not with the bugs in the older versions.

The only way even remotely close to getting out of this is block your server from the public internet if you're on an older version, verify that you have full control, verify that it has no rogue configurations or compromise, and then upgrade. Anything else leaves you open.

If you can't guarantee that your server is clean of any backdoors or other malicious file implants, then you need to re-provision a fresh server and migrate data over - but ONLY after verifying that the configurations aren't compromised as well for things like rogue volume mount commands that will literally re-execute once the new server comes up...

MailEnable survivor / convert --

Rod Strumbel Replied

1/28/2026 at 9:06 AM

Seems to me if this is truly the case (having to completely rebuild a server), the onus is on SmarterMail to be reconstructing and patching servers for their customers.

DRKZA Replied

1/28/2026 at 9:46 AM

@Montague WebWorks, is this for version 9511?

N

Nico Smit Replied

1/28/2026 at 10:07 AM

I was on 9504 and coulnd't login and upgraded to latest version but now see the error below. Any tips/ideas what to do?

The server is not responding or cannot be reached. Please try again later. If the problem continues, please check your internet connection or contact your system administrator for assistance.

Error 502.3

T

T Mulder Replied

1/28/2026 at 12:39 PM

We are having the same issue. Smartertools support ticket opened yesterday......but barely response or actions taken by SM . We pay over € 2800 yearly, and we get software that has serious issues.

N

Nico Smit Replied

1/28/2026 at 1:04 PM

I’ve contacted smartermail support and they fixed it very quickly fortunately. Good luck!

T

T Mulder Replied

1/28/2026 at 1:09 PM

Can you also tell how it got solved?

Montague WebWorks Replied

1/28/2026 at 1:21 PM

@DRKZA, yes. Pretty sure we are on 9511. Can't tell right now, obviously. We're working to bring it back up.

BTW, no official word or post from ST on this episode? Do we know how many servers were taken out?

Mik MullerMontague WebWorks

N

Nico Smit Replied

1/28/2026 at 2:38 PM

@T Mulder: no, they didn't tell me to be honest. Already glad they sorted that out. I've asked if the can update this forum.

Tony Scholz Replied

1/28/2026 at 3:15 PM

Employee Post

Hello Nico,

Here is what I did to resolve your issue.

After I accessed the server, I uninstalled SmarterMail.
Once this was done, I reviewed your administrators.json file to try and find the date the issue started.
Once I knew this, I went to the Archived Data folder and (system level) and extracted the oldest zip in there. It was from the day before the first issue showed up for you.
Next, I created a new folder ({date}.bad.jsons) and moved all of the json/sbin/txt files in the settings folder into the new folder.
Copied out all of the JSONs from the zip and pasted them into the settings folder.
Installed SmarterMail again (Build 9518).

Some installs are seeing issues with trying to install where it is saying that the user does not have permissions to start the service. This is most likely due to a pending reboot. Reboot your server and run the installer again. You should be good to go.

If you find that the issue started prior to the oldest "Archived Data" zip file, you will want to grab one from your local backups.

Hope this helps.

Tony

Tony Scholz Lead Network/System Administrator SmarterTools Inc. www.smartertools.com

Gabriele Maoret - SERSIS Replied

1/28/2026 at 4:22 PM

Marked As Resolution

A big warning to all of you: upgrade to v. 9518 NOW.

If you're using an older version and experiencing problems, don't complain: it's your fault.

YOU MUST UPDATE TO THE LATEST VERSION.

PERIOD.

P.S.:

We closely monitored all advisories and CVEs and updated IMMEDIATELY to protect ourselves.

We usually wait a bit to avoid bugs, but in this case, given the danger, we didn't even wait 10 minutes after each release.

And so we avoided ALL problems (thank God!!!)

In the event of serious vulnerability issues, updates must be applied IMMEDIATELY!

Gabriele Maoret - Head of SysAdmins and CISO at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)

Ben Rowland Replied

1/29/2026 at 8:45 PM

I found rogue .aspx and modified json settings files on my servers this morning. My Linux servers crash pretty regularly due to the oom killer but this morning the restart of the service failed. Evidently the ha-settings.json file had been added which fooled the SM service and it refused to start.

Yes upgrade immediately, but if you haven’t, you may have already been compromised and you should check the server carefully for evidence of an attack.

My advice to ST: please push outbound tickets to all customers with the server running (even if out of license) to inform them of the seriousness of this. We all know this stuff happens. The problem is that many of us get to a stable install and then wait for community feedback before upgrading to these new versions. This has helped me avoid lots of pain in the past, but I sure got burned this morning.

I was not able to contact ST through the website this morning while this was happening so want to extend my sincere appreciation to the ST employee who helped me via LinkedIn messaging.

t

terry fairbrother Replied

1/30/2026 at 1:51 AM

"I found rogue .aspx and modified json settings files on my servers this morning"

I'm a Linux noob having resisted using it for the last 30 or so years, but i'm going with Ubuntu with my own and a clients ST mail server, so it's been a sharp learning curve. So would you mind letting me know where I might find these rogue files (if i'm compromised?) Thanks

Ben Rowland Replied

1/30/2026 at 6:57 AM

Yes, I found them in /etc/smartermail

Here are the files/dates:

admin@SM-Linux:/etc/smartermail$ ls *.aspx -l
-rw-r--r-- 1 root root 28 Jan 29 07:13 1cxwko_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 2pd6f5_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:22 4vjwqm_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 5xkd5k_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:20 7hfm2l_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:23 9tdcpm_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:14 aapwzs_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:21 fhcknl_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:12 flrk8u_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:21 hfitxm_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:14 izn3lx_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:37 lrc9to_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 n0ennu_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 nk30qx_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 oakmy9_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:24 qtoaei_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:20 tghexf_0.aspx
-rw-r--r-- 1 root root 1403 Jan 10 17:59 ttanlo0q.aspx_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:22 tvwkua_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:22 us9ume_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:13 wo2zpk_0.aspx
-rw-r--r-- 1 root root 28 Jan 24 13:24 yb1jwh_0.aspx
-rw-r--r-- 1 root root 28 Jan 29 07:16 yyo0xy_0.aspx

I also found ha-settings.json but in the /etc directory.

-rw-r--r-- 1 root root 194 Jan 29 03:16 ha-settings.json

Here are the modified contents of ha-settings.json (I don't use HA):

Here are the contents of the largest of the .aspx files:

On a linux server, this won't succeed in launching the Windows command line cmd.exe.

104 Replies

Reply to Thread