CVE-2026-105854 in Payload
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, a malformed multipart request body can cause multipart Content-Type processing to take an extremely long time, resulting in uncontrolled resource consumption. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Payload CMS affects headless content management systems operating on version ranges from 3.0.0 up to, but not including, 3.90.0, as well as canary versions prior to 4.0.0-canary.34. This security flaw is classified as a resource exhaustion vulnerability resulting from improper handling of multipart form data requests. Specifically, the application fails to adequately validate or limit the complexity and size of malformed multipart request bodies during processing. When an attacker submits a specially crafted HTTP POST request with a maliciously constructed Content-Type header and body structure, the server's parser enters a state of excessive computational effort. This behavior leads to uncontrolled resource consumption, manifesting as high CPU utilization and potentially significant memory pressure on the hosting environment. The core technical issue stems from the underlying multipart parsing logic which does not implement sufficient safeguards against pathological inputs designed to trigger backtracking or infinite loops within the content type processing routine.
From an operational perspective, this vulnerability poses a direct threat to the availability of Payload CMS instances. By exploiting this flaw, an unauthenticated attacker can initiate a Denial of Service attack without requiring valid credentials. The impact is characterized by service degradation where legitimate users experience timeouts or complete inability to access the content management interface and API endpoints. In cloud-native environments or containerized deployments with strict resource limits, such attacks can cause automatic scaling events that inflate operational costs or trigger instance termination if thresholds are exceeded. This aligns closely with Common Weakness Enumeration (CWE) category CWE-400, which covers uncontrolled resource consumption, and specifically relates to the mechanism of causing a service to become unavailable through excessive processing time rather than crashing it outright.
The attack vector for this vulnerability is remote and network-accessible, requiring only an HTTP connection to the targeted Payload CMS instance. It falls under MITRE ATT&CK technique T1496, Resource Hijacking, where adversaries leverage system resources to disrupt service availability or consume budget in cloud environments. The lack of authentication requirement makes it particularly dangerous for public-facing deployments that do not have additional web application firewall rules specifically filtering malformed multipart requests before they reach the application layer.
Mitigation strategies primarily involve upgrading to patched versions immediately. Administrators should update Payload CMS to version 3.90.0 or later, or if using canary builds, ensure the version is at least 4.0.0-canary.34. For organizations unable to patch immediately due to dependency constraints, implementing a Web Application Firewall (WAF) rule that inspects and restricts multipart request sizes and validates Content-Type headers against expected formats can provide temporary protection. Additionally, configuring reverse proxies such as Nginx or Apache to limit the maximum allowed body size for POST requests can help mitigate the impact by preventing excessively large payloads from reaching the application server. Monitoring CPU usage patterns on servers hosting Payload CMS instances is also recommended to detect potential exploitation attempts early and trigger automated scaling or alerting mechanisms.