CVE-2023-52129 is a medium severity (6.3 CVSS) cross-site request forgery flaw in the teachPress plugin for WordPress, in versions through 9.0.4. Patchstack lists 9.0.5 as the patched release, so update to 9.0.5 or later. Exploitation needs a signed-in privileged user to be tricked into sending a request.
What's affected
The NVD record covers teachPress from Michael Winkler, the teachPress plugin, in all versions through 9.0.4. Patchstack agrees on the vulnerable range and names 9.0.5 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, low availability 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 teachpress --field=version
The slug teachpress comes from the Patchstack advisory address. Confirm it matches the folder name under wp-content/plugins on your site. If the version is 9.0.4 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 teachPress to 9.0.5 or later, from the dashboard or with
wp plugin update teachpress. - 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
With cross-site request forgery, the attacker never needs the victim's password. The attacker only needs the victim's browser to send a request while a session is open. A plugin that accepts such requests without verifying a per-user token trusts the browser too much.
The record scores this at 6.3, and Patchstack rates it low priority. The gap is normal for CSRF: the attack needs the victim to be signed in and to open a hostile page, which lowers the odds even when the impact on a site is real. It is still a one-click update, so there is little reason to wait. The KEV flag in the record is false, and none of the sources we read claim exploitation in the wild.
Fixing a version number is the easy part. The harder part is knowing which sites run the plugin at all. Keep an inventory of plugins with versions and owners, and re-run it whenever an advisory like this one appears. For a wider view of your own code, the free in-browser dependency scan and the Gold directory show which packages carry known CVEs, and reachability analysis helps you decide which findings to fix first. WordPress plugins installed from the admin screen do not sit in a manifest, so start with the wp-cli inventory above for those.
Quick check
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.
What if I no longer use the plugin?
Deactivate and delete it. Inactive plugins still sit on disk, and their files can remain reachable on some setups, so removal is safer than leaving them deactivated.
Sources
Last reviewed: 19 October 2026.
