CVE-2026-119325 in Theme Plugin
Summary
by MITRE • 10/29/2026
Bricks Theme 2.4 and before for WordPress contains an unauthenticated broken access control vulnerability in the load_popup_content REST endpoint that allows anonymous attackers to read draft and unpublished page content by supplying a popupId parameter without any status or capability checks. Attackers can obtain a public nonce via the bricks_regenerate_query_nonce action and then increment the popupId value in requests to the /wp-json/bricks/v1/load_popup_content endpoint to enumerate and disclose confidential content from any unpublished post on the site.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The Bricks Theme for WordPress, specifically versions 2.4 and earlier, contains a critical unauthenticated broken access control vulnerability within its REST API implementation. This flaw resides in the load_popup_content endpoint, which is designed to retrieve dynamic content for popups created by theme users. The core technical deficiency lies in the absence of proper authorization checks when processing requests that include a popupId parameter. Instead of verifying whether the requesting user has the necessary capabilities or permissions to access specific post data, the server blindly processes the request based solely on the provided identifier. This architectural oversight allows anonymous attackers who are not logged into the WordPress administration area to interact with sensitive backend logic as if they were authenticated users with elevated privileges.
The operational impact of this vulnerability is significant because it enables information disclosure of draft and unpublished content that should remain private until explicitly published or shared by authorized editors. By exploiting this flaw, an attacker can enumerate valid popup identifiers through simple iteration techniques. Once a valid identifier is discovered, the attacker can retrieve the full HTML structure, embedded scripts, stylesheets, and any other data associated with that specific popup. This includes sensitive business logic, internal URLs, API keys potentially hardcoded in templates, or personal information contained within draft pages. The ability to read unpublished content undermines the fundamental trust model of WordPress, where drafts are intended to be invisible to public visitors until they are officially published by an administrator or editor.
To successfully exploit this vulnerability, attackers must first obtain a valid nonce value for the bricks_regenerate_query_nonce action. This nonces mechanism is typically used in WordPress to prevent Cross-Site Request Forgery attacks and ensure that requests originate from legitimate sources within the application context. However, because the load_popup_content endpoint does not validate these nonces against user sessions or capabilities, obtaining a valid nonce via public endpoints allows attackers to bypass standard CSRF protections. With this nonce in hand, an attacker can incrementally adjust the popupId parameter in HTTP POST requests sent to /wp-json/bricks/v1/load_popup_content. This systematic enumeration leads to the complete exposure of confidential content stored on the server but not intended for public consumption.
From a classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures in authorization checks that allow unauthorized access to resources. It also maps closely to MITRE ATT&CK technique T1078, Valid Accounts, although the exploitation occurs without valid credentials by abusing public-facing API endpoints. The scenario represents a classic case of broken object level permissions where the system fails to verify if the actor is authorized to perform the requested action on the specific data instance identified by the popupId. This type of vulnerability is particularly dangerous in content management systems because it exposes the internal structure and potentially sensitive logic before any public release occurs, giving attackers valuable intelligence for further exploitation or social engineering attacks.
Mitigation strategies must focus on immediate patching to a version of Bricks Theme that addresses this authorization gap. Administrators should ensure they are running software where the load_popup_content endpoint strictly validates user capabilities such as edit_posts or publish_pages before returning any data. In cases where upgrading is not immediately feasible, temporary workarounds include disabling REST API access for unauthenticated users if possible through server-level configurations or security plugins that restrict specific endpoints. Additionally, implementing strict rate limiting on the affected endpoint can mitigate enumeration attacks by slowing down the process of guessing valid popupIds. Regular audits of custom theme code and third-party plugin integrations are essential to identify similar patterns where REST API handlers lack proper capability checks against global user objects.