CVE-2026-82520 in parsedmarcinfo

Summary

by MITRE • 09/03/2026

parsedmarc before 11.0.1 decompresses gzip and ZIP attachments in a single unbounded read with no limit on decompressed output size. Because parsedmarc automatically processes incoming DMARC report emails without user interaction, an unauthenticated remote attacker can send a crafted email with a highly compressed attachment to the monitored mailbox, causing the parsedmarc process to allocate memory proportional to the uncompressed size and exhaust available RAM.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 09/03/2026

The vulnerability identified in versions of parsedmarc prior to 11.0.1 represents a critical resource exhaustion flaw rooted in improper input validation during archive processing. The core technical deficiency lies in the library's handling of gzip and ZIP attachments within incoming DMARC report emails. When the software encounters these compressed file formats, it initiates an automatic decompression process without implementing any constraints on the size of the resulting uncompressed data. This design choice assumes that the ratio between compressed and uncompressed sizes will remain manageable or that system resources are sufficient to handle worst-case scenarios, which is a fundamental security anti-pattern in systems processing untrusted external input.

From an operational perspective, this flaw allows for a straightforward denial-of-service attack vector against any infrastructure relying on parsedmarc for DMARC analysis. Because the tool operates autonomously to process incoming emails without requiring user interaction or authentication, it presents a low-barrier entry point for attackers. A remote adversary can craft a malicious email containing an attachment that is highly compressed but expands into a massive amount of data when decompressed. Upon receipt and automatic processing by the vulnerable parsedmarc instance, the application attempts to allocate memory proportional to this inflated uncompressed size. This rapid consumption of available RAM leads to resource exhaustion, causing the process to crash or become unresponsive due to out-of-memory conditions.

The impact of this vulnerability extends beyond simple service disruption for the immediate host. In environments where parsedmarc is integrated into broader email security pipelines or monitoring dashboards, a failure in parsing can lead to gaps in visibility regarding domain authentication and abuse reports. This lack of data integrity hinders an organization's ability to detect spoofing attempts or monitor their DMARC policy effectiveness. Furthermore, if the system runs with elevated privileges or within containerized environments without strict resource limits, the memory exhaustion could potentially affect other co-located services, amplifying the blast radius of the attack beyond just the parsedmarc process itself.

This vulnerability aligns closely with CWE-400, which describes uncontrolled resource consumption, specifically manifesting as a denial-of-service condition through excessive allocation. It also maps to MITRE ATT&CK technique T1496, Resource Hijacking, where an attacker uses computing resources for their own benefit or to disrupt service availability by exhausting system capacity. The attack vector is classified under Remote Code Execution principles in the broader sense of impacting system stability via remote input, specifically leveraging the Automated Processing aspect common in mail servers and parsers.

To mitigate this risk, organizations must upgrade parsedmarc to version 11.0.1 or later, where developers have implemented safeguards against unbounded decompression. Until an update is applied, defensive measures should focus on external filtering mechanisms. Deploying a front-end email gateway that inspects attachments for potential zip bombs before they reach the parsedmarc service can provide effective protection. Additionally, implementing strict memory limits and resource quotas at the operating system or container orchestration level ensures that even if such an attack is attempted, its impact is contained within defined boundaries, preventing total host compromise or widespread service outage. Regular auditing of dependency versions in automated mail processing pipelines is essential to maintain resilience against these types of algorithmic complexity attacks.

Responsible

VulnCheck

Reservation

08/29/2026

Disclosure

09/03/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!