Looking at the SmarterMail API Vulnerability CVE-2026-24423

The Sensor Intel Series is created in partnership with Efflux, who maintains a globally distributed network of sensors from which we derive attack telemetry.

Introduction

The F5 Labs Sensor Intel Series provides an in-depth analysis of the most significant vulnerabilities and their exploitation trends. This article highlights the top 10 CVEs, their activity levels, and their potential impact on organizations. By examining long-term trends and recent activity, this report aims to inform security professionals about emerging threats and provide actionable insights for mitigating risks.

Trending CVEs for February 2026

CVE-2017-9841, a PHPUnit Remote Code Execution vulnerability, remains the most exploited CVE. This vulnerability allows attackers to execute arbitrary code on vulnerable servers. Organizations using PHPUnit should ensure they are running the latest patched versions and consider implementing web application firewalls to mitigate exploitation attempts.

CVE-2025-55182, a React Server Components Unsafe Deserialization vulnerability, has seen a significant rise in exploitation. This critical vulnerability allows remote code execution through unsafe deserialization. Developers should update to the latest secure versions of React and review their deserialization practices to prevent exploitation.

CVE-2024-4577, an Apache PHP-CGI Argument Injection vulnerability, has climbed in the rankings. This vulnerability enables attackers to inject malicious arguments into PHP-CGI scripts. Administrators should apply the latest patches and consider disabling PHP-CGI if not required.

CVE-2019-9082, a ThinkPHP PHP Injection vulnerability, continues to be exploited. This vulnerability allows attackers to execute arbitrary PHP code. Organizations using ThinkPHP should update to the latest versions and monitor their systems for signs of compromise.

CVE-2022-47945, a ThinkPHP Lang Parameter Local File Inclusion vulnerability, has entered the top five. This vulnerability allows attackers to include local files, potentially leading to code execution. Administrators should apply patches and restrict access to sensitive files to mitigate this risk.

SmarterMail CVE-2026-24423

SmarterTools SmarterMail, according to its documentation, “is an award-winning email, groupware, collaboration, and group chat server that easily meets the needs of any sized business, from the individual proprietor to large corporations and enterprise organizations.”

SmarterMail has about 30,000 instances appearing in shodan.io,¹ with the majority in the USA followed distantly by Malaysia, although since this vulnerability has been known for some time, it’s likely that at least some of those are honeypots.

SmarterMail supports the configuration of “hubs” (essentially routers for messages) and “nodes” (places to store mailboxes), allowing for a highly available, clustered use case.

It also has an extensive web API, allowing for remote configuration and administration.

Sometime before late January of 2026, researcher Cale Black from VulnCheck discovered a critical vulnerability in this application, leading to remote code execution. The vulnerability was also independently found by Sina Kheirkhah & Piotr Bazydlo of watchTowr, and Markus Wulftange of CODE WHITE GmbH.²

CVE-2026-24423 is a CVSSv3.1 9.8 (Critical) remote code execution vulnerability. It allows attackers to run shell commands and to create and write files. SmarterTools released a patch for the vulnerability on January 15th, 2026, in build 9511. VulnCheck filed the CVE request on January 22^nd, and NVD published it the next day.

CISA has added CVE-2026-24423 to its Known Exploited Vulnerabilities (KEV) database,³ and notes that it has been used in ransomware campaigns, further classifying it as falling under CWE-306 - Missing Authentication for Critical Function vulnerability. It was added to the KEV on February 2^nd, 2026, and the “due date” for US government entities to patch set to February 26^th, 2026.

The Exploit

The precise method for exploitation is a POST request to the API endpoint ‘/api/v1/settings/sysadmin/connect-to-hub’, containing a POST body containing a JSON string that looks roughly like this:

{"hubAddress": "http://<remote address>",

"oneTimePassword": "<some string>",

"nodeName": "<some node name>"}

This request can be made with no authentication.

The function of this API is to contact a “hub” (specified in the ‘hubAddress’ parameter) and then parse the response from that hub, to determine how the servers should mount resources from that hub.

This would normally allow for a sort of autoconfiguration. Unfortunately, very limited validation is done on the response from the hub, and the hub address is arbitrary.

This leads to the situation where an attacker can make an unauthenticated request to this API endpoint and specify as the hub a server that they control, which can then send a response with malicious values back to the API server, which eventually results in attacker-controlled data being used in a shell command.

The VulnCheck writeup shows this in detail.⁴ In their exploitation example, the CommandMount parameter in the attacker-controlled JSON object is set to “dir > c:\\pwn”, creating a file at the Windows C drive root, called “pwn”, that will contain the contents of the Windows “dir” command.

This vulnerability appears to allow any shell command to be run. This could easily be weaponized to pull down and run a stager for further malware, modify files that the API server process has access to, trigger information disclosure; really anything that can be accomplished with the command line.

Step By Step

The process of attacking with this vulnerability is:

1. Establish a web server on the public internet that will accept a request and return a specific JSON object. This is easily done – perhaps just with a small python script.
2. Identify vulnerable servers, or alternately, simply scan the entire internet for web servers that accept POST requests at the API path ‘/api/v1/settings/sysadmin/connect-to-hub’.
3. Send a POST request with a specific JSON object that specifies the hubAddress pointing to your server.
4. Your fake hub replies with a properly formatted response, which contains the command you want to have run
5. Your code runs, and the exploit is achieved.

Observed Attacks

Once a researcher discovers a serious vulnerability and publishes a detailed write-up after coordinating disclosure with the vendor, the path to attacker exploitation is typically short. One has all the details needed to reproduce the issue and weaponize it. In this case, the disclosure date was the date of the writeup being published – January 26^th, 2026.

