CVE-2026-45185

Published May 12, 2026

Last updated 2 months ago

CVSS critical 9.8
SMTP
Tls

Overview

Description
Exim before 4.99.3, in certain GnuTLS configurations, has a remotely reachable use-after-free in the BDAT body parsing path. It is triggered when a client sends a TLS close_notify mid-body during a CHUNKING transfer, followed by a final cleartext byte on the same TCP connection. This can lead to heap corruption. An unauthenticated network attacker exploiting this vulnerability could execute arbitrary code.
Source
cve@mitre.org
NVD status
Analyzed
Products
exim

Risk scores

CVSS 3.1

Type
Secondary
Base score
9.8
Impact score
5.9
Exploitability score
3.9
Vector string
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Severity
CRITICAL

Weaknesses

cve@mitre.org
CWE-416

Social media

Hype score
Not currently trending

  1. 12, 2026, — Dead.Letter: Critical Use-After-Free RCE in Exim Mail Servers — CVE-2026-45185. On May 12, 2026, the Exim development team released emergency security advisories addressing CVE-2026-45185, a severe use-after-free vulnerability in the BDAT message body parsing…

    @lyrie_ai

    22 Jun 2026

    18 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  2. CVE-2026-45185: Email infrastructure remains one of the Internet’s highest-value attack surfaces. In @BleepinComputer, Bill Toulas covers XBOW’s discovery of CVE-2026-45185, a critical unauthenticated Exim RCE, and the crucial role AI tools play in helping security…

    @lyrie_ai

    7 Jun 2026

    21 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  3. CVE-2026-45185: Exim Mail Server Remote Code Execution - What It Means for Your Business and How to Respond https://t.co/RLx0170GsS

    @integ_sec

    31 May 2026

    23 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  4. CVE-2026-45185: ⚠️⚠️ CVE-2026-45185 (CVSS 9.8): Critical Exim mail-server vulnerability — patch or upgrade immediately. 🔗FOFA Link: 🎯6.0M+ Results are found on in the past year. FOFA Query: app="Exim-Mail-Server" 🔖Refer:…

    @lyrie_ai

    17 May 2026

    41 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    1 Reply

    0 Quotes

  5. New zero-days hit Microsoft Exchange (XSS/spoofing, CVE-2026-42897) & Windows DNS Client (RCE, CVE-2026-41096), plus Exim MTA (RCE, CVE-2026-45185). Critical for data privacy & integrity in transit. Patch ASAP! #Cybersecurity #InfoSec #Vulnerabilities

    @YourAnon_irc

    17 May 2026

    76 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  6. A new critical Exim mailer flaw (CVE-2026-45185) allows remote code execution. #CyberSecurity #InfoSec https://t.co/V2FwJqOAzY https://t.co/6VU0mBuctE

    @twelvesec

    16 May 2026

    84 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

  7. Top 5 Trending CVEs: 1 - CVE-2026-44581 2 - CVE-2026-45185 3 - CVE-2026-44578 4 - CVE-2026-20182 5 - CVE-2026-42945 #cve #cvetrends #cveshield #cybersecurity https://t.co/4Fua3CAN6W

    @CVEShield

    16 May 2026

    144 Impressions

    0 Retweets

    0 Likes

    2 Bookmarks

    0 Replies

    0 Quotes

  8. THREAT INTEL: CVE-2026-45185 Dead.Letter - Exim pre-auth RCE via BDAT/GnuTLS UAF. 9 detections, 24 IOCs. https://t.co/DynMOo9pVI #ThreatIntel #Exim #RCE #CVE https://t.co/162nPZb9SR

    @threadlinqs

    14 May 2026

    26 Impressions

    0 Retweets

    0 Likes

    0 Bookmarks

    0 Replies

    0 Quotes

Configurations

