Login

Plugin Vulnerabilities

A service to protect your site against vulnerabilities in WordPress plugins.

Login
02 Oct

What Plugin Vulnerabilities Was Up to in September

If you want the best information and therefore best protection against vulnerabilities in WordPress plugins we provide you that through our service. Here is what we did to keep those are already using our service secure from WordPress plugin vulnerabilities during September (and what you have been missing out on if you haven’t signed up yet).

Paid customers of the service can suggest and vote on plugins to have a security review done by us (you can also order a review separately). This month we released details of our reviews of Redis Object Cache and Nginx Cache.

During the month we added data on 79 vulnerabilities. Many of those vulnerabilities were ones that we discovered (33 of them) or ones where no report was put out on the vulnerability and we determined the details from other information we ran across (another 21 of them).

By comparison other data sources added less new vulnerabilities in total than ones we discovered, as the WPScan Vulnerability Database only added 25 vulnerabilities and ThreatPress also only added 25. ThreatPress seems to almost entirely copy data from the WPScan Vulnerability Database and WPScan Vulnerability Database intentionally doesn’t include a lot of vulnerabilities for a reason that doesn’t make sense to us (and probably one that wouldn’t make sense to you either).

As of the end of the month, 26 of the vulnerabilities we had added to the data set still had yet to be fixed.

We added vulnerabilities in the following plugins to our data set during the month:

  • About Author
  • Advanced Access Manager
  • Advanced AJAX Product Filters
  • API Bearer Auth
  • Apply Online 2.0
  • Checklist
  • Click to Chat
  • DELUCKS SEO
  • Easy Pixels by JEVNET
  • Easy Social Feed
  • ECPay Logistics for WooCommerce
  • Event Tickets
  • Export Users to CSV
  • FileBird Lite
  • Font
  • Formidable Forms
  • Give (GiveWP)
  • Groundhogg
  • Human Presence
  • Melhor Envio v2
  • Memphis Documents Library
  • Mitsol Social Post Feed
  • NBDesigner
  • Photo Gallery by 10Web
  • Poll, Survey, Form & Quiz Maker by OpinionStage
  • Portrait-Archiv.com Photostor
  • Premium Addons for Elementor
  • Premium Blocks for Gutenberg
  • Prevent Files / Folders Access
  • Product Subtitle For WooCommerce
  • Qwizcard
  • Request a Quote
  • SagePay Server Gateway for WooCommerce
  • Search Exclude
  • Simple Fields
  • SKU Shortlink For WooCommerce
  • SlickQuiz
  • Slimstat Analytics
  • Social Metrics Tracker
  • Spryng Payments WooCommerce
  • Swift Landing Page
  • Theme Editor
  • Travelpayouts
  • Ultimate Google Analytics
  • Visualizer: Tables and Charts Manager for WordPress
  • WooCommerce One Click Upsell Funnel
  • Woocommerce Quick Buy
  • Woody ad snippets
  • WP BASE Booking of Appointments, Services and Events
  • WP Google Map Plugin
  • WP human resource management
  • WP Live Chat Support
  • WPeMatico RSS Feed Fetcher
  • Youtube Showcase (YouTube Gallery)
  • Zedna Contact form

We discovered and disclosed vulnerabilities in the following plugins during the month:

  • Easy Social FeedClick to Chat
  • FileBird Lite
  • Font
  • Formidable Forms
  • Groundhogg
  • DELUCKS SEO
  • NBDesigner
  • Poll, Survey, Form & Quiz Maker by OpinionStage
  • Premium Addons for Elementor
  • Prevent Files / Folders Access
  • Request a Quote
  • Search Exclude
  • Simple Fields
  • Social Metrics Tracker
  • Travelpayouts
  • Ultimate Google Analytics
  • Woocommerce Quick Buy
  • WP BASE Booking of Appointments, Services and Events
  • WP Google Map Plugin
  • WP human resource management
  • WPeMatico RSS Feed Fetcher
  • Youtube Showcase (YouTube Gallery)
  • Zedna Contact form

Other vulnerabilities we added were discovered by GeneralEG 0x01, Julien Ahrens, MTK, Nathan Davison, NinTechNet, Ov3rfly, Ricardo Sanchez, WebARX, and Wordfence.

