CVE - Mitigation Options
Problem reported by kevind - 1/11/2026 at 8:20 PM
Submitted
Saw on a website regarding this particular CVE, it recommended:
  • Disable file upload functionality if not actively used.
  • Implement WAF rules to block suspicious file uploads
Our users never need to send attachments, upload files, or use the File Storage area. Is there a way to disable upload functionality on older builds? Thanks.
kevind Replied
What if you create a firewall rule that only allows trusted IPs to access the server using a browser. Anyone outside the organization would not be able to access webmail via browser. Does this help mitigate this vulnerability?

Just trying to identify steps to block these attacks on older builds until they can be upgraded.
kevind Replied
@Reto, OK, thanks for the reply!
J. LaDow Replied
@kevind sent a DM not sure if you got it.
MailEnable survivor / convert --
kevind Replied
@J., yes got it. Will check out your suggestions.

Thanks!
JohnC Replied
"Disable file upload functionality if not actively used."

How is this done (where is this setting)?
JohnC Replied
I am a single-user system, so would restricting access to the smwebmail IIS site (by IP or network) fully mitigate this vulnerability? (because that solution would be perfectly acceptable for my use case).
Winston Tsai Replied
Easy mitigation

1/ Open a free cloudflare account

2/ Import your webmail / smartermail domain under cloudflare

3/ Activate the cloudflare proxy for your smartermail

4/ Add security rules to block access to vulnerable endpoints

It takes 5 minutes and fix the problem definitively.
John Quest Replied
Easy mitigation

If things were so easy, the war on bad actors would be over by now.
George To Replied
Easy mitigation
As you shall open DNS MX record to receive emails, others will know your MX mail server IP accordingly.
Winston Tsai Replied
As you shall open DNS MX record to receive emails, others will know your MX mail server IP accordingly.

If you use the same IP for the Webmail and the smtp/pop that will be the case
But you should not use the same IP for both services as it is (another) bad security practice

So what I suggest would work.
Richard Laliberte Replied
@Winston

My understanding was that Smartermail (at least on windows servers) doesn't support passed headers, and thus only detects the Cloudflare IP addresses, thus making region blocking and IP blocking much more difficult? unless Smartermail made an upgrade so that CF-Connecting-IP can be read i don't know if this is a viable option. 

Although i do agree with separating webmail from the rest of the protocols.
Winston Tsai Replied
@richard 

SmarterMail does not support X-Requested-For ?

You can easily transform CF-Connecting-IP to X-Requested-For with a CF transform rule.
Richard Laliberte Replied
From what i understood, Smartermail doesn't support CF-Connecting-IP, X-Requested-For or X-Forwarded-For, unless something changed at some point. The logs will record these values, but any smartermail functions that work via IP address like blocking, will end up blocking the Cloudflare IP addresses, thus blocking everyone?

like i said, unless something has changed?
Winston Tsai Replied
You can region & IP block with CloudFlare instead of SmarterTools. It will more secure as we can imagine how ST is doing region blocking...

Regarding the number of critical bugs found in ST and what it shows of their underlying security QC, putting the webmail behind CloudFlare is in my opinion something that you can't avoid...
Richard Laliberte Replied
or we can ask SmarterTools to add support for those headers?

J. LaDow Replied
That they are "not" supported by an interface that is literally built around an internal proxy configuration makes no sense.
MailEnable survivor / convert --
Logan Price Replied
Employee Post
Hello,

Replace your <rewrite> block in MRS/web.config with this to block the known vulnerable force-reset-password and upload endpoints. Please note that this will break uploading files + resetting passwords.


        <rewrite>
            <rules>
                      <rule name="Block upload endpoint" stopProcessing="true">
                          <match url="^api/upload$" ignoreCase="true" negate="false" />
                          <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Blocked" />
                      </rule>
                      <rule name="Block force-reset-password endpoint" stopProcessing="true">
                          <match url="^api/v1/auth/force-reset-password$" ignoreCase="true" />
                          <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Blocked" />
                       </rule>
                <rule name="HttpReverseProxyInboundRule" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="on" negate="true" />
                        <add input="{REQUEST_URI}" pattern="^/proxy-error-502\.3\.html" negate="true" />
                        <add input="{REQUEST_URI}" pattern="^/proxy-error-502\.4\.html" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="http://localhost:17017/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_Forwarded_Host" value="{HTTP_HOST}" />
                        <set name="HTTP_X_Forwarded_Proto" value="http" />
                    </serverVariables>
                </rule>
                <rule name="HttpsReverseProxyInboundRule" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="on" />
                        <add input="{REQUEST_URI}" pattern="^/proxy-error-502\.3\.html" negate="true" />
                        <add input="{REQUEST_URI}" pattern="^/proxy-error-502\.4\.html" negate="true" />
                    </conditions>
                    <action type="Rewrite" url="http://localhost:17017/{R:1}" />
                    <serverVariables>
                        <set name="HTTP_X_Forwarded_Host" value="{HTTP_HOST}" />
                        <set name="HTTP_X_Forwarded_Proto" value="https" />
                    </serverVariables>
                </rule>
               </rules>
        </rewrite>
Logan Price System/Network Administrator SmarterTools Inc. www.smartertools.com
terry fairbrother Replied
Does this apply to the Linux version and if so, how to add it? I know IIS, but have no idea about the Linux version of IIS or even where it is (new to linux and SM)
J. LaDow Replied
web.config is still leveraged by the Kestrel web server that .NET Core uses on Linux. The web.config in question will reside in the MRS sub-directory of the main smartermail directory.

On Linux, use find while in your root directory /

find . -name web.config
works on Debian based Linuxes - some adjustments may be necessary depending on your distribution.

MailEnable survivor / convert --
Marc Frega Replied
Would and should web.config only reside in the MRS subdir on windows?

J. LaDow Replied
It is my understanding that the web.config that the webmail interface uses is the one located in the MRS sub-directory inside the main smartermail directory. 

On any .NET based application, web.config or app.config (if not a web application) controls the behavior. IIS and Kestrel read the web.config for directives like the URL rewrite settings (among others). 

On Windows, you may find multiple web.config files throughout the server - but the one referenced in this thread relates to the one inside the MRS directory.

MailEnable survivor / convert --

Reply to Thread

Enter the verification text