CVE-2025-1570 is a high severity account takeover flaw in the Directorist WordPress plugin, versions up to and including 8.1. The password reset one time code can be brute forced, which lets an unauthenticated attacker change a user's password. NVD scores it 8.1. Update to a release newer than 8.1.
What's affected
The record lists Directorist, the AI powered business directory and classified ads plugin from WPWax, in all versions up to and including 8.1. That means a release after 8.1 is where the fix lives. The record points to a WordPress plugin changeset for the change, but we could not read that page, so confirm the exact fixed version in the plugin's changelog on WordPress.org before you record the site as fixed.
How to check if you're exposed
From each site's root, list the installed version of the plugin.
wp plugin list --fields=name,status,version | grep directorist
Anything at 8.1 or lower is in scope. If the plugin is present, also check for signs of misuse. Look at recent password reset activity in your logs and at whether any administrator accounts have changed.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
The vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H) marks attack complexity as high and requires no account at all. The high complexity reflects the guessing involved in the attack, not any barrier that makes it safe to wait.
What to do now
- List every site running Directorist and note the version.
- Update the plugin to the newest release and confirm in the changelog that it is later than 8.1.
- Review the administrator and editor accounts. Remove any you do not recognise and reset passwords for admins if you see signs of a reset you did not request.
- Add rate limiting or a login protection layer in front of password reset requests, and consider a second factor for administrators.
- Check that your site sends reset emails only for real requests, and review your logs for bursts of reset attempts.
- Add the plugin to your automatic update list so the next fix lands without a ticket.
Why it matters
The weakness is CWE-640, weak password recovery mechanism for forgotten password. The two functions named in the record, directorist_generate_password_reset_pin_code() and reset_user_password(), do not do enough to stop repeated guessing of the one time code, and do not verify that the reset request came from an authorized user.
Short numeric codes are fine only if the number of tries is limited. Without a cap, a script can work through the possibilities. The result is account takeover, and on a directory site that can mean control over listings, user data and in some cases administrator rights. The record scores confidentiality, integrity and availability impact as high. It is not on the CISA KEV list.
The fix pattern for this class is well known: limit attempts per account and per address, expire codes quickly, make them longer or less guessable, and tie the reset to a token that proves the request started with the real owner.
Going further
Account takeover bugs are quiet. There is no crash and no error page, only a password that changed. That makes log review more important than usual. Keep logs of reset requests for at least a month and alert on many requests for one account in a short window.
If your directory has paying listers or public submissions, tell your support team about the issue. They will be the first to hear about an account that suddenly stopped working.
Teams sometimes ask whether they need to reset every password after an update. The answer depends on evidence. If logs show bursts of reset attempts, or an account changed without a request from its owner, reset the affected accounts and the administrators. If there is no sign of misuse, updating and watching is reasonable.
Longer term, treat password reset as part of your security perimeter. Test it as you would login: rate limits, lockout, code length and expiry. Plugins that add their own reset flow bypass the protections of WordPress core, so each one deserves a look.
Safeguard Gold lists this CVE with linked weaknesses, and the free in-browser scan at https://gold.safeguard.sh/scan helps with the dependencies in the code you build. For WordPress plugins, the WP-CLI steps above are the quickest way to see your exposure.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which version fixes it?
The record says versions up to and including 8.1 are affected, so anything later is the target. Confirm the exact release in the plugin changelog.
Why does the score say complexity is high?
Because the attack depends on guessing a code, not on a single request. It is still practical when attempts are not limited, so do not treat high complexity as a reason to delay.
Sources
Last reviewed: 19 October 2026.
