Burst Statistics EUVD-2026-91950

Exploitation requires the attacker to possess a valid burst_share_token - specifically one that has been shared publicly or distributed to an untrusted party; sites that never generate or circulate share tokens are not exposed. The flaw is reachable because the maybe_load_shared_dashboard() handler issues a real wp_set_auth_cookie() session for the burst_statistics_viewer account, and the plugin only blocks Application Passwords for the burst_viewer role while leaving the core /wp-json/wp/v2/users/me password-update endpoint and the edit_user self-service capability unrestricted. Limiting factors: no WordPress user interaction is needed (UI:N), but the compromised account is limited-privilege (view_burst_statistics only), the token prerequisite prevents mass/automatable exploitation, and only versions up to and including 3.7.1 are affected (fixed in 3.7.2).

This is a genuine but low-to-moderate priority issue, not a drop-everything emergency. The signals are mostly consistent on low real-world severity: the provided CVSS base score is 4.3 (Medium), and the vulnerable asset is only the limited-privilege burst_statistics_viewer account whose sole capability is view_burst_statistics - there is no path to admin, RCE, or site-wide data in the CVE as described (C:N/A:N, I:L). No EPSS score, KEV listing, or POC was provided, so exploitation status is 'no public exploit identified at time of analysis.' The most important caveat is a conflict between the provided CVSS vector and the description: the vector contains PR:L (implying an authenticated attacker), yet the description repeatedly calls the attacker 'unauthenticated' and instead gates exploitation on possession of a valid burst_share_token - a distributed secret rather than a WordPress credential. These two signals should be reconciled with the vendor: in practice the real prerequisite is token possession, not a WordPress login. The true differentiator of this bug is persistence, not access level - a share token is meant to grant temporary, revocable viewing, but this flaw converts it into a permanent WordPress account the defender cannot evict via token revocation, expiration, or the daily cleanup_viewer_sessions() routine. Prioritize patching where share tokens have been circulated to untrusted parties; deprioritize where the share feature is unused.

An organization shares a Burst Statistics dashboard link containing a burst_share_token with a contractor or posts it semi-publicly. The recipient visits the shared-dashboard handler, is handed a genuine WordPress auth cookie for the burst_statistics_viewer account, and then calls the core /wp-json/wp/v2/users/me endpoint to set a password of their choosing. No POC was provided in the source data, and with AV:N/AC:L the request sequence is straightforward once the token is held, but it is not an automatable drive-by since a valid share token must first be obtained.