Mail2Shell: CVE-2026-28289 FreeScout Zero-Click RCE — One Email, Full Server Access

The Attack in Plain Language

FreeScout is an open-source customer support and helpdesk platform — a self-hosted alternative to Freshdesk and Zendesk with over 4,100 GitHub stars. It's commonly deployed by small and mid-sized businesses, MSPs, and security-conscious teams who want helpdesk functionality without sending customer data to a SaaS provider.

CVE-2026-28289 allows an unauthenticated attacker to achieve remote code execution by sending a single email. No account required. No interaction from helpdesk staff beyond the mail server receiving the message. The attack flow is:

1. Attacker sends an email to any email address monitored by FreeScout
2. FreeScout's mail fetcher processes the email, including its attachments
3. A specially named attachment is stored in /storage/attachments/, which is web-accessible
4. The attachment is a PHP webshell or an .htaccess file that configures Apache to execute PHP from that directory
5. The attacker accesses the stored file via the web interface to execute arbitrary commands

The file extension validation that was supposed to block dangerous uploads exists — but a Unicode character turns it off.

The Technical Vulnerability: Unicode U+200B and the Bypass

The root cause is how FreeScout validates attachment file extensions before storage. The validation check examines the filename to block dangerous extensions — .php, .htaccess, executable files.

The bypass uses Unicode U+200B — a zero-width space character that is invisible in most text rendering contexts. An attacker names their attachment ​.htaccess (with the U+200B prepended before the dot). The validation logic sees a filename starting with an invisible character and doesn't recognise it as matching the blocked pattern for .htaccess.

When the file is subsequently written to disk, PHP's filesystem normalisation strips or collapses the U+200B character — leaving a file named simply .htaccess in the attachments directory. Apache, with AllowOverride All in the server configuration, picks up the newly created .htaccess and applies its directives.

A malicious .htaccess might contain:

AddType application/x-httpd-php .txt
php_flag engine on

This instructs Apache to parse .txt files as PHP. The attacker then sends a second email with a .txt attachment containing their PHP webshell — also stored in the same directory. The .htaccess causes Apache to execute it as PHP on the first HTTP request.

The result is unauthenticated code execution under the web server's user context, with access to all FreeScout application data including customer emails, attachments, and — critically — the application's environment configuration including database credentials and API keys.

Why This is a Fix Bypass: The CVE-2026-27636 History

This vulnerability is a bypass of a prior security fix. CVE-2026-27636, disclosed approximately six weeks ago, identified the same class of vulnerability: attacker-controlled email attachments being stored in web-accessible directories. The fix introduced file extension validation to block dangerous file types.

CVE-2026-28289 demonstrates that the fix was incomplete. The original validation checked for blocked extensions as exact string matches after basic normalisation — but didn't account for Unicode characters that survive the string comparison but are stripped during filesystem operations.

This bypass pattern — Unicode homoglyphs or zero-width characters in filenames — is a well-documented class of file upload bypass. The zero-width space specifically has appeared in multiple CVEs across different platforms. The Web Application Hacker's Handbook covers file upload bypass techniques in depth, including the Unicode normalisation class of attacks. Security teams performing code review on any platform handling user-supplied filenames should treat Unicode normalisation as a mandatory test case.

Prerequisites and Attack Surface

The prerequisites for exploitation are minimal:

