CVE-2026-124673 in Burst Statistics Plugin
Summary
by MITRE • 11/15/2026
The Burst Statistics WordPress plugin before 3.7.5 does not check that a reported page view belongs to published content, nor check post status before listing post titles and links in its public statistics output, allowing unauthenticated attackers to disclose the titles and permalinks of draft, pending and private posts.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 11/15/2026
The vulnerability identified in Burst Statistics versions prior to 3.7.5 represents a significant information disclosure flaw rooted in insufficient input validation and access control mechanisms within the plugin's public-facing statistics endpoint. The core technical deficiency lies in the application logic that processes requests for post metadata without verifying the publication status of the targeted content. When an unauthenticated user submits a request to retrieve page view data, the backend script fails to cross-reference the reported page identifier against the WordPress database constraints regarding post visibility states such as draft, pending review, or private. This oversight allows the system to return sensitive structural information about unpublished material alongside publicly accessible statistics, effectively bypassing standard content access controls that are typically enforced by the main application framework during normal browsing sessions.
From a technical perspective, this flaw is classified under CWE-200: Exposure of Sensitive Information to an Unauthorized Actor and aligns with CWE-611: Improper Restriction of XML External Entity Reference if interpreted broadly as improper restriction of access, though more accurately it falls under CWE-863: Incorrect Authorization. The attacker exploits this by sending crafted HTTP requests that mimic legitimate statistic collection calls but target internal or unpublished post IDs. Because the plugin does not validate whether the requested resource is marked for public consumption in the database before generating its response, the application inadvertently leaks permalinks and titles of content that administrators intended to keep confidential during development or review phases. This behavior contradicts the principle of least privilege and fails to enforce proper authorization checks at the data retrieval layer.
The operational impact of this vulnerability extends beyond simple metadata leakage. By exposing the structure and topics of unpublished posts, attackers can gain valuable intelligence regarding a website's content strategy, upcoming product launches, or internal communications that have not yet been finalized. This information aids in reconnaissance activities, allowing adversaries to map out potential attack surfaces more accurately by identifying specific endpoints or features associated with those drafts. Furthermore, knowledge of private post titles and permalinks may facilitate targeted phishing campaigns or social engineering attacks against site administrators if the content hints at sensitive organizational matters. The lack of authentication requirement means that this exploitation can be performed remotely by any internet user without prior credentials, significantly lowering the barrier to entry for malicious actors.
To mitigate this risk, immediate remediation involves upgrading Burst Statistics to version 3.7.5 or later where these access control checks have been implemented. Administrators should also ensure that all WordPress plugins are kept up to date with security patches released by their vendors. In environments where updating is not immediately feasible, temporary mitigations include restricting access to the plugin's AJAX endpoints via web application firewall rules if such functionality is available and configured correctly. Additionally, implementing strict logging and monitoring for unusual patterns of requests targeting non-public post IDs can help detect exploitation attempts in real-time. Regular security audits focusing on authorization logic within public-facing APIs are essential to prevent similar vulnerabilities from persisting in custom or third-party codebases.