During the month we helped to get vulnerabilities in the following plugins with over 810,380 installs fixed:

  • DELUCKS SEO
  • Event Tickets
  • FileBird Lite
  • Formidable Forms
  • Forms: 3rd-Party Inject Results
  • GA Top Posts
  • Groundhogg
  • Limb Gallery
  • Ovic Addon Toolkit
  • Poll, Survey, Form & Quiz Maker by OpinionStage
  • Post SMTP
  • Premium Addons for Elementor
  • Prevent Files / Folders Access
  • Product Subtitle For WooCommerce
  • Search Exclude
  • SKU Shortlink For WooCommerce
  • Travelpayouts
  • Woocommerce Quick Buy
  • Woody ad snippets
  • WP BASE Booking of Appointments, Services and Events
  • WP Google Map Plugin
  • WP human resource management
  • WPeMatico RSS Feed Fetcher
  • Youtube Showcase (YouTube Gallery)
25 Sep

Exploitation of Vulnerability in Simple Fields WordPress Plugin Shows That Unlike Other Security Providers We Keep Ahead of Hackers

If you want to understand why security, whether related to WordPress plugins or more broadly, is in such bad shape looking at the state of security journalism would be a good place to start. What you will find with WordPress plugins is that there are frequent stories telling people to update or remove plugins after they have already been widely exploited, which is too late. You might think that journalists would stop and think about that and realize there what is going on isn’t working (there is a line about the definition of insanity that comes to mind), but it doesn’t ever seem to occur for them. If anything they seem to think trying to better address the situation is a bad thing. For example, earlier today we mentioned that a journalist was criticizing us for having spotted a hacker targeting a plugin and then publicly warning everyone about that before there was confirmed exploitation. If journalists were actually interested in doing good journalism another element of that post is worth covering, as a new version of the plugin that fixes the exploited vulnerability has been released, but the WordPress is not allowing those using the plugin to get access to it.

That plugin was part of what looks to have been a set of nine plugins so far that a hacker has been recently looking to exploit. With another of those, Simple Fields, we saw what looked to be the hacker probing on the September 15 and we warned about a persistent cross-site scripting (XSS) vulnerability that it looked like the hacker would be interested in exploiting the next day. Other security providers still don’t seem to be aware of the issue (they at least have not warned about the issue), even though there is now public confirmation that it is being exploited. What that shows is not only how our service can often help to avoid websites being hacked by warning before the hackers exploit vulnerabilities instead of after, but also that we can help to address security situations that are beyond the scope of the average webmaster on their own.

Yesterday a new topic was created on the WordPress Support Forum, “Hack related to Simple Fields?“, which indicates that a hacker had exploited this vulnerability on this person’s website in the last day:

I noticed today our website had problems, and yesterday it was fine. I was about to add a new post for a custom post type, the same as I had done yesterday, but I noticed none of the special fields that come from Simple Fields were where they were supposed to be on the edit page. It looked like a plain edit page.

If they had been using our service they would have been warned about the vulnerability a week before that.

Later in their post they write:

We did have a backup that we reloaded successfully, and we’ll have more things to add back in since the last backup, but that is doable. However, we don’t know how this could have occurred and we don’t currently have a way to prevent it from happening again.

I just noticed on the plugin page –
https://wordpress.org/plugins/simple-fields/
It says in red background –
“This plugin has been closed as of September 16, 2019 and is not available for download. This closure is temporary, pending a full review.”

That is recent and it is interesting that it is a temporary closure and there will be a review. Perhaps someone is aware of a serious problem. Does anyone know more about this?

And near the end of their message they say this:

I don’t even know for sure if the Simple Fields plugin was the original vulnerability, but that is my best guess. We will check web server and network logs.

I guess if there is no short-term solution, then the long-term solution for us would be to use an alternative plugin to Simple Fields. That would be a huge undertaking.

Again if they were using our service they would have been warned about the vulnerability a week before that, so they would have known what was going on before being hacked. But we would also been able to help with dealing with the situation, as an important part of our service is the support we provide when a plugin being used is found to be vulnerable. Whether that be making an assessment that the plugin was simply too insecure to keep using or providing them with temporary fixes that could be made to the plugin to secure it enough to keep using for the time being (it doesn’t appear this plugin is being supported anymore).

