Mail2Shell: The Zero-Click Exploit That Turns FreeScout Help Desks Into Attack Weapons

A single email. No clicks. No login. No user interaction at all. That is all it takes for an attacker to gain full remote code execution on a FreeScout help desk server, thanks to a critical vulnerability researchers have named Mail2Shell. Tracked as CVE-2026-28289 and carrying a maximum CVSS score of 10.0, this flaw represents one of the more elegant and dangerous attack chains disclosed so far in 2026 — and it was born from an incomplete patch that was supposed to fix the problem in the first place.

The Mail2Shell vulnerability was discovered by researchers at OX Security, an application security company that specializes in securing software from code to runtime. Their findings highlight a truth that security teams know well but too often learn the hard way: shipping a patch does not mean shipping a fix. Within days of FreeScout releasing a security update for an earlier authenticated RCE vulnerability, OX Security researchers had not only bypassed the patch but escalated the attack from requiring a logged-in user to requiring nothing more than an inbound email.

What Is FreeScout and Why Does This Matter

FreeScout is a free, open-source help desk and shared mailbox platform built on PHP's Laravel framework. It positions itself as a self-hosted alternative to commercial platforms like Zendesk and Help Scout, offering organizations the ability to manage customer support tickets and team inboxes without per-agent subscription fees or third-party data hosting. The project has accumulated over 4,000 stars on GitHub, supports more than 25 languages, and has no limitations on the number of users, tickets, or mailboxes — making it a popular choice for small and medium-sized businesses, IT departments, and organizations that prioritize data sovereignty.

Because FreeScout is self-hosted, organizations deploy it on their own Apache or Nginx web servers, often on cloud VPS instances, shared hosting, or on-premises infrastructure. This self-hosted nature is central to both its appeal and its risk profile. When a critical vulnerability is disclosed, there is no vendor-managed update that rolls out silently overnight. Every administrator running FreeScout is individually responsible for applying patches, and the reality is that many do not do so quickly.

One scoping point matters here: Mail2Shell and the underlying CVE-2026-27636 chain are specific to Apache deployments. The attack depends entirely on Apache's .htaccess mechanism, which does not exist in Nginx. FreeScout instances running on Nginx are not affected by this specific exploit chain, though they are still subject to the CVE-2026-27637 token takeover flaw, which is web server agnostic. Administrators should confirm which server they are running before assessing their exposure level.

The platform's core function — receiving and processing inbound email from customers — makes it an especially attractive target. Help desk systems are, by design, intended to receive unsolicited messages from the outside world. Any vulnerability that can be triggered by an incoming email effectively turns a standard business communication channel into an attack vector.

The Original Flaw: CVE-2026-27636

To understand Mail2Shell, it is necessary to start with the vulnerability it bypasses. CVE-2026-27636 was disclosed on February 25, 2026, and carried a CVSS score of 8.8 (High). The flaw was originally reported by Offensive.sa and arose from an oversight in FreeScout's file upload restriction list, located in the app/Misc/Helper.php file. The restriction list was designed to prevent users from uploading dangerous file types, but it failed to include .htaccess and .user.ini files. This vulnerability is classified under CWE-434: Unrestricted Upload of File with Dangerous Type.

On Apache web servers configured with AllowOverride All — which is a common default configuration — a .htaccess file placed in a web-accessible directory can override the server's runtime configuration for that directory. This means an attacker who can upload a .htaccess file can redefine how the server processes other files in that same directory.

The exploitation chain for CVE-2026-27636 worked as follows. An authenticated FreeScout user could compose a new email in the web UI and attach files to it. Critically, FreeScout writes attachments to the filesystem immediately upon upload, even before the email is actually sent. An attacker would upload two files: a malicious .htaccess file configured to treat .txt files as executable PHP, and a webshell.txt file containing PHP code that accepts and executes system commands via a URL parameter. Once both files were uploaded, the attacker could navigate to the webshell URL and execute arbitrary commands on the server.

