Duplicated Vulnerabilities in WordPress Plugins

Duplicated WordPress Vulnerabilities

During a recent plugin audit, we noticed a weird pattern among many plugins responsible for performing a specific task: Duplicating a page or a post.

With a bit of research, we came to the following conclusion: Many of these plugins came from the same source — and contained the same vulnerabilities.

SQL Injections in Vulnerable Plugins

Let’s talk for a moment about the original code sample that this entire scenario stems from: A blog post from Misha Rudrastyh, written back in 2013, detailing how to duplicate posts without the help of a plugin by inserting a bit of code into a theme’s function.php file.

The original code was very simple. Comprising little more than 100 lines of code and well commented, it had one major issue: A SQL injection into a serialized table.

A few years later, this vulnerable code snippet was then converted to three plugins: Duplicate Page and WP Post Page Clone in 2016, and Duplicate Page and Post in 2017.

All of these plugins contained the vulnerability from the original post — which ironically was updated to fix the vulnerability in mid 2016, barely a week after the first plugin copied it and before the two others were even released.

Duplicated vulnerabilities

A number of other plugins also use parts of the code and instructions from the post to add to their features, such as Cherry Services List, Cherry Team Members, Custom Email Blocks for WooCommerce, and the theme framework Nebula — none of which are vulnerable to this attack.

As we were researching vulnerabilities in these plugins, we noticed that both Duplicate Page and Post and WP Post Page Clone were vulnerable to the exact same attack as Duplicate Page was.

While Duplicate Page and Post had been updated before we could reach out to them, we contacted WP Post Page Clone so they could update their plugin. Since they have not responded to our multiple outreach attempts, the WordPress plugin team had to close the plugin on March 31st until it is updated.

Timeline

  • 2013-06-17 – Misha Rudrastyh releases a blog post on how to duplicate a post
  • The original 2013 version has the vulnerability we found last year on duplicate page
  • 2016-05-04 Duplicate Page plugin released
  • 2016-05-13 – Misha Rudrastyh Fixes the vulnerability on his post most likely following a comment which highlighted the SQL injection.
  • 2017-01-11 Duplicate Page and Post plugin released
  • Copied from the vulnerable duplicate-page
  • 2017-02-10 WP Post Page Clone plugin released
  • Copied from the vulnerable duplicate-page
  • 2019-04-01 Duplicate Page patches vulnerability
  • 2019-04-05 – We release our blog post on the vulnerability
  • 2020-02-22 Duplicate Page and Post patches vulnerability
  • No mentions of the security update, only general WP Update
  • 2020-03-04 – Initial attempt at contacting WP Post Page Clone
  • 2020-03-30 – Contacted WordPress about vulnerability, following the lack of response from the developer
  • 2020-03-31 – Plugin is closed by WordPress

Conclusion

The permissive license used by WordPress and its plugins make it easy to copy and duplicate plugins for both their features — and their vulnerabilities. In this case, three plugins copied the source code from another source and never checked the original source for any important security updates after their launch.

To prevent the exploit of known vulnerabilities, the best solution is to keep your plugins and extensible components up to date with the latest patches. Website owners can also leverage a web application firewall to virtually patch vulnerabilities.

You May Also Like