Because of the inappropriate behavior of the moderators of that forum, not surprisingly they so far have not gotten a response from someone who could help them to understand what has happened. Instead the only response they have gotten so far is from someone else impacted by this:

We are having similar issues as well.

25 Sep

WordPress Isn’t Allowing Users of DELUCKS SEO to Get New Version of the Plugin That Fixes Exploited Vulnerability

When it comes to the poor security surrounding WordPress plugins what we have long found so unfortunate is that it would be easy for the team running the Plugin Directory to improve the situation, but for reasons that have never made sense they continue to refuse to do things that would make a big difference and likely greatly reduce the number of websites being hacked (we and others have repeatedly offered to help them do those things).

One of the problems we have long seen is that after plugins are closed on the Plugin Directory due to vulnerabilities, even after the vulnerability has been fixed, the plugin remains closed, so those already using the plugin can’t get the updated version. This often looks to be because the team running the Plugin Directory requires more changes to be made, sometimes security related. The problem with that is that if those websites could update they would stop the possibility of the fixed vulnerability being exploited.

While it is understandable to not want to introduce a plugin that still has additional security issues to those websites not already using the plugin, for those already using the plugin not providing them the update is only harmful. So an option to allow those already using the plugins to update seems like a no brainer.

Back in April we believed that the team had finally gotten access to the capability and started using as with the plugin Ari Adminer there was different message shown when it was closed due to a security vulnerability:

This plugin has been closed as of April 5, 2019 and is not available for download. This closure is permanent.

and we found that while it was closed you could still update the plugin. What made that seem a bit odd is that vulnerability was not an issue that was likely to be exploited, so why start with that plugin.

Since then we haven’t seen that done with any other plugin we have run across and in looking back at something recently, we noticed that it sound like they have had this capability for years, as this was written by the person in charge of the Plugin Directory four years ago:

Right now, we actually do have disabled as an option, which means a plugin is removed but still able to push updates. That functionality would need to be revisited.

So it appears that might have been used in that instance by accident.

Using that capability would be useful with the plugin DELUCKS SEO right now. On Saturday we publicly warned that it look like a hacker was targeting an unfixed vulnerability in the plugin. The developer of the plugin fixed the vulnerability on Monday, but the plugin still remains closed as of the publishing of this post. Since then there have been reports of websites being hacked due to it.

Since the team running the Plugin Directory also controls the moderation of the WordPress Support Forum it isn’t possible to discuss problems like this in the most obvious place, so security journalists covering these problem seems like it would be an important element of them finally being resolved, but they seem to be unconcerned about such things. Instead you had a ZDNET security journalists who made up a fictional story about us earlier this year criticizing us for getting ahead of the vulnerability in DELUCKS SEO (also incorrectly, they are claiming that we have “big of an ego to work with the WP security team”, when it seems to be the the opposite of that):

20 Sep

Responsible Disclosure and Closing a WordPress Plugin With an Unfixed Vulnerability Didn’t Prevent Websites From Being Hacked

One of the things we do to keep track of vulnerabilities in WordPress plugins to warn customers of our service if they are using publicly known insecure plugins is monitoring WordPress support forum. Recently that hasn’t led to us finding out about any vulnerabilities we didn’t know about, but it does provide a regular reminder of the lack of concern of people in charge of WordPress about addressing the poor handling of security problems with plugins.

Yesterday a topic was started on the forum of Rich Reviews, “Plugin not supported; open to malware – uninstall now!“, which starts:

Since this plugin is no longer on the repository or supported, it is highly suggested to remove this plugin. 3 of 4 of my sites using it were affected by the script malware

If you go to main page for the plugin on the Plugin Directory there is this warning:

This plugin has been closed as of March 11, 2019 and is not available for download. Reason: Security Issue.

While that warning is there, no warning is provided to those already using the plugin and based on the replies the original poster isn’t the only one still using the plugin.

The current amount of installs of the plugin isn’t listed due to the plugin being closed, but on January 9 there were 10,000+ installs, so somewhere between 10,000 and 20,000 installs.