FreeScout patched CVE-2026-27636 in version 1.8.206, released on February 25, 2026. The fix added .htaccess and .user.ini to the upload blacklist and implemented additional logic in the sanitizeUploadedFileName() function: any filename that started with a dot character would have an underscore appended to neutralize it. On paper, this appeared to close the door. In practice, the door was still wide open.

How the Patch Was Bypassed

OX Security researchers examined the patch for CVE-2026-27636 within days of its release and identified a critical flaw in its logic. The vulnerability exists in the sanitizeUploadedFileName() function in app/Http/Helper.php, and it is classified as a Time-of-Check to Time-of-Use (TOCTOU) ordering flaw.

The function performs its security checks in a specific order. First, on line 1913 of the source code, it checks whether the filename begins with a dot character. If the filename starts with a dot, the function appends an underscore to neutralize the file. Later in the processing pipeline, around line 1957, the function runs a regular expression that strips invisible Unicode characters from the filename, including characters in the \p{Cf} Unicode category (format characters).

The problem is the order of operations. The dot-prefix check happens before the invisible character sanitization. This creates a window of exploitation.

An attacker can prepend a zero-width space character (Unicode U+200B, encoded as the UTF-8 byte sequence E2 80 8B) to the beginning of the filename .htaccess. When the function checks whether the filename starts with a dot, it sees the zero-width space character first, not the dot. The check passes, and no underscore is appended. Later, the sanitization step strips the invisible zero-width space character, and the file is saved to disk with its original, dangerous name: .htaccess.

PHP — Vulnerable
// Vulnerable code flow in sanitizeUploadedFileName()

// Line 1913: CHECK happens FIRST
if (mb_substr($file_name, 0, 1) == '.') {
    $file_name = $file_name.'_';  // Append underscore to neutralize
}

// ... other processing ...

// Line 1957: SANITIZATION happens AFTER
// Regex strips invisible Unicode characters (\p{Cf}), including U+200B
// Result: zero-width space is removed, leaving ".htaccess" on disk

This is a textbook TOCTOU vulnerability. The security decision is made based on the state of the data at one point in time (with the zero-width space present), but the data is subsequently modified (the zero-width space is removed), and the security decision is never re-evaluated against the modified data. The fix should have performed the dot-prefix check after all sanitization was complete, or it should have re-validated the filename at the end of the processing pipeline.

From Authenticated RCE to Zero-Click Takeover

The TOCTOU bypass alone was significant, but OX Security did not stop there. During their analysis, they discovered that the entire attack chain could be escalated from an authenticated exploit to a fully unauthenticated, zero-click remote code execution.

The key insight was that FreeScout, as a help desk platform, is designed to receive incoming email and store attachments. When FreeScout fetches email from a configured mailbox, it automatically saves any attachments to the server's filesystem in a predictable directory path: /storage/attachment/.... The attachments are stored as-is, meaning the zero-width space filename trick works just as effectively through email delivery as it does through the web UI.

This means an attacker does not need any account, any credentials, or any user interaction. They simply send a crafted email to any address that FreeScout is configured to monitor. The email contains two attachments: a .htaccess file (with the zero-width space prefix) and a PHP webshell disguised as a text file. When FreeScout processes the incoming email and saves the attachments, the .htaccess file bypasses the filename validation, lands on disk with its intended name, and reconfigures Apache to treat the webshell as executable PHP.

Because the storage path for attachments is predictable — formatted as http://[victim-domain]/storage/attachment/... — the attacker can then access the webshell directly through the web interface and execute arbitrary system commands on the server. No authentication. No clicks. No interaction. Just a single email.

The Technical Anatomy of Mail2Shell

Looking at Mail2Shell as a complete attack chain, there are several components that make it particularly effective.

The Zero-Width Space Trick

The zero-width space character (U+200B) is an invisible Unicode character that occupies no visual space in rendered text. It is commonly used in word processing and web content for purposes like marking soft line-break opportunities. Because it is invisible and non-printable, it is easy to overlook in both manual code review and automated testing. In the context of Mail2Shell, it serves as a perfect evasion character: it is present during the security check, fooling the validation logic, and then removed during sanitization, restoring the malicious filename.