Related CVEs

  1. Vulnerability in the Oracle Workflow product of Oracle E-Business Suite (component: Workflow Notification Mailer). Supported versions that are affected are 12.2.3-12.2.15. Difficult to exploit vulnerability allows unauthenticated attacker with network access via SMTP to compromise Oracle Workflow. Successful attacks of this vulnerability can result in takeover of Oracle Workflow. CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).•CVE-2026-62547
  2. Missing validation of the outer content_type byte on TLS 1.3 encrypted records in s2n-tls allows an active man-in-the-middle to silently discard individual application data records without either endpoint detecting the modification. RFC 8446 Section 5.2 requires that the outer content_type of all encrypted TLS 1.3 records must be application_data (0x17). The s2n-tls AEAD implementation hardcodes this value in the additional authenticated data rather than using the actual wire byte, so the outer content_type is not covered by the authentication tag. This enables selective suppression of application data. In HTTP pipelining scenarios, dropping a TLS record containing an HTTP request can cause request/response desynchronization, where subsequent responses are delivered to the wrong requests. In write-heavy workloads, a dropped record containing a write request can result in undetectable data loss when the client interprets a subsequent success response as confirmation of the dropped write. All TLS 1.3 connections are affected. Both TLS clients and servers are affected. TLS 1.2 and QUIC connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16317
  3. The QUIC transport parameters extension handler in s2n-tls incorrectly uses s2n_alloc instead of s2n_realloc to store the peer's transport parameters. When a TLS 1.3 connection goes through a HelloRetryRequest, the handler is called twice on the same connection. On the second call, s2n_alloc zeroes the existing pointer before allocating new memory, causing the first allocation to be leaked. This can occur during normal QUIC traffic when a client offers a key share group the server does not prefer. An unauthenticated user can amplify the issue by deliberately forcing HelloRetryRequests, causing up to approximately 64 KB of unreachable memory per handshake. Over time, this can lead to increased memory consumption on long-running server processes. The unreachable memory is only reclaimed when the process is restarted. Only server-side QUIC-enabled deployments are affected. Non-QUIC TLS connections are not affected. We recommend you upgrade s2n-tls to version v1.7.6•CVE-2026-16318
  4. In the Linux kernel, the following vulnerability has been resolved: net/handshake: Drain pending requests at net namespace exit The arguments to list_splice_init() in handshake_net_exit() are reversed. The call moves the local empty "requests" list onto hn->hn_requests, leaving the local list empty, so the subsequent drain loop runs zero iterations. Pending handshake requests that had not yet been accepted are not torn down when the net namespace is destroyed; each one keeps a reference on a socket file and on the handshake_req allocation. Pass the source and destination in the documented order (list_splice_init(list, head) moves list onto head) so the pending list is transferred to the local scratch list and drained through handshake_complete(). Fixing the splice direction exposes a list-corruption race. After the splice each req->hr_list still has non-empty link pointers, threading the stack-local scratch list rather than hn_requests. A concurrent handshake_req_cancel() -- for example, from sunrpc's TLS timeout on a kernel socket whose netns reference was not taken -- finds the request through the rhashtable, calls remove_pending(), and sees !list_empty(&req->hr_list). __remove_pending_locked() then list_del_init()s an entry off the scratch list while the drain iterates, corrupting it. The same call arriving after the drain loop has run list_del() on an entry hits LIST_POISON instead. Have remove_pending() check HANDSHAKE_F_NET_DRAINING under hn_lock and report not-found when drain is in progress. The drain has already taken ownership; handshake_complete()'s existing test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates between drain and cancel for who calls the consumer's hp_done. Use list_del_init() rather than list_del() in the drain so req->hr_list does not carry LIST_POISON after drain releases the entry. The DRAINING guard in remove_pending() makes cancel return false, but cancel still falls through to test_and_set_bit on HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference. Without another pin, if that is the last reference, sk_destruct frees the request while it is still linked on the drain loop's local list. Pin each request's hr_file under hn_lock before releasing the list, and drop that drain pin after the loop finishes with the request.•CVE-2026-63978
  5. Bypass to the fix for CVE-2026-34916. Variants of such vectors have been also reported by phucrio and offsetmd. The fix can be bypassed either by sending a disallowed but otherwise valid plugin identifier as `type`, or using the `ox.setChannelTargeting` XML-RPC API method.•CVE-2026-50741

References

Sources include official advisories and independent security research.