That so many people were using that plugin at that time is itself a bad sign as the vulnerability being exploited now sounds like it could one that we had disclosed in December of 2017. We had notified the developer of that vulnerability over a month and half before disclosure, along with two lesser issues. While the lesser issues were resolved before our disclosure, the more serious issue was not and still hasn’t been.

Plenty of Room for Improvement

There is a lot that could have been done differently here and WordPress could easily improve their processes going forward, but based on the years long track record of inaction it seems unlikely that will happen, but everyone can hope.

Why did the plugin remain in the Plugin Directory for over a year after we had warned about the vulnerability? The simple answer is that we appear to have been the only ones that ever tried to make sure that publicly known vulnerable plugins were not remaining in the Plugin Directory. When we suspended doing that in June of 2017 due to continued poor handling of security by the WordPress team, they didn’t pick up the slack, so you now have plugins with millions of installs that are known to be vulnerable still in that.

Years ago, shortly after we had started notifying the team running the Plugin Directory about those unfixed vulnerabilities, we realized the problem with people already using plugin being left unaware that they were using plugins that were closed on the Plugin Directory. We had then suggested on the Ideas section of the WordPress to start alerting people, while that was the marked as ‘Good idea! We’re working on it”, since then the people on the WordPress side of things have given a litany of strange excuses for not doing that. Here for example is the head of the team running the Plugin Directory claiming that not warning about an unfixed vulnerability is the proper response when a vulnerability is already being exploited:

We cannot provide this service at this time.

IF an exploit exists and we publicize that fact without a patch, we put you MORE at risk.

If an exploit exists, hackers will be targeting the vulnerability en-mass.

That’s exactly the issue. If we make it known there is an exploit, the hackers attack everyone :/

If we don’t tell anyone, then hackers who DO know will attack, but they would have anyway.

You don’t have to be a security expert to realize that leaving people to be hacked isn’t a proper resolution for that. There is another option, as mentioned on the security page on the WordPress website:

When a plugin vulnerability is discovered by the WordPress Security Team, they contact the plugin author and work together to fix and release a secure version of the plugin. If there is a lack of response from the plugin author or if the vulnerability is severe, the plugin/theme is pulled from the public directory, and in some cases, fixed and updated directly by the Security Team.

Despite our repeated offer to provide the fixes, so the team wouldn’t have to do almost any work, we can’t even recall the last time that option was used with a vulnerability that is being exploited. We tried to discuss the lack of doing that in the past and they have refused to even discuss the lack of doing that. In one instance we tried to do that involved an unfixed vulnerability in the plugin Form Lightbox that appears to have originally been exploited in July of 2016 and was recently claimed by Wordfence to still being exploited.

Protecting Yourself

We continue to be willing to work the WordPress team to resolve these problems, but since that isn’t happening our service can fill the gap. If you used our service and this plugin you would have been warned it was vulnerable back in 2017 or whenever you first set up the service.

Relying on other data sources likely wouldn’t have done that, as underlying source of most of those is the WPScan Vulnerability Database and that doesn’t include the vulnerability in its data set:

16 Sep

WordPress Plugin Security Review: Nginx Cache

For our 34th security review of a WordPress plugin based on the voting of our customers, we reviewed the plugin Nginx Cache.

If you are not yet a customer of the service, once you sign up for the service as a paying customer you can start suggesting and voting on plugins to get security reviews. For those already using the service that haven’t already suggested and voted for plugins to receive a review, you can start doing that here. You can use our tool for doing limited automated security checks of plugins to see if plugins you are using have possible issues that would make them good candidates to get a review. You can also order a review of a plugin separately from our service.

The review was done on version 1.0.4 of Nginx Cache. We checked for the following issues during as part of our standard review:

  • Insecure file upload handling (this is the cause of the most exploited type of vulnerability, arbitrary file upload)
  • Deserialization of untrusted data
  • Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)
  • Security issues with functions accessible through WordPress’ REST API (those have started to be a source of disclosed vulnerabilities)
  • Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below
  • Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin
  • SQL injection vulnerabilities (the code that handles requests to the database)
  • Reflected cross-site scripting (XSS) vulnerabilities
  • Security issues with functions accessible through any of the plugin’s shortcodes
  • Security issues with functions accessible through the admin_action action
  • Security issues with functions accessible through the admin_init action
  • Security issues with functions accessible through the admin_post action
  • Security issues with import/export functionality
  • Security issues with usage of the is_admin() function
  • Security issues with usage of the add_option(), delete_option(), and update_option() functions
  • Security issues with usage of the extract() function
  • Host header injection vulnerabilities
  • Lack of protection against unintended direct access of PHP files
  • Insecure and unwarranted requests to third-party websites
  • Any additional possible issues identified by our Plugin Security Checker