The .htaccess Weapon

The malicious .htaccess file used in the attack contains an Apache directive that instructs the server to process .txt files as PHP code. A minimal example of such a directive would be AddHandler application/x-httpd-php .txt. Once this file is in place, any .txt file in the same directory (or subdirectory, depending on the Apache configuration) will be executed as PHP rather than served as plain text.

The Webshell Payload

The second attachment is a simple PHP webshell saved with a .txt extension. The webshell accepts commands via a URL query parameter and returns the output. Once the .htaccess override is active, Apache treats this text file as executable PHP, giving the attacker an interactive command shell on the server.

The Email Delivery Mechanism

FreeScout periodically polls configured mailboxes for new messages. When it finds an email with attachments, it saves those attachments to a predictable filesystem location. This is normal and expected behavior for a help desk application — it needs to store attachments so that support agents can view them. The problem is that this automated, unattended file-saving behavior provides attackers with a reliable, unauthenticated method for placing files on the server.

That is the complete anatomy of Mail2Shell as a standalone exploit. But the full picture of the FreeScout security event in late February 2026 is wider than two CVEs. There is a third vulnerability in this cluster that has received almost no coverage, and it changes the risk calculus in ways that matter for anyone currently assessing whether their environment is clean.

The Third CVE Nobody Is Talking About

The coverage of Mail2Shell has been almost entirely focused on the CVE-2026-27636 and CVE-2026-28289 chain. There is a third vulnerability disclosed at the same time that has received far less attention but significantly expands the potential attack surface: CVE-2026-27637, a critical-severity account takeover flaw carrying a CVSS score of 9.8.

CVE-2026-27637 lives in FreeScout's TokenAuth middleware. Prior to version 1.8.206, this middleware generates authentication tokens using a deterministic algorithm: the token is computed as MD5(user_id + created_at + APP_KEY). The resulting token is static — it never expires and never rotates. Anyone who can determine a user's user_id and account creation timestamp, and who has access to the application's APP_KEY, can compute a valid authentication token for that user without knowing their password. This includes administrator accounts. The flaw is classified under CWE-330 (Use of Insufficiently Random Values).

The APP_KEY is a Laravel application secret. It is a well-documented exposure vector because misconfigured Laravel deployments frequently leak it through debug pages, improperly secured .env files, public repository commits, and similar mistakes. When it leaks, every account in the application is instantly and silently compromised — with no password theft required and no login attempt that would appear in authentication logs.

The security implication is worth sitting with. The three vulnerabilities together represent a cluster of independent attack paths that all converge on the same outcome: full server compromise. You can get there through email alone (CVE-2026-28289), through authenticated file upload with a compromised account (CVE-2026-27636), or through token forgery using a leaked application secret followed by file upload (CVE-2026-27637 chained with CVE-2026-27636). Patching one path without understanding the others provides only partial protection.

The fix for CVE-2026-27637 is included in version 1.8.206. It updates the token generation mechanism to use cryptographically secure, randomly generated tokens that rotate and expire. For organizations that were running vulnerable versions, auditing whether the APP_KEY was ever exposed — in logs, in repository history, in debug output — should be treated as a mandatory step alongside patching, not an optional one.

Who Is Exposed

The vulnerability affects all FreeScout installations running version 1.8.206 or earlier on Apache web servers with AllowOverride All enabled. CVE-2026-28289 carries the same CWE-434 classification (Unrestricted Upload of File with Dangerous Type) as the original flaw it bypasses, since the underlying capability — writing a malicious file to a web-accessible directory — remains unchanged. According to OX Security's research, the Shodan search engine identified approximately 1,100 publicly exposed FreeScout instances at the time of disclosure. However, this number likely undercounts the total number of vulnerable deployments, as many FreeScout instances may not be directly identifiable through Shodan fingerprinting.

