CVE-2026-105845 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.88.0 and canary versions before 4.0.0-canary.27, an untrusted user who can query readable collections through dynamic filters or joins can submit a request that causes SQL injection in the SQLite and Postgres adapters. This issue is fixed in versions 3.88.0 and 4.0.0-canary.27.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS, a popular open-source headless content management system built on Node.js, suffered from a critical SQL injection vulnerability affecting multiple releases prior to the patched versions. The flaw resided within the query handling mechanisms of both the SQLite and PostgreSQL database adapters, specifically triggered when users with permission to read collections utilized dynamic filters or join operations. This architectural weakness allowed an untrusted user who possessed basic read access to manipulate the underlying SQL queries constructed by the application framework. By injecting malicious syntax into filter parameters or join conditions, attackers could bypass intended data isolation boundaries, potentially extracting sensitive information from other tables within the same database schema that were not originally accessible through standard API endpoints.
The technical root cause of this vulnerability stems from improper neutralization of special elements used in SQL commands, a classic flaw categorized under CWE-89: Improper Neutralization of Special Elements used in an SQL Command. In dynamic query builders like those employed by Payload CMS, user-supplied input is often directly interpolated into SQL statements without sufficient sanitization or parameterization when handling complex queries involving joins and filters. When the application constructs a SELECT statement to retrieve data based on these inputs, it fails to properly escape characters such as single quotes or semicolons that could alter the query's logic. This allows an attacker to terminate the original intended query and append arbitrary SQL commands, effectively turning the database into an attack vector for unauthorized data access rather than just a storage medium.
The operational impact of this vulnerability is severe due to its potential for remote code execution via stored procedures or direct exfiltration of sensitive business logic and user credentials. Since Payload CMS often manages administrative content, customer data, and internal configurations, the ability to read arbitrary tables compromises the confidentiality integrity of the entire system. An attacker could dump database contents, including hashed passwords, API keys, or personally identifiable information, leading to significant regulatory compliance violations such as GDPR or HIPAA breaches depending on the jurisdiction and data type involved. Furthermore, in some database configurations, SQL injection can be chained with other vulnerabilities to achieve remote code execution, granting full control over the server hosting the CMS instance.
This vulnerability aligns closely with MITRE ATT&CK technique T1059: Command and Scripting Interpreter, specifically through the sub-technique of Database Commands (T1059.007), as it involves using SQL syntax to interact directly with the database engine outside of normal application logic. It also reflects aspects of T1213: Data from Information Repositories, where adversaries leverage compromised systems to query databases for valuable information. The attack vector is classified under Remote Code Execution via Input Manipulation, requiring only network access and valid read credentials, which makes it particularly dangerous in multi-tenant environments or public-facing deployments where user registration is open.
Mitigation strategies must prioritize immediate upgrading to the fixed versions of Payload CMS, specifically version 3.88.0 for the stable branch or version 4.0.0-canary.27 and later for development branches. For organizations unable to upgrade immediately due to dependency constraints, implementing a Web Application Firewall (WAF) with rulesets tuned to detect SQL injection patterns in query parameters can provide temporary protection against exploitation attempts. Additionally, developers should enforce strict input validation on all filter fields and join conditions at the application layer, ensuring that only whitelisted values are processed. Adopting parameterized queries or prepared statements for any custom code interacting with these adapters is essential to prevent similar issues from arising in future development cycles. Regular security audits focusing on ORM usage patterns and dynamic query construction will further harden the system against evolving SQL injection techniques.