Results

We found no issues with any of the checked items in version 1.0.4 of Nginx Cache.

11 Sep

Wordfence Security and Wordfence Premium Failed to Protect Against Widely Exploited Vulnerability

A month ago we noted an instance of us running across the Wordfence Security plugin, despite being marketed with the claim that it “stops you from getting hacked”, failing to protect against exploitation of a vulnerability in a WordPress plugin that was being widely exploited. That has happened again. In a post earlier today we mentioned a topic on the WordPress Support Forum discussing websites being exploited due an already fixed arbitrary file viewing vulnerability in the plugin Advanced Access Manager, which we had warned customers of our service about the same day it was fixed. In that topic there was a claim that the Wordfence Security plugin failed to protect against that:

It happened to me. I cleaned up but it came again one day later, even websites with last version of WP, with Wordfence, Block Bad Queries, etc.
Does somene knows where it comes from ? Is it an injection ?

Considering that our other post about the exploitation of that vulnerability was talking about confusion related to the vulnerability in question, we wanted to double check that the plugin really didn’t protect against this. A quick test confirmed that it did not, as of yesterday, provide protection. We also tested the NinjaFirewall plugin and found that plugin did provide protection. NinjaFirewall has 100 times less installs than Wordfence Security, despite it providing the same or more protection is previous testing we have done, which goes to show that the popularity of security plugins doesn’t seem to be tied to how well they work.

There also was a claim that the paid service tied to that plugin, Wordfence Premium, also failed to provide protection:

Same problem, in 2 different sites that we have.
We revert back to previous day and all OK, but problem started a few hours later.
We do have Advanced Access Manager. We are all day trying to see where it comes from. We use Wordfence Premium but it didnt help.

We don’t have access to the Wordfence Premium service, but since that service often doesn’t provide any addition protection over the Wordfence Security plugin until after widespread exploitation has occurred, so if the plugin doesn’t provide protection it would seem likely that the paid service wouldn’t make a difference (as we have said before, people paying for that service are not getting the protection they pay for).

03 Sep

Two Additions to Our Security Reviews of WordPress Plugins

Like everything else we do, we are always looking for ways that we can improve the security reviews of WordPress plugins that we do as part of our main service as well as a separate service. With our recent reviews we have been testing out doing the following two additional checks as part of the reviews:

  • Security issues with functions accessible through the admin_post action
  • Security issues with usage of the extract() function

Based on what we have seen with those, some of which relates to a widespread security issue we will be discussing soon in the context of one of the reviews we will be releasing the results of soon, we have now added those checks to our standard roster of items being checked.

That isn’t the only recent improvement made to our reviews. We have been making a number of refinements to our handling of existing checks, which have allowed us to produce better results for those checks. We have also been making a lot improvements to what can be detected by our Plugin Security Check tool recently and since possible issues flagged by that get checked during our reviews, the amount of possibly insecure code checked by our reviews is increasing due to that.

Improved Pricing

We have also recently improved the pricing of the review service. Previously we based the price on the number of lines of code in the plugin, which usually mapped closely to the amount of work needed to be done in the review, but some plugins had a lot of code, but little that would be reviewed. We have now changed to determining the price based on how many instances in the plugins’ code of many of the things we check over during the reviews. Alongside that, the pricing is now more variable, with the lowest price being significantly lower than it was before.

The practical impact of that can be seen with a plugin that we are in the process of reviewing based on our customer selecting it, where the price would now be only a fifth of the price under are old pricing structure.

For other plugins that will increase the price, sometimes significantly due to there previously being a ceiling for the price. With two paid reviews that we will be releasing the results once there has been a chance to resolve the issues found, the price paid was lower than it would be now.

27 Aug