OX Security confirmed that exposed deployments span multiple sectors, including public health institutions, technology providers, financial services platforms, and news organizations. The researchers stated that they are intentionally withholding identifying details about specific affected organizations to avoid increasing risk to those parties.

Organizations running FreeScout internally behind a firewall face a lower but still real risk. If an attacker gains a foothold on the same network through another vector, they could target the internal FreeScout instance using the same exploitation chain.

It is worth noting the CVSS scoring discrepancy for this vulnerability. FreeScout assigned CVE-2026-28289 a CVSS score of 10.0 (Critical) via GitHub's security advisory system, using the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — which reflects the zero-click, unauthenticated email delivery path where no privileges are required. NIST, through the National Vulnerability Database, assessed the flaw at 7.5, likely applying different assumptions about the attack prerequisites (reflecting the authenticated upload variant rather than the email-delivery escalation). From a practical standpoint, any organization running an unpatched FreeScout instance on Apache should treat this as a critical-severity issue regardless of which CVSS score they reference. The zero-click email path requires no credentials and no user interaction.

Remediation and Hardening

The FreeScout development team responded quickly to the disclosure, releasing version 1.8.207 on February 27, 2026, with a corrected patch that addresses the TOCTOU flaw. The CVE was formally published on March 3, 2026. Administrators must upgrade to version 1.8.207 or later. It is critical to understand that version 1.8.206 — the version that patched the original CVE-2026-27636 — is still fully vulnerable to Mail2Shell.

Beyond patching, OX Security and the FreeScout maintainers both recommend a defense-in-depth measure that administrators should implement regardless of their patch level: disable AllowOverride All in the Apache configuration for the FreeScout server.

Apache — httpd.conf / Virtual Host
# In your Apache virtual host configuration or httpd.conf:
# Change AllowOverride from "All" to "None" (or a limited set)

<Directory /var/www/freescout/public>
    AllowOverride None
    # If FreeScout requires specific overrides, use a limited set:
    # AllowOverride FileInfo Options
    # Avoid "All" to prevent .htaccess-based attacks
</Directory>

Disabling AllowOverride All removes the mechanism that the entire attack chain depends on. Even if an attacker manages to upload a .htaccess file through a future bypass or similar vulnerability, Apache will ignore it if AllowOverride is set to None. This is a powerful mitigation that neutralizes not just Mail2Shell but an entire class of .htaccess-based attacks.

Additional hardening steps that administrators should consider include reviewing server logs and email logs for signs of compromise. Specifically, look for: inbound emails with attachments whose filenames contain the UTF-8 byte sequence E2 80 8B (the zero-width space U+200B) in raw headers; unexpected .htaccess files appearing in FreeScout's storage/attachment/ directory tree; web server access logs showing GET or POST requests to paths under /storage/attachment/ that were not initiated by authenticated agents; and outbound connections from the web server process to unfamiliar IPs, which may indicate an active webshell being used for lateral movement. Monitor for unexpected file modifications in FreeScout's storage directories, implement network segmentation to limit the blast radius if a FreeScout server is compromised, apply the principle of least privilege to the web server process so that even if code execution is achieved the attacker's access is constrained, and enhance email filtering at the gateway level to pre-screen incoming attachments before they reach FreeScout.

What a Correct Fix Actually Looks Like

The FreeScout maintainers fixed the TOCTOU ordering problem, but it is worth spelling out precisely what a correct implementation looks like and why — because this pattern appears in many codebases and the wrong mental model leads to repeated failures.

The root problem was that the security decision (is this filename safe?) was made using intermediate data — the filename before sanitization was complete. The fix requires that the security check operate only on finalized data. In practice, that means running all sanitization steps first, then performing validation on the cleaned output. The corrected logic flow looks like this:

PHP — Correct Implementation
// CORRECT order of operations in filename sanitization

// STEP 1: Sanitize FIRST — strip all invisible and format characters
// This includes Unicode category \p{Cf} (format chars), zero-width spaces,
// bidirectional override characters, and other non-printing Unicode
$file_name = preg_replace('/[\p{Cf}\x{200B}-\x{200D}\x{FEFF}]/u', '', $file_name);