• FreeScout version ≤ 1.8.206 — all versions prior to the patch are vulnerable
• A monitored mailbox — any email address configured to fetch into FreeScout. These are typically published as support addresses: support@company.com, help@company.com
• Apache with AllowOverride All — the default configuration for many FreeScout deployments. Nginx deployments are not vulnerable to the .htaccess vector (Nginx doesn't use .htaccess), but may be vulnerable to the direct PHP upload variant if PHP execution isn't restricted in the attachments directory
• Web-accessible attachments directory — required for the attacker to retrieve and execute their dropped file. Default FreeScout configurations expose /storage/attachments/

OX Research conducted a Shodan scan and identified over 1,100 publicly accessible FreeScout instances as of March 4, 2026. These are instances with web interfaces exposed to the internet — the actual count of vulnerable mail processing endpoints (which don't require web exposure to receive the initial email) is likely higher.

No active exploitation has been confirmed as of March 5, 2026. However, the zero-click nature of this vulnerability — it requires only that the target's mail server accept the email — means exploitation is trivially automatable. The disclosure period is approximately four days old. Expect exploitation activity to begin shortly.

Remediation

Immediate action: Update to FreeScout v1.8.207. This version patches the Unicode bypass. The fix was released approximately four days before this disclosure and is available via the standard FreeScout update mechanism.

If you cannot patch immediately:

• Nginx deployments: Ensure the attachments directory has PHP execution disabled. In Nginx, add a location block explicitly disabling PHP parsing for the attachments path:

  location ~* /storage/attachments {
      location ~* \.php$ { deny all; }
  }

• Apache deployments: Override the AllowOverride directive for the attachments directory to prevent .htaccess from applying:

  <Directory /var/www/freescout/storage/attachments>
      AllowOverride None
      Options -ExecCGI
      php_flag engine off
  </Directory>

• All deployments: Verify that /storage/attachments/ is not directly web-accessible if possible. Moving the attachments directory out of the webroot entirely eliminates the execution vector even if the upload bypass persists

Threat hunt steps for potentially compromised instances:

• Check for .htaccess files in /storage/attachments/ or subdirectories
• Check for .php, .phtml, .php5, or .txt/.jpg files that contain PHP code in the attachments directory
• Review Apache/Nginx access logs for requests to the attachments directory that include query strings (common for webshell interaction)
• Check FreeScout mail logs for emails with unusually named attachments — particularly those containing non-printable or zero-width Unicode characters in filenames
• Review server process creation logs for commands spawned by the web server user (PHP RCE will typically appear as child processes of Apache/php-fpm)

The Broader Pattern: Unicode Characters as Security Control Bypasses

This vulnerability fits a recurring pattern in web application security: validation logic that operates on the string representation of a filename, while the filesystem operates on the bytes. Any transformation between those two states — Unicode normalisation, character stripping, encoding/decoding — creates an opportunity for bypass.

Common variants of this pattern:

• Unicode homoglyphs: Using visually similar Unicode characters that normalize to ASCII letters. A filename with Cyrillic "а" instead of Latin "a" passes extension checks that match on ASCII characters
• Null byte injection: In languages with C-string heritage, a null byte (%00) can truncate a filename at the filesystem level while the validation sees the full string. Largely mitigated in modern PHP but still relevant for older codebases
• Double extension + MIME mismatch: shell.php.jpg passes MIME-based checks but may be served as PHP if the web server uses extension-based type determination
• Zero-width characters (this vulnerability): Characters like U+200B, U+200C (zero-width non-joiner), U+FEFF (BOM) that are invisible in rendering and may be stripped during filesystem normalisation

For penetration testers, file upload testing should always include a Unicode bypass pass. The Black Hat Python 2nd Edition includes practical tool development for file upload testing scenarios, and building a fuzzer that systematically tests Unicode character prefixes against validation endpoints is a tractable weekend project.

For developers maintaining any application that accepts user-supplied filenames, the correct approach is:

1. Reject, don't sanitise — allowlist safe characters rather than denying known-bad ones
2. Normalise filenames to ASCII before any security check
3. Store attachments outside the webroot, or explicitly disable execution in the storage directory at the web server level regardless of what validation the application performs

The third point is the most important. Application-layer validation is your second line of defence. Web server configuration that prevents code execution in upload directories is the first — and it eliminates an entire class of file upload CVEs regardless of the specific bypass technique used.

Who Should Care

FreeScout deployments skew toward organisations that prioritise data sovereignty — self-hosted software users who've made an explicit decision not to send customer communications to a third-party SaaS provider. These are often the same organisations with higher security awareness. Ironically, the self-hosted deployment model also means they're responsible for applying patches themselves — there's no cloud provider pushing this automatically.

If you run FreeScout for internal IT support, external customer service, or security team communications, this vulnerability exposes your entire helpdesk email archive to an unauthenticated attacker. Every ticket, every customer complaint, every internal support conversation, every attachment — all accessible to whoever sends the right email first.

For incident responders and bug bounty hunters: 1,100+ exposed instances plus a four-day-old disclosure and no observed exploitation yet is a meaningful window. Bug bounty programmes for self-hosted software platforms often accept vulnerability reports relating to the deployment infrastructure of their software in scope. Check programme terms carefully before testing.

Consult the Metasploit: The Penetration Tester's Guide for broader context on web application exploitation frameworks and responsible disclosure methodology.