Our Security Review for WordPress Plugins Would Have Identified the Vulnerability in Bold Page Builder Before It Was Exploited

Last week we discussed how the developers of the Wordfence Security plugin are selling their Wordfence Premium service as being able to do something that it can’t and they don’t even try to accomplish. One of the claims about it is this:

Stay a Step Ahead of Attackers with Real-time Threat Intelligence

If your website is mission-critical you can’t afford the downtime, reputation challenges or SEO impact of getting hacked. That’s why so many sites rely on the real-time protection provided by Wordfence Premium.

In reality they are adding claimed protection against vulnerabilities after they have already been widely exploited, which is too late for the widely exploited vulnerabilities and does nothing for the vast majority of vulnerabilities that are not widely exploited, but could be used in a targeted attack.

At the end of that post we noted the real way to get ahead of hackers if you have a mission critical website is to have the security of the software you use reviewed. With WordPress websites the most important software to get reviewed would usually be the plugins being used.

To give everyone a better idea of how that can protect against vulnerabilities let’s take a look at a vulnerability that was reported to be being exploited before it was fixed last week.

Last Friday NinTechNet vaguely disclosed that a persistent cross-site scripting (XSS) vulnerability in the plugin Bold Page Builder was being exploited. Shortly after they had done that we had provided our customers with more detailed information on it, which led to additional related security vulnerabilities being fixed in the code.

As is the case with many of the widely exploited vulnerabilities in recent times the checks we do during our security reviews of WordPress plugins would have spotted the vulnerable code during multiple of the checks done, in this case five different checks.

The vulnerability starts with a function, bt_bb_save_custom_css(), which was registered to be accessible through WordPress AJAX functionality to those logged in as well as those not logged in:

327
328

add_action( 'wp_ajax_bt_bb_save_custom_css', 'bt_bb_save_custom_css' );
add_action( 'wp_ajax_nopriv_bt_bb_save_custom_css', 'bt_bb_save_custom_css' );

That means it would be checked as part of us checking any AJAX accessible functions:

Security issues with functions accessible through WordPress’ AJAX functionality (those have and continued to be a common source of disclosed vulnerabilities)

If it wasn’t already checked for that it would be checked as part of our check of any issues flagged our Plugin Security Checker, since it flags functions registered to be accessible through WordPress AJAX functionality to those logged in as well as those not logged in:

Any additional possible issues identified by our Plugin Security Checker

The function doesn’t contain much code, but it has multiple issues, which if we somehow missed during our review of the function as part of the AJAX check, would be identified by others:

310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325

 function bt_bb_save_custom_css() {
	$post_id = intval( $_POST['post_id'] );
	$css = $_POST['css'];
	$opt_arr = get_option( 'bt_bb_custom_css' );
	if ( ! is_array( $opt_arr ) ) {
		$opt_arr = array();
	}
	if ( $css != '' ) {
		$opt_arr[ $post_id ] = $css;
	} else {
		unset( $opt_arr[ $post_id ] );
	}
	update_option( 'bt_bb_custom_css', $opt_arr );
	echo 'ok';
	die();
}

Before the main code runs in that there should be a check for a valid nonce to prevent cross-site request forgery (CSRF), which if we hadn’t looked at the code first we should have noticed when we check for that type of issue on admin pages since the function is called from there:

Cross-site request forgery (CSRF) vulnerabilities in the admin portion of the plugin

Next up, in the second line of code in the function user input is set to a variable without sanitization or validation. That would have been checked due to our check for reflected cross-site scripting (XSS), which in practice also is a more general check of user input being brought in to the plugin:

Reflected cross-site scripting (XSS) vulnerabilities

The final check that would involve directly checking that function’s code is that we check all usage of the function update_option(), since as is the case here, it is frequently involved in vulnerabilities being widely exploited these days:

Security issues with usage of add_option(), delete_option(), and update_option()

Through that function malicious JavaScript code could be saved a WordPress option. Through another function, bt_bb_wp_head(), that would be output on frontend pages of the website. The combination of all that would be something we checked on through another of the checks:

Persistent cross-site scripting (XSS) vulnerabilities in the frontend portions of the plugin and in the admin portions accessible to users with the Author role or below

