Description

The Custom Field Template plugin for WordPress is vulnerable to generic SQL Injection via the 'post_ID' parameter in all versions up to, and including, 2.7.8 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 contributor-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 capability check via current_user_can('edit_post', $id) is bypassable because WordPress internally casts $id to an integer for the permission evaluation while the full unsanitized string is preserved and passed to the SQL sink, and a valid nonce — which is also required — can be legitimately obtained by any Contributor-level user from the post edit screen.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-19T08:16:55.487Z",
  "pubdate": "2026-09-19T08:16:55.487Z",
  "executiveSummary": "The Custom Field Template plugin for WordPress, in versions up to and including 2.7.8, contains a critical SQL Injection (SQLi) vulnerability.\nThis vulnerability stems from improper input sanitization of the 'post_ID' parameter, allowing authenticated attackers with Contributor-level privileges or higher to execute arbitrary SQL commands.\nThe security risk is high, as it enables unauthorized database access, potentially leading to sensitive data exfiltration.\nThe exploitation path relies on the mismatch between WordPress's internal integer casting during authorization checks and the subsequent usage of the unsanitized string within the SQL sink.\nSuccessful exploitation requires the attacker to possess a valid nonce, which is natively accessible to users with Contributor roles via the WordPress post edit screen, making this an accessible attack vector for malicious internal actors or compromised accounts.\nThe vulnerability effectively bypasses the intended capability checks, as the system validates the ID as an integer for permission purposes but processes the malicious payload as a raw string during database interactions.",
  "technicalDetails": "The vulnerability originates from the improper handling of the 'post_ID' parameter within the Custom Field Template plugin. The application fails to apply sufficient escaping or utilize prepared statements when constructing SQL queries using user-supplied data.\nThe root cause is a type-juggling discrepancy between the authorization logic and the database execution logic. When WordPress executes current_user_can('edit_post', $id), it internally casts the $id parameter to an integer. This integer casting effectively masks the malicious payload, allowing the attacker to pass the capability check for a legitimate post ID.\nHowever, after the authorization gate, the original, unsanitized string representation of the 'post_ID' parameter is passed directly to the SQL sink. Because the underlying SQL query is constructed using string concatenation rather than parameterized queries, the unsanitized string allows for the injection of arbitrary SQL syntax.\nAttackers can leverage this to terminate the legitimate query and append additional malicious statements, such as UNION-based SQL injections, to query information from other tables within the WordPress database. This allows for the retrieval of configuration details, user credentials, or other sensitive records stored in the database.\nThe attack flow follows these steps: First, the attacker navigates to the post edit screen to acquire a valid nonce, which is a prerequisite for the plugin's action. Second, the attacker crafts a malicious request containing a specially formatted string in the 'post_ID' parameter. Third, the plugin performs the current_user_can('edit_post', $id) check, where the integer cast succeeds because the string starts with or contains a numeric representation of an authorized post. Fourth, the backend processes the raw string into an SQL query, triggering the injection. Finally, the database executes the appended query, returning the requested unauthorized data to the attacker.\nThis vulnerability is particularly concerning because it bypasses standard permission mechanisms, allowing a user with minimal privileges (Contributor) to perform actions that should be restricted to administrative roles."
}