Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-10-06T16:17:06.540Z",
  "pubdate": "2026-10-06T16:17:06.540Z",
  "executiveSummary": "Payload CMS versions 3.0.0 through 3.87.x and canary versions prior to 4.0.0-canary.27 are susceptible to a SQL injection vulnerability within the SQLite and Postgres database adapters.\nThe vulnerability occurs when untrusted users execute queries against readable collections using dynamic filters or join operations, enabling the injection of malicious SQL commands.\nThis flaw allows an attacker to manipulate the underlying database queries, potentially leading to unauthorized data exposure, data modification, or complete database compromise.\nThe attack requires the ability to query collections, though it does not explicitly demand high-level administrative privileges depending on the implementation of collection access controls.\nRisk implications are high as successful exploitation bypasses application-level security, allowing arbitrary SQL execution in the context of the database user.\nUsers are strongly advised to update to version 3.88.0 or 4.0.0-canary.27 to remediate this security defect.",
  "technicalDetails": "The vulnerability stems from improper sanitization or parameterization of dynamic filtering and join inputs within the Payload CMS database abstraction layer, specifically affecting the SQLite and Postgres adapters.\nWhen a user performs a query, the application dynamically constructs SQL statements based on the provided query filters. In the vulnerable versions, these filters are not sufficiently sanitized before being concatenated into the raw SQL query strings, allowing for the injection of arbitrary SQL syntax.\nAttackers can leverage this by crafting malformed query parameters in an API request targeting accessible collections. By embedding specific SQL control characters or clauses (such as UNION SELECT, OR 1=1, or subqueries) into the filter object or join criteria, the attacker can force the database to execute unintended operations.\nThe attack flow follows a structured path: First, the attacker identifies a readable collection accessible via the application's API. Second, the attacker crafts an HTTP request containing a maliciously formatted JSON payload representing complex filter criteria or relational joins. Third, the Payload CMS query engine processes these criteria, failing to properly encapsulate the input before passing it to the database driver.\nThis lack of parameterization allows the injected SQL to break out of its intended data context. For example, by manipulating a join clause, an attacker may be able to traverse relational tables that they are not explicitly authorized to view, or by manipulating filters, they can extract sensitive information from the entire database schema.\nThis issue affects the core database integration logic in both SQLite and Postgres adapters, indicating that the failure occurs during the translation of high-level API filter objects into low-level SQL statements. Exploitation is possible through standard API interactions, making it accessible to any user capable of querying the collection endpoints.\nThe impact of a successful injection includes, but is not limited to, the exposure of PII (Personally Identifiable Information), credentials, or internal configuration data stored within the database. Furthermore, if the database user possesses sufficient permissions, an attacker might be able to perform data modification or deletion, leading to an integrity compromise of the content management system."
}