// STEP 2: Normalize — apply NFC Unicode normalization to collapse
// any remaining multi-codepoint sequences into canonical forms
$file_name = Normalizer::normalize($file_name, Normalizer::FORM_C);

// STEP 3: VALIDATE on the sanitized result — NEVER on intermediate state
if (mb_substr($file_name, 0, 1) == '.') {
    $file_name = '_' . $file_name;  // Prepend underscore (safer than appending)
}

// STEP 4: Re-validate the extension list against the final filename
// Do not trust pre-sanitization extension checks

There is an additional subtlety that the naive fix misses. The original patch appended an underscore to the end of the filename when it detected a dot-prefix. Appending to the end is weaker than prepending, because some server configurations may still recognize the file by its leading character. Prepending the neutralizing character is safer. The corrected patch should also re-validate the extension against the final sanitized filename to catch cases where sanitization itself produces a dangerous output — an edge case that becomes more relevant as Unicode attack techniques grow more sophisticated.

A note on the regex in step one above: the official FreeScout security advisory uses the simpler patterns \p{C}+ and \p{Cf}+ to strip control and format characters. The example above uses a more explicit set that additionally targets the specific zero-width space range (\x{200B}-\x{200D}) and the byte order mark (\x{FEFF}). Both approaches address Mail2Shell. The more explicit version provides marginally broader coverage against future Unicode-based bypass variants and is the approach recommended here for any new implementation. If you are reviewing the official patch and see the simpler pattern, that is not an error — the context matters.

Beyond the ordering fix, a robust implementation applies the principle of allowlisting rather than blocklisting. Instead of maintaining a growing list of dangerous filenames and extensions to block, the function should define a narrow list of permitted extensions and reject everything else. This inverts the security model: the default is denial, and only explicitly approved types are allowed through. A blocklist can always be bypassed by discovering a type that was not included. An allowlist can only be bypassed by discovering something that is explicitly permitted but dangerous — a far smaller and more controllable surface.

Web application firewalls can add a meaningful layer of defense against this class of attack at the network perimeter, independently of application-level fixes. WAF rules that inspect multipart form uploads for filenames containing Unicode format characters, zero-width spaces, or known dangerous combinations can block exploit attempts before they reach application code. For organizations that cannot patch immediately, a WAF rule targeting the specific byte sequences used in Mail2Shell (E2 80 8B for U+200B) provides a short-term compensating control. The rule needs to inspect raw filename bytes, not rendered display text, since the attack exploits the gap between what is visible and what is processed.

Containerized and orchestrated deployments offer structural protections that bare-metal or VPS deployments do not. When FreeScout runs in a container with read-only filesystem mounts for the application code and a separate, isolated, writable volume for attachments, an uploaded .htaccess file in the attachment directory cannot affect Apache's configuration for the application directory. Docker volumes can be mounted with noexec flags, preventing execution of any file within the attachment storage directory regardless of how it is named or what directives it contains. Organizations deploying new FreeScout instances should consider this architecture as a default rather than an afterthought, since it structurally eliminates the class of attack that Mail2Shell represents — without relying on application-level validation being correct.

Lessons for Defenders

Mail2Shell is a case study in several recurring themes that defenders encounter across the vulnerability landscape.

Patches are not guarantees. The FreeScout team responded to CVE-2026-27636 with a patch that was reasonable on its surface. They blacklisted the dangerous file extensions and added logic to catch dotfiles. But the patch contained a subtle ordering flaw that attackers were able to identify and exploit within days. This is not a failure unique to FreeScout — it is a pattern seen repeatedly across the software industry. Attackers routinely diff patches immediately after release, looking for exactly these kinds of incomplete fixes.

TOCTOU vulnerabilities are subtle and persistent. Time-of-Check to Time-of-Use flaws are among the more difficult vulnerability classes to identify during code review because the check and the use may be separated by many lines of code, multiple function calls, or asynchronous processing steps. The lesson here is that input validation should always operate on the final, fully processed form of the data — never on an intermediate representation that will be modified later. The corrected implementation and why it matters is explored in detail in the section above. The conceptual principle applies everywhere: validate what you will actually use, not what you see at the moment of checking.

