CVE-2023-52128 is a medium severity (4.3 CVSS) cross-site request forgery flaw in the White Label plugin for WordPress, in versions through 2.9.0. Patchstack lists 2.9.1 as the patched release, so update to 2.9.1 or later. Exploitation needs a signed-in privileged user to be tricked into sending a request.
What's affected
The NVD record covers White Label from WhiteWP, a plugin for custom admin, login page and dashboard branding, in all versions through 2.9.0. Patchstack agrees on the vulnerable range and names 2.9.1 as the patched version.
The record classifies the weakness as CWE-352 (Cross-Site Request Forgery). The CVSS vector in the record is network based with no privileges required but with user interaction required, and it scores low confidentiality, high integrity impact. The advisory does not say which plugin action lacks the check, so assume any admin screen of the plugin could be involved until you have updated.
How to check if you're exposed
On a site you manage, list installed plugins and their versions with wp-cli:
wp plugin list --fields=name,version,update_version,status
wp plugin get white-label --field=version
The slug white-label comes from the Patchstack advisory address. Confirm it matches the folder name under wp-content/plugins on your site. If the version is 2.9.0 or lower, the site is in the affected range. You can also read the version on the Plugins screen of the WordPress dashboard.
For agencies, run the same listing across every client site and collect the results in one sheet. Plugins that are installed but inactive still count as inventory.
What to do now
- Take a backup or snapshot before changing anything.
- Update White Label to 2.9.1 or later, from the dashboard or with
wp plugin update white-label. - If the plugin is unused, deactivate and delete it instead of updating it.
- Review recent changes in the plugin settings and look for administrator accounts you do not recognise.
- Ask administrators to use a separate browser profile for admin work and to sign out when finished, which shrinks the window a forged request needs.
Why it matters
Cross-site request forgery means a site accepts a state-changing request without checking that the logged-in user meant to send it. A browser attaches the user's session cookie to any request aimed at that site, including one triggered from a page the attacker controls. If the plugin does not require an anti-forgery token on the action, the request goes through.
Patchstack describes the issue as low priority and unlikely to be exploited, while the CVSS score in the record is 4.3. Both can be true. The score reflects what a successful forged request could do, and the priority label reflects how likely that is in practice. Treat the fix as routine maintenance that should still happen this week. The KEV flag in the record is false, and none of the sources we read claim exploitation in the wild.
Quick check
Do I need to be logged in as an admin for this to matter?
The attack works through a logged-in privileged user whose browser is tricked into sending a request. The attacker does not need an account of their own. A site with no signed-in privileged users at the moment is a harder target, but that is not a fix.
Is a firewall rule enough instead of updating?
A web application firewall can block some forged requests, but the fix is the patched plugin release. Use a rule as a stopgap if you cannot update today, then update.
Sources
Last reviewed: 19 October 2026.
