CVE-2026-105844 in PayloadCMS
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.88.0 and canary versions before 4.0.0-canary.27, an unauthenticated user can submit prototype-sensitive field paths when @payloadcms/plugin-import-export is enabled, causing unintended application behavior that can lead to remote code execution. This issue is fixed in versions 3.88.0 and 4.0.0-canary.27.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS represents a popular headless content management system built on Node.js, widely adopted for its flexibility and developer-friendly API structure. The vulnerability identified within this platform affects specific legacy versions ranging from 3.0.0 up to but not including 3.88.0, as well as canary releases prior to version 4.0.0-canary.27. This security flaw is specifically tied to the activation of the @payloadcms/plugin-import-export module, which facilitates data migration and backup operations by allowing users to import content from external sources such as JSON or CSV files. While this functionality is essential for administrative workflows, it introduces a critical attack surface when input validation mechanisms are insufficiently rigorous against sophisticated injection techniques.
The core technical flaw stems from an improper neutralization of special elements during the processing of imported data fields. Specifically, unauthenticated attackers can submit prototype-sensitive field paths within the import payload. In JavaScript-based environments like Node.js, object prototypes contain properties that define behavior for all objects created using a particular function or constructor. By manipulating these path structures to target internal prototype chains, an attacker can inject malicious property names that bypass standard validation checks. This technique leverages the dynamic nature of JavaScript object resolution, where accessing a non-existent property on an object triggers a lookup up the prototype chain. If the application code naively merges incoming data into existing objects without sanitizing keys that resemble prototype properties such as _proto_, constructor, or prototype itself, it can inadvertently modify global object behaviors rather than just local document fields.
This vulnerability is classified under CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes, which encompasses issues where an application allows modification of internal state through untrusted input that targets structural elements like prototypes. The exploitation vector aligns with ATT&CK technique T1059 Command and Scripting Interpreter, as the ultimate goal is to achieve Remote Code Execution by altering how JavaScript interprets object properties. When prototype pollution occurs in a server-side application, it can lead to severe consequences including denial of service through infinite loops or property overwrites that break core functionality. More critically, if the payload includes methods or functions within the polluted objects, these may be executed during subsequent operations such as serialization, logging, or template rendering, thereby granting the attacker arbitrary code execution capabilities on the host system without requiring any authentication credentials.
The operational impact of this vulnerability is severe due to its unauthenticated nature and potential for remote code execution. An adversary does not need valid login credentials to exploit this flaw; they only require network access to the Payload CMS instance and knowledge that the import-export plugin is enabled. Once exploited, the attacker can compromise the integrity of the entire application state by polluting global prototypes. This may lead to data corruption, privilege escalation if other parts of the codebase rely on polluted objects for security checks, or complete system takeover through command injection via crafted object properties. The lack of authentication requirements makes this vulnerability particularly dangerous in public-facing deployments where automated scanners can easily discover and exploit such flaws at scale.
Mitigation strategies must prioritize immediate version upgrades to resolve the underlying input validation deficiencies. Administrators running affected versions should upgrade Payload CMS to 3.88.0 or later, or migrate to a stable release of version 4.x that is equal to or greater than 4.0.0-canary.27. These updated releases include patches that properly sanitize and validate field paths during the import process, ensuring that prototype-sensitive keys are either rejected or safely handled without affecting global object prototypes. For organizations unable to upgrade immediately due to compatibility constraints, disabling the @payloadcms/plugin-import-export module effectively removes the attack vector by eliminating the code path through which malicious payloads are processed. Additionally implementing strict input validation at the API gateway level and monitoring for anomalous request patterns involving nested or unusual key structures can provide an additional layer of defense against prototype pollution attempts until a permanent fix is deployed.