Description

The Create plugin for WordPress is vulnerable to generic SQL Injection via the 'order' parameter in all versions up to, and including, 2.5.3 due to insufficient escaping on the user supplied parameter and lack of sufficient preparation on the existing SQL query. This makes it possible for authenticated attackers, with author-level access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database. The vulnerable advanced-filter SQL branch is only entered when at least one of the following parameters is present in the request: linked_posts, created_after, created_before, missing_fields, post_id, a comma-separated type value, or exclude_type.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-19T08:16:52.200Z",
  "pubdate": "2026-09-19T08:16:52.200Z",
  "executiveSummary": "The Create plugin for WordPress, in versions up to and including 2.5.3, is susceptible to an authenticated SQL injection vulnerability.\nThis vulnerability stems from the improper sanitization and lack of parameterized queries when handling user-supplied input via the 'order' parameter.\nSuccessful exploitation allows an authenticated attacker with author-level privileges or higher to manipulate backend database queries, potentially leading to unauthorized data extraction.\nThe vulnerability is conditioned upon the presence of specific additional parameters that trigger the application's advanced-filter SQL branch.\nRisk implications include the exposure of sensitive database content and the potential for unauthorized data access or modification, depending on database permissions.\nThe attack is limited to authenticated users, requiring a minimum of author-level access, thereby restricting the threat vector to internal or registered malicious actors.",
  "technicalDetails": "The vulnerability resides within the Create plugin's query construction logic, specifically where the 'order' parameter is processed. The root cause is the failure to implement adequate input validation or parameterization on this parameter, allowing user-supplied input to influence the structure of the SQL query directly.\nThe vulnerable code path is nested within the plugin's advanced-filter SQL branch. This branch is conditionally executed by the application logic only when specific input parameters—specifically 'linked_posts', 'created_after', 'created_before', 'missing_fields', 'post_id', 'type' (when provided as a comma-separated value), or 'exclude_type'—are present in the HTTP request. When these conditions are met, the 'order' parameter is concatenated into the SQL statement without sufficient escaping, facilitating SQL injection.\nExploitation requires an authenticated session with at least author-level privileges. An attacker initiates the attack by crafting a malicious HTTP request that includes the 'order' parameter containing a SQL payload, alongside one of the mandatory triggering parameters to ensure the vulnerable code path is reached. Because the application fails to use prepared statements for the 'order' parameter, the database driver processes the malicious input as part of the intended query command.\nThe injection allows an attacker to append arbitrary SQL commands to the original query. By leveraging UNION-based SQL injection techniques or error-based extraction, an attacker can bypass standard query logic to retrieve data from other tables within the WordPress database. This may include sensitive user information, configuration details, or other private records stored in the database.\nThe attack flow follows a structured sequence: 1) The attacker authenticates as a user with sufficient privileges (author level or higher). 2) The attacker identifies the target endpoint and crafts a request containing one of the required triggers (e.g., 'post_id') and a malicious SQL payload injected into the 'order' parameter. 3) The backend server receives the request, identifies the presence of the trigger, and enters the vulnerable SQL generation branch. 4) The unvalidated 'order' input is concatenated into the query, executing the attacker's injected SQL commands. 5) The server processes the manipulated query and returns the unauthorized data or reflects the injection result in the application response, enabling post-exploitation data extraction."
}