Un-Patched Insecure WordPress Themes Update

An Update

A few weeks ago we disclosed the first batch of insecure WordPress themes with an un-patched authenticated vulnerability within them. This post is a follow up, where we disclose more issues in those same themes.

You can read our first post here.

In the time between the full timeline of events that go back months before our discovery and disclosure.

Starting with the biggest revelation: Patchstack was not the first to find the vulnerable code in these insecure WordPress themes. This vulnerability, line for line, was first found by Wordfence months ago, and it affected a plugin by the same author as the affected themes.

You can read a great technical write-up by Wordfence that was released in October.

The paragraph that summarizes this vulnerability in all of these components is as followed:

The plugin registers the wp_ajax_plugin_offline_installer AJAX action, which is tied to the plugin_offline_installer_callback function.

This function takes the supplied file_location, which could be any external URL to a ZIP file, along with the other specifying parameters like slug, class_name, and file, and then retrieves the file’s contents and extracts the ZIP file to the plugins directory.

Author: Chloe Chamberland from WordFence

Weeks after Wordfence released this report, Patchstack Alliance member Lenon Leite found the identical insecure code in multiple themes. It really was “identical”, as in it was the same lines of code with the same endpoint and variable names

This is a critical fact to consider because the endpoints were the same: the protections and attacks first reported in Access Demo Importer would work the same with all of the insecure themes Lenon reported.

This explains why our initial disclosure post it was mentioned that users with any up-to-date WordPress WAF protection services, were likely already protected.

This also means attackers had knowledge of how to write an attack this vulnerability for weeks. Luckily, possibly because of the requirement of authentication to perform the attack, we have not seen active exploitation of these vulnerabilities.

One problem becomes dozens of problems

The developer responsible for all of these insecure WordPress themes wrote and shared code between their projects. This is not too uncommon, but when they were made aware of a vulnerability in this shared code, they neglected to take action to secure this shared code across their projects.

This is what leads to one problem, turning into dozens of problems. The time needed to update one bit of code across all of the projects when the initial vulnerability was found is why this is not a best practice.

Developers long ago knew of this problem, and it is why we have libraries in code. This mature development practice puts shared code into packages that are separately tracked and managed, and we update the libraries to distribute the security patches across code bases.

In this developer’s specific case, they should have kept this code in the “Access Demo Importer” plugin alone, and not manually added it to all of their themes.

The extended timeline:

2021-08-09 Wordfence reports a file upload vulnerability to the developer of the Access Demo Importer WordPress Plugin.
2021-08-27 After no response from the developer, Wordfence escalates to the WordPress plugins team. The plugins team removes the plugin from the repository.
2021-09-07 Plugin author released an incomplete patch, Wordfence notifies the developer of the incomplete patch.
2021-09-20 After no response from the developer, Wordfence advises the WordPress plugin team of the incomplete patch.
2021-09-21 A complete patch is pushed.

(6 weeks later…)

2021-11-28 Lenon Leite reports their findings to the Patchstack Bug Bounty Program that the same vulnerable code is present in many WordPress themes by the same developer as the Access Demo Importer plugin.
2021-12-02 Patchstack research team verifies Lenon’s report and notifies the developer with details.
2021-12-09 No response, reached out again.
2021-12-22 Access Press Themes responds acknowledging awareness of the issue. We reply, asking for a timeline.
2022-01-10 No response and no patch available. We notify the WordPress themes team of the issue.
2022-01-11 The WordPress themes team removes the themes from the repository.

Additional insecurities found:

During the above timeline, Patchstack’s very own Vlad Visse took the time to dig deeper into the code of this developer’s WordPress themes. Vlad’s investigation identified more vulnerabilities and more vulnerable components.

Vlad’s findings include:
1) Authenticated arbitrary file upload in more components.
2) Lack of CSRF protections, leading to plugin activation or de-activation.
3) Authenticated arbitrary plugin activation or de-activation.
4) Authenticated content deletion of posts, pages, or media.

We have already begun publicly reporting these additional insecurities and have updated our database with dozens of additional insecurities in themes by the developer, we did attempt to reach out to the developer, but again found they were non-responsive to our reports of security bugs in their products.

Users with the Patchstack App integrated into the websites receive vPatches applied automatically to protect your website(s).

Hosting provider partners who subscribe to our Vulnerability Intelligence Feed received an initial heads up a few weeks ago and are automatically receiving further details via the intelligence feed. For everyone else I have provided a list of vulnerable themes below, or you can check out the Patchstack Database.

Vulnerable Theme List

All of the following themes lacked proper CSRF protections on an AJAX endpoint which manages the site’s plugins. I spoke about how to handle CSRF in the Patchstack Weekly for the 3rd week of 2022.

In addition to the above CSRF issues, the Access Demo Importer plugin itself is also lacked proper CSRF protections in multiple AJAX endpoints, which could lead to plugin activation/de-activation or site data deletion.

Ignore or embrace security?

There was one remarkable similarity in the above timeline, something that both Patchstack and Wordfence encountered: The developers consistently ignored the security reports from researchers who notified them privately.

Resulting in moderators from the theme or plugin repositories needing to step in and take down the insecure components before action was taken by the developer to patch their own code. This is unnecessary and wasteful of the repository moderation team’s time and effort, they have enough work and responsibility as it is.

This behavior comes from an incorrect belief that security can be ignored or thought about later. I propose an alternative, to embrace security.

Developers can treat security reports like free critical bug reports. Give these reports the appropriate time and attention they need. Setting up a formal vulnerability disclosure program, or at least a page explaining how to report security issues will show the world that they are a mature project, and a project their users can trust.

Users of free plugins or themes should be cautious of developers who have a history of ignoring or not commenting on security reports. Users of open source should not be taking on the burden of security, be it through paying for audits themselves or by having their sites hacked.

Users can protect themselves, when looking for what open source components to use, and prefer those projects that have a public vulnerability disclosure policy, or at least have a good track record of patching security issues quickly and transparently (this can be seen in the plugin’s change-logs.)

If you are ready to embrace security, Patchstack is here to help. We are here to help the users, developers, and open source projects with security.

We handled hundreds of reports last year, and are helping build an alliance between open-source projects and security researchers. If you are part of an open-source project and would like to improve your project’s security please reach out. If you are a user of open-source projects, by supporting Patchstack, you are supporting and benefiting from this effort as well.