The changelog for the latest version of the WordPress plugin WordPress Hosting Benchmark tool is “fixed CSRF bug and WP nonce check vulnerability reported by patchstack.com, Dhabaleshwar Das.” In looking into that, we found that there was a more serious issue than cross-site request forgery (CSRF) at issue and it wasn’t fully fixed.
…
We were recently alerted that one of our customers started using a WordPress plugin, Duplicate Post Page Menu & Custom Post Type, which has been closed on the WordPress Plugin Directory. The reason given for the closure is:
…
In September, we wrote about how the WordPress plugin POST SMTP, which has 300,000+ installs, still contained SQL injection issues months after a public claim of a vulnerability involving that (and still does today). We also noted that the plugin was part of one of our competitors, Patchstack, Vulnerability Disclosure Program (VDP). The program doesn’t really make sense, as we noted at the time, because you are contacting a third-party security provider instead of the developer of software who can actually address vulnerabilities. It also wasn’t possible through that program to report security issues that are not vulnerabilities, despite the need for developer to address them. If a plugin developer is part of that program, it would suggest they lack an interest in properly securing their plugins, which the security of this plugin continues to point to.
While reviewing yet another attempt at a security fix in the plugin made on November 1, we noticed that new vulnerable code was being added to the plugin. That involves a failure to implement basic security and the plugin appears to contain multiple other vulnerabilities because of the other instance of the failure to implement that. [Read more]
The changelog for the latest version of the WordPress plugin Super Progressive Web Apps suggests a vulnerability might have been fixed, as one of the entries says in part “Fixed Broken Access Control vulnerability”. Looking at the changes made in that version, we found that a minor issue was addressed. Previously, anyone could access functionality to sign up for a newsletter or hide a form for the newsletter.
…
Part of how we keep track of vulnerabilities in WordPress plugins is by monitoring the WordPress support forum for relevant topics. What we are seeing a lot these days are developers who are trying to deal with rather unclear claims of vulnerabilities in their plugins. Two weeks ago, we helped a developer to get an issue in their plugin addressed after another provider, Patchstack, as usual, was rather unhelpful. There are lessons for plugin developers and Patchstack. We don’t have much hope for Patchstack addressing the issues, since they are already long running and well known, but developers have a chance to pretty easily improve their handling of the security of their plugins.
Patchstack inaccurately claimed that the plugin Simple SEO contained a cross-site request forgery (CSRF) vulnerability. While that was part of the issue, the vulnerability was more serious than that, though not a serious vulnerability. Here is the information they provided on that: [Read more]
One of the changelog entries for the second latest version of the WordPress plugin Super Socializer suggested a privilege escalation vulnerability had been fixed:
…
In reviewing changes being made to WordPress plugins used by our customers that are supposed to fix vulnerabilities, we often find that the vulnerabilities haven’t actually been fixed. Telling our customers that vulnerabilities have been fixed when we don’t actually know if they have been fixed would be unethical, but that is what we keep finding another provider, Wordfence, is doing with their Wordfence Intelligence Vulnerability Database. On their homepage, Wordfence call themselves the “Global Leaders in WordPress Security” and say you should trust them because of that. It’s unclear what would make someone the global leaders in WordPress security, but we can say they can’t be trusted whether they are the global leaders or not, as what we found below shows.
The changelog for the latest version of the WordPress plugin Simple Calendar claimed that a vulnerability was fixed in the plugin: [Read more]
Last month, we contacted the developer of the 5+ million install (and maybe 13 million install) WordPress plugin Elementor about yet another issue with them failing to properly restrict access to the plugin’s functionality to only users that are intended to access it. The only response we got back was asking a subscription to their Elementor Pro plugin. That issue still hasn’t been fixed, but the latest version of the plugin, 3.13.2, did address some other instances of the issue that led to at least minor vulnerabilities.
The only changelog information given on the fix made was “Security Fix: Addressed security weaknesses in access management related functions”. Looking into this, so that we could properly inform the one or more of our customers using that plugin, we found that user capability checks were added in several locations. One example of that involves the file /modules/safe-mode/module.php, where the ajax_enable_safe_mode had such a capability check added to limit enabling a safe mode for the plugin to those with install_plugins capability (which normally only Administrators have): [Read more]
The WordPress security provider Wordfence makes a big deal about doing responsible disclosure of vulnerabilities, despite not doing that. Responsible disclosure involves notifying the developer first and giving them a chance to address the vulnerability, before notifying anyone else. In Wordfence’s disclosure policy, they claim to do responsible disclosure and then go on to say they will sell information about the vulnerabilities to those using their Wordfence Premium service in the form of firewall rules before even notifying the developer. That policy also obliquely acknowledges that those firewall rules could be misused:
Where possible, we develop a firewall rule to protect our customers. This rule is obfuscated to prevent reverse engineering. [Read more]