CVE-2026-110595 in BottleCRM
Summary
by MITRE • 10/14/2026
BottleCRM 0.45 through 1.14.5 contains an uncontrolled memory allocation vulnerability in _read_upload() that reads entire CSV uploads before enforcing the 5 MB limit. Authenticated users with mass-import permission can send oversized CSV files concurrently to /api/contacts/import/ and /api/cases/import/ endpoints to exhaust worker memory and trigger out-of-memory termination.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The vulnerability identified in BottleCRM versions 0.45 through 1.14.5 represents a critical uncontrolled memory allocation flaw located within the _read_upload() function, which is responsible for processing CSV file imports. This architectural defect stems from an incorrect sequence of operations during data ingestion where the system prioritizes reading the entire content of an uploaded CSV file into server-side memory before validating whether the file size exceeds the configured maximum limit of five megabytes. By loading the complete payload into RAM prior to enforcement, the application fails to implement a stream-based processing approach or early validation checks that would typically prevent large payloads from consuming excessive resources. This design oversight creates a direct pathway for resource exhaustion attacks against the web server infrastructure hosting the BottleCRM instance.
Authenticated users possessing mass-import permissions can exploit this flaw by submitting oversized CSV files concurrently through the /api/contacts/import/ and /api/cases/import/ endpoints. Because the memory allocation occurs before size validation, an attacker does not need to bypass any authentication or authorization checks beyond having valid credentials with import rights. The concurrent nature of these requests amplifies the impact significantly, as multiple large payloads can be processed simultaneously by different worker processes. This concurrency leads to a rapid depletion of available system memory across all active workers handling incoming traffic rather than affecting only a single process instance.
The operational impact of this vulnerability is severe, resulting in denial-of-service conditions for both the specific application and potentially the underlying host server depending on configuration limits. When the cumulative memory usage exceeds physical RAM or swap space thresholds, the operating system's out-of-memory killer mechanism typically terminates processes to reclaim resources. In this context, worker processes running BottleCRM are terminated abruptly, causing immediate service disruption for all users attempting to access the platform. This results in significant downtime and potential data inconsistency if transactions were mid-processing during termination events. The attack vector is classified under CWE-789 as Uncontrolled Memory Allocation because the application does not properly control the allocation of memory resources based on user input size, leading to resource exhaustion.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1496 Resource Hijacking, specifically within the sub-category of Denial of Service via resource consumption. Attackers leverage legitimate authentication credentials and authorized API endpoints to degrade service availability without needing elevated privileges or external network access beyond standard web traffic. The exploitation relies on the application's failure to implement proper input validation boundaries before memory-intensive operations are initiated.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The primary solution is to upgrade BottleCRM to a version newer than 1.14.5 where this logic error has been corrected, ensuring that file size limits are enforced prior to full content loading into memory. For environments unable to patch immediately, implementing reverse proxy configurations such as Nginx or Apache can help mitigate the risk by enforcing strict request body size limits at the network edge before traffic reaches the application server. Additionally, configuring worker process restarts and monitoring for abnormal memory consumption patterns can aid in detecting ongoing exploitation attempts. Application-level fixes should also include refactoring the _read_upload() function to use streaming parsers that read CSV data in chunks rather than loading entire files into RAM, thereby decoupling file size from total memory footprint during processing.