Disable User Login – Vulnerability found in 1.3.7.

While the plugin has always had nonce validation that prevents Cross Site Request Forgery, we just released v1.3.8 which adds user-specific nonce validation for each user row in the admin table to improve this and address any potential issue.

Please update to 1.3.8 at your earliest convenience.

It’s worth noting that Patchstack which is the source for WordPress Defender and some other security scanning plugins has already had a history of incorrectly flagging plugins for CSRF vulnerabilities, which is made worse by their “bounty” program which rewards those who find vulnerabilities. If you visit their site for a specific vulnerability and try to “claim” the plugin, it then wants to walk you through an on-boarding process of setting up a “Security Program” for your WordPress plugin, which appears to be a way to grow their usage and market share.

In this specific case, we already had CSRF protection in our plugin for the one ajax call that our plugin utilizes. We have always used the standard check_ajax_referer method which performs a nonce verification and referer validation to prevent cross-site request forgery, followed by a security check using current_user_can to ensure the authenticated user is allowed to perform the action for the specified user. Furthermore, the Patchstack vulnerability detail page (https://patchstack.com/database/vulnerability/disable-user-login/wordpress-disable-user-login-plugin-1-3-7-cross-site-request-forgery-csrf-vulnerability) didn’t provide any details other than saying that the finder (qilin_99) verified it. It claims the required privileges are “Unauthenticated” when our plugin only exposes an ajax hook for authenticated requests and doesn’t expose the nopriv version that would needed for handling unauthenticated ajax requests.

So, in short, we believe this was an incorrectly reported vulnerability, but did add a more defensive check where we generate a unique nonce for each user row in the admin table and pass that to the ajax endpoint instead of a single global nonce for the entire page. However, there is still no fundamental difference in the behavior and we don’t believe there was any risk of CSRF as we attempted to break it by providing in invalid nonce, an invalid action and even triggering a post from an incorrect referer and were unable to bypass the nonce and CSRF validation.

• This reply was modified 10 months, 2 weeks ago by Saint Systems.
• This reply was modified 10 months, 2 weeks ago by Saint Systems.

Improved nonce verification has been added in v1.3.8/v1.3.9. Please update at your earliest convenience.