Can someone running SM take a look at something for me.

Problem reported by Dave - 2/16/2026 at 4:00 PM

Submitted

Can you check your administrative logs for the text

Connecting to hub

Search from mid Jan to now.

I started seeing it on a bunch of my machines and when I opened a ticket and asked it went from no big deal to check for compromise.

Having a bit of a freakout right now.

I see these

[2026.02.02] 07:09:53.551 [64.111.92.34] Connecting to hub
[2026.02.02] 07:13:23.263 [85.215.228.53] Connecting to hub
[2026.02.02] 07:48:25.208 [64.111.92.34] Connecting to hub
[2026.02.02] 07:51:43.779 [64.111.92.34] Connecting to hub
[2026.02.02] 07:54:41.280 [64.111.92.34] Connecting to hub
[2026.02.02] 07:55:38.888 [85.215.228.53] Connecting to hub
[2026.02.02] 07:58:54.654 [85.215.228.53] Connecting to hub
[2026.02.02] 08:00:36.780 [64.111.92.34] Connecting to hub
[2026.02.02] 08:02:15.251 [85.215.228.53] Connecting to hub
[2026.02.02] 08:09:03.221 [85.215.228.53] Connecting to hub
[2026.02.02] 08:12:15.502 [64.111.92.34] Connecting to hub
[2026.02.02] 08:13:10.337 [64.111.92.34] Connecting to hub
[2026.02.02] 08:20:31.582 [85.215.228.53] Connecting to hub
[2026.02.02] 08:21:25.993 [85.215.228.53] Connecting to hub
[2026.02.02] 08:24:52.751 [64.111.92.34] Connecting to hub
[2026.02.02] 08:33:46.142 [85.215.228.53] Connecting to hub
[2026.02.02] 08:57:56.375 [64.111.92.34] Connecting to hub

20 Replies

Reply to Thread

J. LaDow Replied

2/16/2026 at 4:04 PM

We have nothing of that in our logs - running build 9526 - went back 10 days.

What build are you on?

I would also say check for compromise, but first, I would block those IPs at your edge...

MailEnable survivor / convert --

Dave Replied

2/16/2026 at 4:05 PM

9540

Crap it's showing in all our machines.

Sébastien Riccio Replied

2/16/2026 at 4:12 PM

I also have plenty of these...

[2026.02.13] 23:41:32.558 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:32.731 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:33.412 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:37.000 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:37.342 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:37.720 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:42.538 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:43.885 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:44.093 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:45.591 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:46.013 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:46.962 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:47.210 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:47.277 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:47.476 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:48.134 [167.71.200.26] Connecting to hub
[2026.02.13] 23:41:48.203 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:54.922 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:55.980 [157.245.156.118] Connecting to hub
[2026.02.13] 23:41:59.242 [167.71.200.26] Connecting to hub
[2026.02.13] 23:42:05.970 [157.245.156.118] Connecting to hub
[2026.02.13] 23:42:15.026 [157.245.156.118] Connecting to hub

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

J. LaDow Replied

2/16/2026 at 4:16 PM

The IP 85.215.228.53 has another SmarterMail server at the other end according to Shodan. No idea whether or not it's malicious - but somewhere in the exploits there was information relating to the attackers making changes to SM's HA configurations somehow -

The other IP doesn't show much.

MailEnable survivor / convert --

Sébastien Riccio Replied

2/16/2026 at 4:17 PM

It comes from the same IPs that triggered the "User @ failed force-reset-password" messages too.

Maybe they are only meaning attempts are made, but not that they succeed. I have no idea.

We don't even have a HA / hub configuration...

[2026.02.13] 12:46:36.879 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:37.604 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:42.273 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:45.606 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:49.169 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:51.087 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:52.167 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:52.323 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:56.063 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:58.470 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 12:46:58.515 [167.71.200.26] User @ failed force-reset-password
[2026.02.13] 22:49:03.082 [167.71.200.26] Connecting to hub
[2026.02.13] 22:49:38.674 [167.71.200.26] Connecting to hub
[2026.02.13] 22:49:48.847 [167.71.200.26] Connecting to hub
[2026.02.13] 22:49:52.357 [167.71.200.26] Connecting to hub
[2026.02.13] 22:49:58.574 [167.71.200.26] Connecting to hub
[2026.02.13] 22:49:58.833 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:09.054 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:10.353 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:13.327 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:17.694 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:20.217 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:37.493 [167.71.200.26] Connecting to hub
[2026.02.13] 22:50:37.808 [167.71.200.26] Connecting to hub

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

J. LaDow Replied

2/16/2026 at 4:20 PM

Our IDS firewalled the 167.71.200.26 IP a while ago when the password reset vulnerability was exposed.

The other three in this thread haven't been seen in our logs (yet).

[edit] - 157.245.156.118 last appears 3 days ago trying to reset passwords.

[note to self] seems our IDS trigger needs to be updated to the new log entry.

MailEnable survivor / convert --

Sébastien Riccio Replied

2/16/2026 at 4:21 PM

I can find an ha-settings.json on our server though containing:

