Description

The Post Grid Gutenberg Blocks WordPress plugin before 5.0.41 does not perform an authorization or post-visibility check on a REST API route that returns the custom field keys of a given post, allowing unauthenticated users to disclose the custom field key names of arbitrary posts, including private, draft, pending, scheduled and password-protected posts.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-09-23T06:17:04.130Z",
  "pubdate": "2026-09-23T06:17:04.130Z",
  "executiveSummary": "The Post Grid Gutenberg Blocks WordPress plugin, specifically in versions prior to 5.0.41, contains an improper access control vulnerability within its REST API implementation.\nThis vulnerability allows unauthenticated remote attackers to query a specific API endpoint to retrieve custom field key names associated with arbitrary posts.\nThe flaw affects the confidentiality of the WordPress database schema as it pertains to custom post metadata, exposing information for posts regardless of their visibility status, including private, draft, pending, scheduled, or password-protected entries.\nNo authentication or authorization checks are performed by the affected REST API route, facilitating exploitation by any remote user without elevated privileges.\nThe primary risk implication is the unauthorized disclosure of sensitive internal metadata, which can be leveraged to map the site structure, identify third-party plugin integration points, or facilitate further targeted exploitation of specific custom fields.",
  "technicalDetails": "The vulnerability resides within the REST API controller logic of the Post Grid Gutenberg Blocks plugin. The plugin exposes an endpoint intended to facilitate the retrieval of custom field metadata for the Gutenberg block editor interface. However, the implementation of this REST API route fails to enforce proper capability checks or post-visibility verification.\nThe root cause is a missing authentication and authorization gate in the handler function associated with the metadata retrieval route. In standard WordPress development, accessing post metadata through the REST API should typically require permissions such as 'edit_posts' or specific checks to ensure the requesting user has the authority to view the post object in question. The plugin fails to invoke these checks, resulting in the exposure of data for any post ID supplied in the request.\nThe exploitation flow is straightforward: An unauthenticated attacker sends a GET request to the vulnerable REST API endpoint. The request includes parameters defining the target post ID. Because the plugin does not validate the session or the user's privilege level, the server-side controller proceeds to query the WordPress database for the custom fields associated with the requested ID using standard WordPress functions (such as get_post_custom_keys). The controller then serializes the internal metadata keys and returns them in the JSON response body.\nAffected versions include all iterations of the plugin prior to 5.0.41. The vulnerability is network-accessible, as the REST API endpoints are public-facing by default in standard WordPress configurations. The impact is significant because it grants attackers visibility into the site's back-end configuration. By discovering custom field names, an attacker can identify what plugins are being used, understand how the site handles specific data, and potentially identify vectors for SQL injection, cross-site scripting, or privilege escalation if those custom fields are improperly handled elsewhere in the stack.\nThe attack does not require complex payloads; it relies purely on the lack of server-side restrictions on public REST API access. Upon exploitation, the attacker receives a list of internal key-value labels, which effectively reveals private system architecture information that should remain restricted to authorized administrators or content editors."
}