So all total there were five checks that would have come in to play with, making it impossible that we could have missed the vulnerability. Even a lower quality security review should have caught this, which gets to the important thing to understand even if you don’t have a mission critical website, which is that most plugins haven’t gone through any sort of security review and just getting that done could greatly improve the security of WordPress websites. What certainly isn’t helping that happen is security companies like Wordfence, whose business models are not based on improving the security of WordPress websites, but profiting off them remaining insecure or even creating fake threats.

18 Oct

Not Really a WordPress Plugin Vulnerability, Week of October 18

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

Cross Site Scripting in FooGallery, Popup Builder, and Soliloquy

Related claimed cross site scripting vulnerabilities in the plugins FooGallery, Popup Builder, and Soliloquy involve a common cause of false reports of persistent cross-site scripting (XSS) vulnerabilities, people not understanding that WordPress allows users with the unfiltered_html capability to do the equivalent of XSS. In this case if you follow the instruction you find that you are entering the XSS code in the title of a custom WordPress post, which is permitted to happen for users with the unfiltered_html capability, but is not permitted for those without that. [Read more]

14 Oct

WordPress Plugin Copies Security Vulnerabilities From Another Plugin

When it comes to insecure code in WordPress plugins, beyond insecure code written by the developers, we often find that the developers have included code created by others without reviewing its security first (that even has been the case with popular security plugins). Recently multiple security issues were fixed in the plugin Sliced Invoices, while looking into that we found that plugin Tradies has copied a significant amount of code from that plugin and still contains those vulnerabilities, so significant that if you try to activate Tradies with Sliced Invoices already activated (or vice versa) it won’t work because a class name is reused. While that is permitted by the GPL, there isn’t a copyright statement indicating the source of the code (which isn’t the first time we have seen that done with copied code).

As an example of the insecure code copied, let’s take a look at the code to handle exporting the plugin’s quotes and invoices. [Read more]

14 Oct

Vulnerability Details: Information Disclosure in Sliced Invoices

This post provides the details of a vulnerability in the WordPress plugin Sliced Invoices not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

11 Oct

Not Really a WordPress Plugin Vulnerability, Week of October 11

In reviewing reports of vulnerabilities in WordPress plugins to provide our customers with the best data on vulnerabilities in plugins they use we often find that there are reports for things that don’t appear to be vulnerabilities. For more problematic reports we release posts detailing why the vulnerability reports are false, but there have been a lot of that we haven’t felt rose to that level. In particular are items that are not outright false, just the issue is probably more accurately described as a bug. For those that don’t rise to level of getting their own post we now place them in a weekly post when we come across them.

SQL Injection in New Contact Form Widget & Shortcode [Standard] (Contact Form Widget – Contact Query, Form Maker)

The quality of data on vulnerabilities in WordPress plugins form other sources is quite poor, as a recent entry with CVE shows. The entry, CVE-2019-17072, makes this claim: [Read more]

11 Oct

Vulnerability Details: Cross-Site Request Forgery (CSRF)/Settings Change in Page Animations And Transitions

This post provides the details of a vulnerability in the WordPress plugin Page Animations And Transitions not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

11 Oct

Vulnerability Details: Authenticated Persistent Cross-Site Scripting (XSS) in Employee Directory

This post provides the details of a vulnerability in the WordPress plugin Employee Directory not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

11 Oct

Vulnerability Details: Authenticated Persistent Cross-Site Scripting (XSS) in WX Form Management

This post provides the details of a vulnerability in the WordPress plugin WX Form Management not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

11 Oct

Vulnerability Details: Information Disclosure in WP Telegram

This post provides the details of a vulnerability in the WordPress plugin WP Telegram not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

10 Oct

Vulnerability Details: Privilege Escalation in iThemes Sync

This post provides the details of a vulnerability in the WordPress plugin iThemes Sync not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]

08 Oct

Vulnerability Details: Open Redirect in All In One WP Security

This post provides the details of a vulnerability in the WordPress plugin All In One WP Security not discovered by us, where the discoverer hadn’t provided the details needed for us to confirm the vulnerability while we were adding it to the data set for our service, so its contents are limited to subscribers of our service.

If you were using our service you would have already been warned about this vulnerability if your website is vulnerable due to it. [Read more]