CVE-2025-43857

What it actually does

The flaw is a denial-of-service condition caused by unsafe memory allocation while processing IMAP server responses. When a client using the vulnerable IMAP response reader receives a server-declared literal byte count, the receiver thread trusts that count and immediately attempts to allocate memory for the advertised size. A malicious, compromised, buggy, or untrusted IMAP server can advertise an excessively large literal size without needing to send a corresponding payload, causing the client process to consume large amounts of memory and potentially crash or be killed by the operating system. The issue is most relevant where software connects to user-supplied, untrusted, insecure, or compromised IMAP endpoints; securely configured connections to trusted, well-behaved IMAP servers materially reduce exposure.

Why it matters to the business

Successful exploitation can interrupt mail-processing workflows, automation jobs, or services that initiate IMAP connections, leading to application crashes, degraded availability, failed background processing, or host-level memory pressure if many processes are affected. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, is not associated with ransomware campaigns, and has a low EPSS score of 0.0047, so prioritization should be risk-based: higher for systems that connect to externally controlled or user-configurable IMAP servers, and lower for systems restricted to trusted mail infrastructure. For the listed Red Hat Enterprise Linux 9.0 EUS AppStream QEMU-related packages, remediation is available in version 17:6.2.0-11.el9_0.8.

How an attack unfolds

An attacker must be able to influence the IMAP server endpoint contacted by a vulnerable client, operate a malicious IMAP server, compromise a legitimate IMAP server, or position the client to connect over an insecure path to a hostile service. After the client establishes an IMAP session, the malicious server sends a syntactically valid IMAP response containing a literal byte count with an extremely large value. The vulnerable response reader trusts the declared length and allocates memory for that amount in the receiver thread. This can rapidly exhaust process or system memory, causing the application to hang, crash, be terminated by the OOM killer, or trigger broader service instability. No authentication bypass or code execution is implied by the vulnerability itself; the primary impact is availability loss.

How to fix it

Upgrade affected packages to fixed vendor versions. For Red Hat Enterprise Linux 9.0 EUS AppStream packages listed in the advisory, update qemu-guest-agent, qemu-img, qemu-kvm, qemu-kvm-common, qemu-kvm-core, qemu-kvm device packages, block drivers, debuginfo/debugsource packages, and related subpackages to 17:6.2.0-11.el9_0.8 or later. Where the vulnerable IMAP client library is used directly by applications, update the affected net-imap dependency to a vendor-fixed release. As compensating controls, restrict IMAP destinations to trusted servers, disallow user-supplied IMAP hostnames unless strictly validated, require TLS with certificate validation, block plaintext IMAP to untrusted networks, set process/container memory limits, configure supervisor restart backoff, and monitor for repeated OOM events. These mitigations reduce exploitability but should not replace patching.

How to confirm the fix worked

Confirm package remediation by querying installed package versions and verifying that affected Red Hat packages are at 17:6.2.0-11.el9_0.8 or later. On RPM-based systems, use package inventory tools such as rpm -q, dnf repoquery, vendor vulnerability scanners, or configuration management reporting to validate installed versions. For applications using IMAP libraries directly, inspect dependency manifests and lockfiles, then confirm the resolved runtime dependency is a fixed version. Validate exposure reduction by reviewing application configuration to ensure IMAP connections are limited to trusted hosts, TLS certificate verification is enabled, and user-controlled hostnames cannot be used to initiate arbitrary IMAP connections. Operationally, test that mail-processing jobs continue to function after upgrade and that memory limits or restart policies behave as expected under failure conditions.

Typical attack path

1. Identify an application, job, or service that uses the vulnerable IMAP client behavior and can be made to connect to an attacker-controlled, untrusted, insecure, or compromised IMAP server.
2. Cause or wait for the target software to initiate an IMAP connection to the hostile server.
3. Return an IMAP response containing an excessively large literal byte count.
4. Trigger immediate memory allocation by the vulnerable response reader thread.
5. Cause process memory exhaustion, application crash, operating-system OOM termination, or service degradation.
6. Repeat the interaction to sustain denial of service if the application automatically retries or restarts.

How to detect it

To determine whether this was already exploited, review host, application, and mail-client logs for memory exhaustion or crashes that occur immediately after IMAP connections. Useful log sources include system journals, kernel logs, OOM killer logs, application logs for mail ingestion or IMAP polling services, process supervisor logs, container runtime events, endpoint telemetry, and network metadata for outbound IMAP traffic on ports 143, 993, and nonstandard IMAP service ports. Look for repeated crashes of the same mail-processing process, abrupt termination with SIGKILL, kernel OOM messages, sudden resident memory growth after IMAP responses, retry loops to the same IMAP endpoint, and connections to newly introduced or user-supplied mail servers. Network packet captures, if available, may show IMAP server responses with unusually large literal size declarations in curly braces, such as very large numeric values in responses. There are no public threat actors or ransomware campaigns associated with this issue in the provided data, so detection should focus on behavioral artifacts rather than actor-specific infrastructure.

• Out of memory: Killed process
• Memory cgroup out of memory
• oom-kill
• invoked oom-killer
• Killed process
• SIGKILL
• net/imap
• Net::IMAP
• IMAP
• literal
• port 143
• port 993
• {2147483647}
• {4294967295}
• {9999999999}
• qemu-kvm
• qemu-img
• qemu-guest-agent

What your security team should do

• Prioritize patching internet-facing, multi-tenant, automation, or mail-ingestion systems that can connect to user-supplied or externally controlled IMAP servers.
• Upgrade the listed Red Hat Enterprise Linux 9.0 EUS AppStream packages to 17:6.2.0-11.el9_0.8 or later, and update any directly used vulnerable IMAP client dependency to a fixed release.
• Inventory applications that initiate IMAP connections and identify whether destination hostnames can be configured by users, partners, imported data, or external workflows.
• Enforce allowlists for IMAP server destinations and require TLS with certificate validation for all IMAP connections.
• Add memory limits, restart backoff, and alerting for services that perform IMAP polling or mailbox ingestion.
• Hunt for historical process crashes, OOM killer events, and repeated IMAP connection failures involving mail-processing processes.
• Because this is not KEV-listed, not tied to ransomware, and has low EPSS, handle through normal vulnerability management unless the organization relies on untrusted or user-configurable IMAP connectivity.