{
  "ClusterId": "some-uuid-string",
  "SharedSecret": "something",
  "TargetHubs": {}
}

No idea if it's normal on a non-clustered SmarterMail host.

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

Sébastien Riccio Replied

2/16/2026 at 4:25 PM

Those "Connecting to hub" seems attempts related to this exploit:
https://www.vulncheck.com/blog/smartermail-connecttohub-rce-cve-2026-24423

If I understand correctly, if you have no "Volume mounts" configured with some hostile command lines, you are not compromised.

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

J. LaDow Replied

2/16/2026 at 4:27 PM

Could be some benign logging like when we were seeing the incorrect log entry after the force-reset-password bug was fixed. The build that fixed it had a bad log entry - but the next version at least added the word "failed" --

I would still scan everything, check auto-runs, event-viewer logs, look for new files (this might take a couple scans because some of the attacks were leveraging "delays" between initial breakin/compromise and attack/pwn of the server)...

MailEnable survivor / convert --

Dave Replied

2/16/2026 at 5:01 PM

It does not matter if the server has the ha-settings.json file or not.

The logs had the same connecting to hub in them.

Not all of our servers had that ha-settings.json but they all had the connecting to hub.

Sabatino Replied

2/16/2026 at 7:01 PM

I also have several in the logs. My server wasn't compromised. They managed to change the password, but I had IP restrictions, so I never had any follow-up or successful logins.

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

J. LaDow Replied

2/17/2026 at 3:32 AM

If I understand correctly, if you have no "Volume mounts" configured with some hostile command lines, you are not compromised.

One of the concerns (and I'm sure part of why there is now a "scripts" folder that requires a separate "execution file" defined in the filesystem, instead of just being able to define shell level commands directly from the interface) - is that there were several locations in SM that could have arbitrary commands changed - from external virus scanners, to spam checks, volume mounts, events, etc.

Leveraging any of those to insert something into say Windows Scheduled Tasks or a Linux cron job - or even a one-time event that registered a startup task that now launches some random unknown DLL in the rundll32 context - but the command and evidence was removed from the SM install to cover the attacker's tracks - a "hit and run" attack. So there wouldn't be any current evidence - you'd have to scour the logfiles going back to when the initial breakin happened to see if any changes were made.

Then there's some random unknown thing that has been "planted" -- and the challenge is to find it before it moves to a higher stage in the attack.

MailEnable survivor / convert --

Brian Bjerring-Jensen - VonBjerring GmbH Replied

2/17/2026 at 4:44 AM

[2026.02.03] 10:40:57.757 [64.111.92.34] Connecting to hub
[2026.02.05] 13:19:38.693 [162.252.198.215] Connecting to hub
[2026.02.05] 13:19:38.772 [162.252.198.215] Connecting to hub
[2026.02.06] 12:44:25.649 [64.111.93.253] Connecting to hub
[2026.02.06] 12:53:05.006 [199.217.99.119] Connecting to hub

Only 5 in all going back to the same serverfarm in Holland.

Andrew Barker Replied

2/17/2026 at 7:09 AM

Employee Post

If you are running a non-HA environment and find an ha-settings.json file, go ahead and delete it. That file is only used in HA configurations, and if it is present it will cause the "Connecting to hub" log entries. This is most likely the result of the vulnerability that Sébastien mentioned, which was patched in build 9511.

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

Dave Replied

2/17/2026 at 8:24 AM

Andrew, replied to my ticket a few hours ago and just added another comment to it.

Looks like it's not the vulnerability causing this.

Take a look at ticket 28D-31248FB9-0050

Zach Sylvester Replied

2/17/2026 at 1:12 PM

Employee Post

Hey guys,

This log alone is anoying but harmless. I will create a task for us to see if we can resolve this.

Kind Regards,

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

Dave Replied

2/17/2026 at 1:17 PM

Zach, did you read the updates I put in the ticket?

Zach Sylvester Replied

2/17/2026 at 1:24 PM

Employee Post

Hey Dave,

This logging issue isn't related to what you're seeing. This logging happens before we return a bad request because the server isnt in setup mode.

I will chat with support about your issue.

Kind Regards,

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

Dave Replied

2/17/2026 at 4:46 PM

Zach, what would we see (or should be looking for) if the request was successful?

Thanks,

Dave

Zach Sylvester Replied

2/17/2026 at 7:30 PM

Employee Post

Hey Dave,

This request is used to connect a server to a hub on the local network. There is a check in place to ensure SmarterMail is in setup mode before allowing this action. If SmarterMail is not in setup mode, the request will return a bad request response and no changes will be made.

The only impact of a successful request would be setting the server as a node. It would still need to connect to a hub on the local network, and the request verifies that the connection is local.

If it were somehow completed successfully, SmarterMail would stop functioning and the service would stop, as it would begin looking for its settings and domains on a shared or mounted location that does not exist in a standalone configuration. Additionally, without a High Availability license, it would not be allowed to operate in that mode.

Kind regards,

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

Back to Community Threads

Please leave this box unchecked

Reply to Thread

Enter the verification text