There is usually at least a short delay between publication and active exploits being observed. Quite frequently, we see many IPs attempting to run whatever PoCs have been published already, to greater or lesser effect.

In this case, and quite interestingly, we saw just one IP conducting any activity related to this CVE. This IP is 193.24.123.58,⁵ one owned by ASN 200593, a block used by a Russian Federation ISP called Prospero OOO, based out of St. Petersberg.

Even more interesting, given the sort of multi-vulnerability scanning we typically observe, this IP was only scanning URLs associated with this vulnerability, and nothing else.

The first instance occurred on February 17^th, 2026. The last observed event was on February 22^nd, 2026, when the IP suddenly went quiet, only to return on March 4^th, 2026, but scanning for a completely different issue – scanning for credential files associated with CVE-2026-20128, a vulnerability in Cisco Catalyst SD-WAN Manager.

At first the following URL was requested, using a variety of Mozilla User-Agent strings.

• GET /interface/app/authentication/login.html – this URL is associated with SmarterMail, and may be serving as a check to see if the target is running the required software.

This continued until February 20^th, 2026, when the pattern changed. This time, the URL requested was used for an exploitation attempt. In this case, the User-Agent was the standard one for a recent version of the python requests library.

• POST /api/v1/settings/sysadmin/connect-to-hub – the specific API endpoint for the vulnerability. This POST also contained a JSON object in the expected format.

This continued until February 22^nd, 2026.

We believe that this pattern is consistent with attempting to find vulnerable endpoints and then, having identified them, exploit them.

The change in User-Agent strings may indicate that two different tools were used for each phase.

The Payload

The attacker used the same server at 193.24.123.58 to host the “hub” which would deliver the JSON payload but changed the port number used periodically. We observed the following ports being used:

• 17325, 17625, 17775, 18625, 18725, 18775

Given the periodic incrementing by 50 (or perhaps 25) this appears to be an automated process, likely attempting to prevent overly precise signature matching from blocking the requests, or used to inhibit analysis.

The big unknown is the exact contents of the response from the attacker-controlled server. We can at least draw from the POST request the address being used to send the payload, but unfortunately, it appears that this address is unresponsive. This may be due to geofencing, or more likely, that the “server” was only present when the scanning and exploitation attempts were active.

Summary

We found it odd that only one IP was observed conducting activity against this CVE – usually with a well-documented, critical vulnerability, exploits are quickly integrated into scanning kits, especially one that is so well documented and easy to exploit.

The activity of this IP was also unusual in that it appears to search for one vulnerability, then pause for a few days, and then target another. This stands in marked contrast to most of the scanning behavior we observe, where scanning IPs will look for dozens of vulnerabilities, or scan 100s of file types for information disclosure.

Defenses and Mitigations

For this sort of web-based, API-based vulnerability, the main line of defense is first preventing access to the API from unauthorized sources. This can be accomplished using a WAF, and an allow-list of whatever web URIs you must provide to unauthorized sources and blocking the rest.

Additional protections would include monitoring, and even blocking, requests from an API server to arbitrary endpoints on the internet. In this specific case, outbound filtering would have prevented the API from contacting the attacker controlled hub server and stopped the attack in its tracks.

Finally, and obviously, maintaining good hygiene, monitoring for vendor updates, and patching quickly when updates are available remain perhaps the most important defense.

Top CVEs for February

In February 2026, CVE-2017-9841 saw over 85,000 exploit attempts, maintaining its dominance as the most exploited vulnerability (see Table 1). CVE-2025-55182 followed with over 22,000 attempts, reflecting its critical severity. CVE-2024-4577 and CVE-2019-9082 exhibited moderate activity, while CVE-2022-47945 entered the top five with over 2,200 attempts. Notably, CVE-2023-1389 dropped to the tenth position, indicating a decline in exploitation attempts. These statistics highlight the evolving focus of threat actors.

Table 1: Top 10 CVEs for February 2026. CVSS scores are v3.1. All data is as of March 1^st, 2026.

Long Term Targeting Trends

The bump plot for February 2026 (see Figure 1) reveals that CVE-2017-9841 continues to dominate as the most exploited vulnerability, with a significant increase in activity compared to the previous month. CVE-2025-55182 maintains its position as the second most exploited CVE, with a notable rise in exploit attempts. CVE-2024-4577 has overtaken CVE-2019-9082 to claim the third spot, while CVE-2022-47945 has entered the top five, reflecting its growing exploitation. These shifts underscore the dynamic nature of threat actor priorities.

Figure 1: Twelve-month bump plot of the top 5 CVEs.

The long-term trends data for February 2026 (see Figure 2) shows a consistent increase in activity for CVE-2017-9841, which remains the most exploited vulnerability. CVE-2025-55182 has also shown a steady rise since its emergence, reflecting its critical nature. CVE-2024-4577 and CVE-2019-9082 exhibit moderate but consistent activity, indicating ongoing exploitation attempts. CVE-2022-47945 has seen a slight increase, suggesting renewed interest in this vulnerability. These trends highlight the need for continued vigilance and patching efforts for these vulnerabilities.

Figure 2: Evolution of vulnerability targeting in the last twelve months, shown using a logarithmic scale for ease of comparison.

Conclusion

The data for February 2026 underscores the importance of proactive vulnerability management. CVE-2017-9841 and CVE-2025-55182 remain critical threats, while the rise of CVE-2024-4577 and CVE-2022-47945 highlights the evolving tactics of threat actors. Organizations must stay vigilant, apply patches promptly, and implement robust security measures to mitigate these risks.