Unicode is an attack surface that most codebases are not hardened against. The use of a zero-width space character to bypass filename validation is not a novelty. Invisible Unicode characters, homoglyph attacks (characters that look identical to ASCII but are different codepoints), bidirectional text override characters (which can reverse displayed text while the underlying string remains dangerous), and other Unicode manipulation techniques have been used in phishing, supply chain backdoors inserted into source code, and input validation bypasses for years. Any application that handles user-supplied filenames, URLs, or text input should apply Unicode normalization (specifically NFC normalization via PHP's Normalizer::normalize() or the equivalent in the relevant language) as the first step in any input pipeline. This is not optional defense-in-depth. It is a prerequisite for any downstream security check to be meaningful.

Ask whether your fix changes the attack model or just the attack path. The patch for CVE-2026-27636 changed the specific filenames that were blocked, but it did not change the fundamental model: the server would still process attacker-controlled files if an attacker found a way past the blocklist. Mail2Shell found that way within days. A fix that changes the attack model would have been one that removed the server's ability to process arbitrary uploaded files as executable code regardless of their name — which is exactly what disabling AllowOverride All achieves. When evaluating whether a patch is sufficient, the right question is not "does this stop the known technique?" but "does this remove the capability that makes the technique possible?"

Self-hosted software demands active maintenance. FreeScout's self-hosted deployment model means that every organization running it is individually responsible for patch management. Unlike SaaS platforms where the vendor pushes updates centrally, self-hosted applications depend on administrators monitoring for security advisories and applying updates promptly. Organizations that choose self-hosted solutions for the benefits of data control and cost savings must also accept the operational responsibility of keeping those systems current.

Defense in depth remains essential. The recommendation to disable AllowOverride All even after patching is a reminder that layered defenses matter. If the FreeScout server had been configured with AllowOverride None from the start, neither CVE-2026-27636 nor CVE-2026-28289 would have been exploitable — regardless of the file upload vulnerabilities. Hardening the environment around the application can neutralize entire categories of exploits that the application itself might be vulnerable to. Containerizing the attachment storage volume with noexec mounts would have achieved the same result through a completely different mechanism. Multiple independent controls, each of which would have stopped the attack on its own, is the architecture that actually holds.

Help desk systems deserve threat-modeling as communication infrastructure. A question this incident raises that rarely gets asked: when organizations assess the risk of their help desk software, do they model it as a communication gateway that accepts untrusted input from the entire internet? The answer, based on how often these systems go unpatched, is probably not. A help desk application like FreeScout sits at a uniquely exposed position — it is intentionally designed to receive messages from anyone, it stores their content, and it runs on infrastructure that is often shared with other internal services. Threat-modeling it with the same rigor applied to an internet-facing web application or email gateway would likely produce very different patching and hardening priorities. The fact that Mail2Shell weaponizes the system's intended function is not a coincidence — it is a predictable consequence of deploying file-processing infrastructure that faces the open internet without treating it as such.

The Mail2Shell case illustrates something worth internalizing: attackers diff patches within hours of release, looking for exactly the kind of residual attack paths that an incomplete fix leaves behind. OX Security's research on CVE-2026-28289 demonstrated this precisely — the bypass was found and the zero-click escalation developed on the same day the original patch shipped. The time between a patch and a bypass can be measured in days.

As of this writing, no active exploitation of CVE-2026-28289 has been confirmed in the wild. That status can change quickly. The vulnerability's zero-click nature, the public availability of detailed technical analysis from OX Security, the predictable attachment storage path, and the simple two-file exploit delivery all make this a low-effort weaponization target. Organizations running FreeScout on Apache should treat patching and hardening as an immediate priority — not a task for next week's maintenance window. Checking current threat intelligence sources for exploitation activity before assuming the window is still quiet is worthwhile for any organization that has not yet patched.