If you run a WordPress site with the Ultimate Members plugin installed, make sure you’ve updated it to the latest version.
Over the weekend, the plugin’s creator published version 2.6.7, which is supposed to patch a serious security hole, described by user @softwaregeek on the WordPress support site as follows:
A critical vulnerability in the plugin (CVE-2023-3460) allows an unauthenticated attacker to register as an administrator and take full control of the website. The problem occurs with the plugin registration form. In this form it appears possible to change certain values for the account to be registered. This includes the
wp_capabilitiesvalue, which determines the user’s role on the website.The plugin doesn’t allow users to enter this value, but this filter turns out to be easy to bypass, making it possible to edit
wp_capabilitiesand become an admin.
In other words, when creating or managing their accounts online, the client-side web form presented to users doesn’t officially allow them to set themselves up with superpowers.
But the back-end software doesn’t reliably detect and block rogue users who deliberately submit improper requests.
Plugin promises “absolute ease”
The Ultimate Member software is meant to help WordPress sites to offer various levels of user access, listing itself as the “best user profile and membership plugin for WordPress”, and talking itself up in its advertising blurb as:
The #1 user profile & membership plugin for WordPress. The plugin makes it a breeze for users to sign-up and become members of your website. The plugin allows you to add beautiful user profiles to your site and is perfect for creating advanced online communities and membership sites. Lightweight and highly extendible, Ultimate Member will enable you to create almost any type of site where users can join and become members with absolute ease.
Unfortunately, the programmers don’t seem terribly confident in their own ability to match the “absolute ease” of the plugin’s use with strong security.
In an official response to the above security report from @softwaregeek, the company described its bug-fixing process like this [quoted text sic]:
We are working on the fixes related to this vulnerability since 2.6.3 version when we get a report from one of our customer. Versions 2.6.4, 2.6.5, 2.6.6 partially close this vulnerability but we are still working together with WPScan team for getting the best result. We also get their report with all necessary details.
All previous versions are vulnerable so we highly recommend to upgrade your websites to 2.6.6 and keep updates in the future for getting the recent security and feature enhancements.
We are currently working on fixing a remaining issue and will release a further update as soon as possible.
Bugs in many places
If you were on cybersecurity duty during the infamous Log4Shell vulnerability over the Christmas vacation season at the end of 2021, you’ll know that some types of programming bug end up needing patches that need patches, and so on.
For example, if you have a buffer overflow at a single point in your code where you inadvertently reserved 28 bytes of memory but meant to type in 128 all along, fixing that erroneous number would be enough to patch the bug in one go.
Now, however, imagine that the bug wasn’t down to a typing mistake at just one point in the code, but that it was caused by an assumption that 28 bytes was the right buffer size at all times and in all places.
You and your coding team might have repeated the bug at other places in your software, so that you need to settle in for an extended session of bug-hunting.
That way, you can promptly and proactively push out further patches if you find other bugs caused by the same, or a similar, mistake. (Bugs are generally easier to find once you know what to look for in the first place.)
In the Log4J case, attackers also set about scouring the code, hoping to find related coding mistakes elswhere in the code before the Log4J programmers did.
Fortunately, the Log4J programming team not only reviewed their own code to fix related bugs proactively, but also kept their eyes out for new proof-of-concept exploits.
Some new vulnerabilities were publicly revelealed by excitable bug-hunters who apparently preferred instant internet fame to the more sober form of delayed recognition they would get from disclosing the bug responsibly to the Log4J coders.
We saw a similar situation in the recent MOVEit command injection vulnerability, where associates of the Clop ransomware gang found and exploited a zero-day bug in MOVEit’s web-based front end, allowing the crooks to steal sensitive company data and then try to blackmail the victims into paying “hush money”.
Progress Software, makers of MOVEit, quickly patched the zero-day, then published a second patch after finding related bugs in a bug-hunting session of their own, only to publish a third patch shortly afterwards, when a self-styled threat hunter found yet another hole that Progress had missed.
Sadly, that “researcher” decided to claim credit for finding the vulnerability by publishing it for anyone and everyone to see, rather than giving Progress a day or two to deal with it first.
This forced Progress to declare it to be yet another zero-day, and forced Progress customers to turn the buggy part of the software off entirely for about 24 hours while a patch was created and tested.
In this Ultimate Members bug situation, the makers of the plugin weren’t as thoughtful as the makers of MOVEit, who explicitly advised their customers to stop using the software while that new and exploitable hole was patched.
Ultimate Members merely advised their users to keep their eyes out for ongoing updates, of which the recently published 2.6.7 is the fourth in a chain of bug fixes for a problem first noticed in the middle of June 2023, when 2.6.3 was the current version number.
What to do?
- If you are an UltimateMember user, patch urgently. Given the piecemeal way that the plugin’s coding team seem to be addressing this issue, make sure you look out for future updates and apply them as soon as you can, too.
- If you’re a server-side programmer, always assume the worst. Never rely on client-side code that you can’t control, such as HTML or JavaScript that runs in the user’s browser, to ensure that submitted input data is safe. Validate thine inputs, as we like to say on Naked Security. Always measure, never assume.
- If you’re a programmer, search broadly for related issues when any bug is reported. Coding errors made in one place by one programmer may have been duplicated elsewhere, either by the same coder working on other parts of the project, or by other coders “learning” bad habits or trustingly following incorrect design assumptions.