CVE-2026-108750 in OpenDocMan
Summary
by MITRE • 10/11/2026
OpenDocMan 2.4.0 through 2.10.0 contains a decompression bomb vulnerability that allows authenticated users to exhaust PHP memory by uploading crafted office documents. Attackers can upload a small ODT, DOCX, or XLSX file whose XML entries decompress to hundreds of megabytes, crashing PHP workers and degrading availability.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/11/2026
OpenDocMan versions 2.4.0 through 2.10.0 are susceptible to a decompression bomb vulnerability that enables authenticated users to exhaust server resources by uploading maliciously crafted office documents. This flaw stems from the application's failure to adequately validate or limit the size of files after they have been extracted from their compressed archives, such as ODT, DOCX, or XLSX formats. These file types are essentially ZIP archives containing XML data and other assets. When an attacker uploads a small archive that contains entries designed to expand significantly upon decompression, the server attempts to process this inflated content without checking if it exceeds predefined memory limits or storage quotas.
The technical mechanism behind this vulnerability relies on the disparity between the compressed file size and its uncompressed footprint. An attacker can construct a document where internal XML files are repeatedly duplicated or structured in a way that results in hundreds of megabytes of data when extracted by PHP libraries like ZipArchive or similar parsing tools. Because OpenDocMan processes these uploads to store them within its repository, the system allocates memory proportional to the decompressed size rather than the uploaded file size. This behavior leads to rapid consumption of available RAM on the web server hosting the application.
The operational impact of this vulnerability is primarily related to service availability and resource exhaustion. As PHP workers attempt to handle these oversized files, they consume excessive amounts of memory, eventually leading to out-of-memory errors or process crashes. In a shared hosting environment or when using traditional LAMP stacks with limited resources, this can cause the entire web server to become unresponsive, effectively resulting in a denial of service for legitimate users. Even if individual PHP processes are restarted by the system manager, an attacker could repeatedly trigger these uploads to maintain a persistent state of resource exhaustion, thereby degrading the overall performance and reliability of the document management platform.
This vulnerability aligns with CWE-409, which describes improper handling of excessively large files in compressed formats, often referred to as zip bombs or decompression bombs. From an offensive security perspective, this technique is consistent with ATT&CK tactic T1496, Resource Hijacking, specifically the subtechnique for resource exhaustion via denial-of-service attacks. Although the vulnerability requires authentication, it poses a significant risk because authenticated users may have varying levels of privilege, and even low-privileged accounts can disrupt service availability if they are allowed to upload files that trigger this flaw.
Mitigation strategies should focus on implementing strict input validation and size limits at multiple layers of the application stack. Developers must enforce maximum file sizes not only for the initial upload but also after decompression occurs within the PHP environment. This can be achieved by configuring memory_limit settings in php.ini to restrict the amount of memory a single script execution can consume, although this is a partial mitigation that may impact legitimate large files. A more robust solution involves modifying the application code to check the uncompressed size before fully loading it into memory or using streaming parsers that do not require full decompression for validation purposes. Additionally, implementing rate limiting on upload endpoints and monitoring server resource usage can help detect and mitigate such attacks in real-time until a permanent patch is applied by upgrading to a version of OpenDocMan where this issue has been resolved.