Description

The Custom Field Template plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.7.8 via the edit_meta_value due to missing validation on a user controlled key. This makes it possible for authenticated attackers, with contributor-level access and above, to delete arbitrary media attachments site-wide by supplying any numeric attachment ID in the file-field parameter alongside the corresponding delete flag, causing content loss and broken pages. Exploitation requires that the attacker's post is governed by a Custom Field Template containing at least one file-type field with the mediaRemove option not enabled, which is the default configuration for file fields.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-09-22T08:16:36.400Z",
  "pubdate": "2026-09-22T08:16:36.400Z",
  "executiveSummary": "The Custom Field Template plugin for WordPress is susceptible to an Insecure Direct Object Reference (IDOR) vulnerability in all versions up to and including 2.7.8. The flaw exists within the edit_meta_value function, where the application fails to perform sufficient server-side validation on user-supplied input parameters.\nThis vulnerability allows authenticated users with contributor-level privileges or higher to delete arbitrary media attachments globally across the WordPress installation. By submitting a crafted request containing a numeric attachment ID and an associated deletion flag, an attacker can bypass access controls to destroy site media assets.\nSuccessful exploitation requires that a post managed by the attacker is associated with a Custom Field Template containing at least one file-type field where the mediaRemove option is not explicitly disabled. Given that mediaRemove is disabled by default in these fields, the attack surface is broad. The primary impact is unauthorized content loss, leading to broken page assets and potential disruption of site operations.",
  "technicalDetails": "The root cause of this vulnerability is the improper implementation of authorization checks within the edit_meta_value function of the Custom Field Template plugin. The plugin fails to verify whether the authenticated user has the necessary ownership or permissions over the specific media attachment targeted in a metadata update request.\nThe attack vector involves manipulating the file-field parameter during a post-editing session. When a user interacts with a post governed by the Custom Field Template, they can transmit requests to the server to update metadata associated with file fields. Due to the lack of validation, the backend process accepts a user-provided numeric attachment ID paired with a deletion trigger.\nStep-by-step, the attack flow is as follows: 1) An attacker with at least contributor-level access identifies a post or page associated with a Custom Field Template configuration containing a file-type field. 2) The attacker intercepts the request sent to the server when modifying the post metadata. 3) The attacker modifies the parameters, specifically targeting the file-field identifier, to inject a valid, arbitrary numeric ID corresponding to any existing media attachment in the WordPress media library. 4) By toggling the deletion flag (associated with the 'mediaRemove' logic), the plugin's backend process proceeds to execute the removal function without verifying if the user has permission to delete that specific attachment. 5) The WordPress system executes the deletion of the attachment record and the associated binary file from the server storage.\nThe vulnerability is present in versions up to and including 2.7.8. It is exacerbated by the default configuration of the plugin, where file-type fields include the capability for media removal without sufficient input sanitization or access control logic. The exploitation occurs over standard HTTP/HTTPS channels, requiring the attacker to be authenticated as a contributor. Post-exploitation impact includes permanent data loss of media files, which leads to broken image links and potential site-wide disruption. Because the vulnerability does not check ownership, an attacker can enumerate and delete attachments they did not upload, essentially allowing for the destruction of the site's media library."
}