High-Severity Vulnerability Patched in Advanced Access Manager

On August 13, 2020, the Wordfence Threat Intelligence team finished investigating two vulnerabilities in Advanced Access Manager, a WordPress plugin with over 100,000 installations, including a high-severity Authorization Bypass vulnerability that could lead to privilege escalation and site takeover.

We reached out to the plugin’s author the next day, on August 14, 2020, and received a response within a few hours. After providing the full vulnerability disclosure, we received a response on August 15, 2020, that a patch had been released in version 6.6.2.

Wordfence Premium users received a firewall rule protecting against the Authorization Bypass vulnerability on August 14, 2020. Sites still running the free version of Wordfence will receive this rule 30 days later, on September 13, 2020.

Description: Authenticated Authorization Bypass and Privilege Escalation
Affected Plugin: Advanced Access Manager
Plugin Slug: advanced-access-manager
Affected Versions: < 6.6.2
CVE ID: Pending
CVSS Score: 7.5(High)
Fully Patched Version: 6.6.2

Advanced Access Manager allows fine-grained access control, and has the capability to assign multiple roles to a single user. If the “Multiple Roles Support” setting is enabled, the plugin is vulnerable to authenticated authorization bypass and, in some cases, privilege escalation.

A low-privileged user could assign themselves or switch to any role with an equal or lesser user level, or any role that did not have an assigned user level. This could be done by sending a POST request to wp-admin/profile.php with typical profile update parameters and appending a aam_user_roles[] parameter set to the role they would like to use.

The reason this worked is that the AAM_Backend_Manager::profileUpdate method that actually assigns these roles is triggered by the profile_update and user_register actions, and failed to use a standard capability check.

            add_action('profile_update', array($this, 'profileUpdate'), 10, 2);
            add_action('user_register', array($this, 'profileUpdate'), 10, 2);
    public function profileUpdate($id)
        $user = get_user_by('ID', $id);

        //save selected user roles
        if (AAM::api()->getConfig('core.settings.multiSubject', false)) {
            $roles = filter_input(

            // let's make sure that the list of roles is array

            $roles = (is_array($roles) ? $roles : array());

            // prepare the final list of roles that needs to be set
            $newRoles = array_intersect($roles, array_keys(get_editable_roles()));

            if (!empty($newRoles)) {
                //remove all current roles and then set new

                foreach ($newRoles as $role) {

This meant that, if the ‘Multiple Roles Support’ setting was enabled, any user would trigger this method when updating their profile. The profileUpdate function would then check to see if any roles were present in the aam_user_roles[] POST parameter. If roles were present, it then used the WordPress get_editable_roles function to determine whether the user was allowed to add a given role, and if so, granted the user that role without performing any other form of capability check.

By default, get_editable_roles returns all registered roles. However, the Advanced Access Manager plugin added a filter to limit these roles in the AAM_Service_UserLevelFilter::filterRoles method. This method looped through each registered role and determined the role’s user level using the AAM_Core_API::maxLevel method.

    public function filterRoles($roles)
        static $levels = array(); // to speed-up the execution

        foreach ($roles as $id => $role) {
            if (!empty($role['capabilities']) && is_array($role['capabilities'])) {
                if (!isset($levels[$id])) {
                    $levels[$id] = AAM_Core_API::maxLevel($role['capabilities']);

                if (!$this->isUserLevelAllowed(true, $levels[$id])) {

        return $roles;

AAM_Service_UserLevelFilter::filterRoles then removed any roles with a higher user level than the current user from the list of roles the current user was allowed to choose. By default, this worked reasonably well; all built-in roles have a built-in user-level attribute. Unfortunately, however, the user-level attribute was deprecated in WordPress 3.0.

This meant that if a role did not have a user-level attribute, or had a user-level attribute equal to or lesser than the logged-in user, the logged-in user could assign themselves to that role.

This was a problem in 3 possible scenarios:

  • Plugins with custom roles. There are several thousand plugins that add custom roles in the WordPress plugin repository, and most of these plugins do not assign a user-level attribute to these roles. For a few real-world examples, a backup plugin could add a role that is allowed to restore arbitrary files, including malicious code or database modifications, or an educational plugin might add an instructor role with the ability to insert unfiltered html and embed malicious JavaScript into the site.
  • Roles without an assigned user level. If a role was created from scratch in Advanced Access Manager, but not assigned a user level, any user with subscriber-level access could switch to that role.
  • Cloned user roles. If a role was cloned from an existing role (for instance, a contributor or author) and assigned additional capabilities, any user in the original role could switch to or assign themselves to the new role.

In any one of these scenarios, a low-privileged attacker could potentially switch to a role that allowed them to either directly take over a site or could be used as part of an exploit chain, depending on which roles were configured.

Description: Authenticated Information Disclosure
Affected Plugin: Advanced Access Manager
Plugin Slug: advanced-access-manager
Affected Versions: < 6.6.2
CVE ID: Pending
CVSS Score: 4.3(Medium)
Fully Patched Version: 6.6.2

Advanced Access Manager also allows users to login via the WordPress REST API. Unfortunately the plugin’s aam/v1/authenticate and aam/v2/authenticate REST endpoints were set to respond to a successful login with a json-encoded copy of all metadata about the user, potentially exposing users’ information to an attacker or low-privileged user. This included items like the user’s hashed password and their capabilities and roles, as well as any custom metadata that might have been added by other plugins. This might include sensitive configuration information, which an attacker could potentially use as part of an exploit chain. For example, an attacker able to assign themselves a custom role using the previous vulnerability could view which capabilities were assigned to them, allowing them to plan the next phase of their attack.

What are Roles and Capabilities?

All WordPress sites need an administrator, a user who has complete control over the site in order to make changes and perform maintenance. Likewise, an eCommerce site would need to allow customers to log in to keep track of their orders, and a news site would likely need to allow its journalists the ability to author posts, and might need an editor. In these cases, “administrator”, “editor”, “author”, and “customer” are roles.

Each of these roles comes with a certain set of capabilities. For example, an administrator would have the manage_options capability that allows them to make changes to a site’s options, but it would be disastrous to allow a customer, or even an author, the same capabilities. Likewise, an author would need the capability to edit_posts, but not edit_others_posts, and a customer or subscriber should not have any of these capabilities.

In many cases, a site owner might need more fine-grained control over which users can perform certain actions, so they might use a plugin like Advanced Access Manager to create custom roles for their users. They could then assign the capabilities they want those users to have, such as allowing a site designer the ability to edit_theme_options without changing other site options.

Additionally, many plugins add specific roles and custom capabilities. For example, while “customer” is not a built-in WordPress role, eCommerce plugins will define a specific “customer” role that has custom capabilities related to viewing their order status and updating their address information, while prohibiting them from making any other changes to the site.

The ability to customize roles and capabilities using plugins is part of the power of using WordPress for a variety of applications, including eCommerce, learning management systems, membership sites, and many others. However, this expanded functionality demands a greater attention to access control and capabilities from site owners.


August 13, 2020 – Wordfence Threat Intelligence finishes analyzing vulnerabilities.
August 14, 2020 – We release a Firewall rule to Wordfence Premium users to protect against privilege escalation vulnerability and provide disclosure to the plugin’s author.
August 15, 2020 – A full patch is released.
September 13, 2020 – Firewall rule becomes available to sites using the free version of Wordfence.


In today’s post, we detailed two vulnerabilities in the Advanced Access Manager plugin, including a high-severity vulnerability that could allow lower-level users to escalate their privileges. We strongly recommend updating to the latest version of the Advanced Access Manager plugin, currently version 6.6.2, as soon as possible.

Wordfence Premium users have been protected against this vulnerability since August 14, 2020. Sites still using the free version of Wordfence will receive the firewall rule 30 days later, on September 13, 2020.

If you know a friend or colleague who is using this plugin on their site, please forward this advisory to them to help keep their sites protected.

Special thanks to the plugin’s author, Vasyl Martyniuk, for an excellent and rapid response to our disclosure

The post High-Severity Vulnerability Patched in Advanced Access Manager appeared first on Wordfence.

Episode 83: 100,000 Sites Impacted by Vulnerabilities in Advanced Access Manager

The Wordfence Threat Intelligence team discovered vulnerabilities in the Advanced Access Manager plugin installed on over 100,000 WordPress sites. A high severity authorization bypass could lead to privilege escalation and site takeover. Critical vulnerabilities found in the Quiz and Survey Master plugin could also lead to site takeover on the 30,000 WP sites using the vulnerable version of this plugin.

Thousands of sites broke after updating to WordPress 5.5 due to deprecated support for jQuery Migrate, and the release of the Enable jQuery Migrate Helper plugin reached 10,000 active installations to help fix these sites using older themes or plugins.

As cryptocurrency values rise, we’re seeing a wave of new scams and hacking campaigns with cryptocurrency as a driving force, such as the recent Twitter hack and a botnet campaign called Fritzfrog that is breaching SSH servers to mine Monero.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:10 High-Severity Vulnerability Patched in Advanced Access Manager
2:05 Critical Vulnerabilities Patched in Quiz and Survey Master Plugin
3:43 Sites updating to WordPress 5.5 breaking due to deprecated jQuery migrate, new plugin released as a fix
6:27 Fritzfrog campaign breaching SSH servers, similar to previous cryptocurrency hacking campaigns

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Episode 83 Transcript

Scott Miller:
Hey everyone, it’s Scott from Wordfence. This is Think Like a Hacker, the weekly podcast covering WordPress security and innovation. Let’s get right into this week’s stories.

Our first story of the week is the high severity vulnerability patched in the Advanced Access Manager plugin, Ram Gall, and our Threat Intel team here at Wordfence found vulnerabilities in the Advanced Access Manager plugin, which is installed on over 100,000 sites.

This high-severity Authorization Bypass vulnerability could lead to a privilege escalation and a site takeover. This plugin allows users to log in via the WordPress REST-API and unfortunately the plugins REST end points were set to respond to a successful login with a JSON-encoded copy of all metadata about the user, which can potentially expose users’ information to an attacker or a low-privileged user.

This information includes items such as the user’s hashed password and their capabilities and roles, as well as any custom metadata that might’ve been added by other plugins. Wordfence premium users received a firewall rule protecting against the Authorization Bypass vulnerability on August 14th, and sites that are still running the free version of Wordfence will receive this rule 30 days later on September 13th, 2020.

Now, lots of plugins and management systems give you the ability to customize roles for users on your site, whether you’re running a blog, an eCommerce store, or a membership site, or just adding a specific capability for certain users on your site. These additional roles require additional thought and attention, much like the plugins and management systems that are offering the features.

From a security standpoint, when it comes to issues and vulnerabilities like this regarding roles and capabilities, it’s typically recommended limiting the roles of users to only what is necessary and staying as close to the core functionality in WordPress as possible.

Our next story this week is the critical vulnerabilities patched in the Quiz and Survey Master plugin. On July 17th, our Threat Intel team found two vulnerabilities in the Quiz and Survey Master plugin, which is installed on 30,000 sites.

The Quiz and Survey Master plugin is a plugin built to allow users the ability to easily add quizzes and surveys to their site. One of the features of the plugin allows file upload implementation for quizzes and surveys. This upload feature, however, was not secure. The checks performed during a file upload only evaluated how the general settings were configured for the file upload itself.

During the upload, checks were made primarily to see if the file type and size were valid. The issue we discovered allows for unauthenticated attackers to upload arbitrary files and achieve Remote Code Execution, as well as remove arbitrary files, such as a site’s wp-config.php file, which could result in site downtime or a site takeover.

It’s recommended to update to version 7.0.1 as soon as possible. And thankfully the default Wordfence firewall rules protecting against malicious file uploads, local file inclusion, and directory traversal will protect both free and premium users from attackers targeting these vulnerabilities.

As a rule of thumb, be selective with who you provide access to your site. And more importantly, who is giving access levels greater than subscriber level. Users with these levels should always have unique and complex passwords.

Our next story this week looks at the increase in broken sites since the WordPress 5.5 core update due to depreciated support for jQuery Migrate. So, a few weeks ago, WordPress 5.5 shipped without a JavaScript library called jQuery Migrate.

jQuery Migrate is a library that basically helps old code function correctly on WordPress sites. This means if you have a plugin or a theme that is potentially no longer supported, or in other words, it’s out-of-date, it may have worked fine until updating to 5.5 where the library to help the code work was no longer included.

The result of the library not being included in the core updates so far has been 10,000 plus sites having issues. On one hand, this looks like the fault of WordPress for not including the library, but one of the real issues here is the number of sites using old themes and plugins.

Since the WordPress core update, there’s been a jQuery helper plugin released, which has surpassed the 10,000 [site] installation mark. This plugin, which was developed by the WordPress core team has provided some relief for users who have seen their site break due to the jQuery Migrate library not being included in the 5.5 core update.

This issue has exposed sites that are using older themes and plugins. And if your site was affected by these issues in 5.5, it may be a good time to look at finding replacements for those themes and plugins that are no longer supported.

If your site currently has plugins and themes that are still supported, but just out-of-date, there’s plenty of tools out there now that can help you manage updates. The new features and core that were added in 5.5 will allow you to update themes and plugins automatically and you can also use Wordfence alerts on your site to stay in tune with available updates for your themes and plugins.

You can also consider using Wordfence Central, which is a hub to add all of your Wordfence-protected sites, both free and premium and keep track of the scans and security of all the sites in one place. There’s a cool option for a summary of alerts in central that will help you with alert fatigue, and keep you up-to-date with what needs attention on your sites. The best part of it is, it’s completely free to use.

If you’re interested in some more information on auto-updates, we also have a good blog post on wordfence.com from August 6th, which is titled WordPress Auto-Updates, What Do You Have to Lose? And it details how you should go about the automatic update feature, which was introduced in WordPress 5.5. You can also check out the Wordfence livestream on YouTube from August 11th, where we go into this in depth.

In our last story this week, we take a look at the increasing value of cryptocurrency and how it’s increasing the number of attacks we’re seeing in various formats. Cryptocurrency has been increasing in value in the past few months, including the privacy focused cryptocurrency Monero.

It’s currently ranked as the 16th most valuable cryptocurrency on CoinMarketCap And it’s a favorite currency for those looking to hide their transactions, including hackers. With this rise in value, we believe we’ll start seeing more attacks using Monero mining much like what we saw with a massive crypto mining campaign, which affected WordPress sites in 2017.

We’ll include that link to our blog post in the show notes. Now, we’re already starting to see some of these attacks that have cryptocurrency as a driving force, including the recent Twitter hack, which focused on Bitcoin. In a similar story, a botnet campaign named Fritzfrog was discovered breaching SSH servers dating back to at least January 2020.

Fritzfrog used brute force to breach SSH. And once their malware was present, the malware replicated and grew in order to perform additional tasks. After some of the higher resource tasks were killed off on the server by the malware, it deployed tasks of its own, which focused on mining the Monero cryptocurrency.

In cases like these and as currency evolves, hackers won’t be far behind and there’s always a use for powerful servers, websites, and user accounts for hackers and botnets. It’s always important to monitor your server resources regularly, as well as harden your security and keep administrator, FTP, SSH, and other important accounts locked down or inaccessible until they’re needed.

That’s all for this week. Don’t forget to subscribe to our mailing list on wordfence.com, as well as check us out on Wordfence, live on YouTube every Tuesday at noon, Eastern 9:00 AM Pacific time where we talk all things WordPress and security. From all of us here at Wordfence, thanks for tuning in to Think Like a Hacker. And we look forward to catching up with you next week.

Follow me on Twitter @wfscottmiller. You can find Wordfence on Twitter, Facebook, Instagram. You can also find us on YouTube, where we have our weekly Wordfence Live on Tuesdays at noon Eastern, 9:00 AM Pacific.

The post Episode 83: 100,000 Sites Impacted by Vulnerabilities in Advanced Access Manager appeared first on Wordfence.

Episode 84: Google Chrome Plans to Implement Insecure Form Warnings

The Google Chrome web browser has a high-severity vulnerability that could be used to execute arbitrary code, which has been fixed in Chrome version 85. Google also announced that Chrome 86 will alert users if a form submission is using the insecure HTTP protocol, making it a good time to audit older sites that may have migrated to HTTPS, but still have forms submitting via HTTP.

A security researcher found a flaw in Apple’s Safari browser that could allow an attacker to access files on a Mac or iOS device.

The FBI and CISA have issued a joint alert to warn about the growing threat from vishing attacks targeting companies.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:12 Chrome patches vulnerability that could be used to execute arbitrary code
1:20 Google announces Chrome 86 will alert users to insecure form submissions
2:55 Safari browser zero-day vulnerability could lead to leaking files to an attacker
4:40 FBI-CISA joint alert about growing vishing threat

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Episode 84 Transcript

Scott Miller:

Hello everyone. It’s Scott from Wordfence. This is Think Like a Hacker, the weekly podcast about WordPress security and innovation. Let’s get right into this week’s stories.

First up a couple of stories relating to the Google Chrome browser. A patch was released for Google Chrome this week, which fixed a vulnerability that could potentially allow code execution. The flaw, which is called a use-after-free vulnerability was in the graphics library component of Chrome. This was part of the functionality that lets users render 2D and 3D graphics. The issue came about from improperly handling memory. If the memory layout of the browser were manipulated by an attacker, they could gain control and ultimately it could lead to arbitrary code execution. An attacker could execute code via one of the vulnerable functions, which was used to sync data. When that was done, it then creates the use-after-free condition mentioned earlier. This can occur from attempts to access memory after it’s been freed up, which can then result in a program crashing or potentially result in execution of arbitrary code. So currently the thing to do here is check your current browser version and make sure that you’ve updated to Chrome 85, which should be available for you now.

In another story regarding the popular web browser, Google said in an upcoming release of Chrome, that they will be restricting forms that are sent via HTTP protocol. This is a push to have site owners review their site and be sure that forms are transmitting data via the secure HTTPS protocol. It’s important to be sure that all of the data on your site is being transmitted securely. And if you’ve recently migrated to HTTPS, double check to be sure that your forms are transmitting data securely to reduce any chance of being alerted or warned by Google of the issue, which could potentially end up resulting in a loss of revenue, depending on what your forms are used for.

If your forms are not transmitting data securely, you’ll see a message alerting you that the form is not secure. And you’ll also see an alert that autofill has been disabled for the form. Your visitors will also see these messages as well. An additional warning will be then shown to the site visitor when they attempt to submit data via that form and the warning will give the visitor an opportunity to continue with the data submission or cancel the submission at that point. One thing to consider as a site owner is checking your browser console for warnings that mention mixed content being loaded on the site. If you’re seeing that message, you can then find some tools with a Google search or via the WordPress plugins area to help automatically fix insecure and mixed content being loaded. Chrome 86 will feature these changes and it’s due to be released on October 6th, 2020.

Sticking with browser related news, Safari has a zero day vulnerability affecting the Mac OS and iOS browsers. The vulnerability allows an attacker to access files that are stored on the user’s local hard drive. This bug was discovered by the polar security firm REDTEAM.PL. The vulnerability resides in the Safari web share API, which introduces the ability to share text, links, files, and other things cross-browser. Visiting a malicious site set up for this vulnerability could open your device to this issue and result in leaking out the private stored local files from your device. After repeatedly chasing Apple about this vulnerability, the researcher who discovered the zero day was notified by Apple, that it would not be patched until the April 2021 security update and then he took it upon himself to disclose the issue in advance. Now, the researcher who disclosed the bug has described it as not very serious due to the fact that the user would need to be tricked into a situation to leak out the files.

However, the attack itself can be hidden well. The vulnerability is not easy to carry out, and it does require some user interaction, as I mentioned, which draws comparison to a social engineering attack. But the founder of the issue mentions that barriers for the bug are far from insurmountable and demonstrates the bug and a proof of concept video, which you can check out on YouTube. So as this has not yet been patched and may not be for some time, it’s always a good rule of thumb to double check where you’re browsing at any given time and always be aware on what you’re clicking and who you’re giving information to.

In our last story for this week, the FBI and CISA, which is the Cyber Security and Infrastructure Security Agency, issued an alert warning about the growing threat of voice phishing, or vishing, attacks. Now you might be wondering what is vishing? Vishing is a form of fishing where during a voice call, a scammer will attempt social engineering to get you to share personal information or company information, to help them with their attack. This can result in an attacker gaining access to employee tools with the end goal of monetizing the access. KrebsOnSecurity took a look at a crime group, which is offering to steal VPN credentials and other data from employees working remotely during the pandemic. In their article they mentioned in the joint FBI-CISA alert that the vishers are said to be compiling information on the employees using public profiles on social media sites and other readily available services, such as background checks.

In the alert it’s noted that in some cases, unsuspecting employees granted access to these vishers, even helping them bypass 2FA and/or one-time passwords (OTP). In other cases, attackers were able to gain access to the necessary one-time codes by targeting the employee with SIM swapping, which is a technique that involves social engineering an employee at a mobile phone company, which would then result in the employee giving them control of the target’s phone number, allowing them to access the 2FA code. One way around this for companies that are working remotely is the approach that Google took in requiring all employees to use physical security keys in place of one-time codes. You can check out USB and USBC versions of these physical security keys from the company Yubico who offers the YubiKey.

That’s all this week for Think Like a Hacker. Take a second to subscribe to our mailing list in the footer of the Wordfence.com homepage and keep up to date with any breaking security news there. Until next week from all of us here at Wordfence, have a great weekend and we’ll catch you soon.

Follow me on Twitter @wfscottmiller. You can find Wordfence on Twitter, Facebook, Instagram. You can also find us on YouTube, where we have our weekly Wordfence Live on Tuesdays at noon Eastern, 9:00 AM Pacific.

The post Episode 84: Google Chrome Plans to Implement Insecure Form Warnings appeared first on Wordfence.

10 WordPress Security Mistakes You Might Be Making

10 WordPress Security Mistakes You Might Be Making

Yesterday, August 18, 2020, the Wordfence Live team covered 10 WordPress Security Mistakes You Might be Making. This companion blog post reviews the recommendations we provided to avoid these mistakes and better secure your WordPress environment.

You can watch the video of Wordfence Live below.


You can click on these timestamps to jump around in the video.

  • 11:24 #10:Changing the WordPress login URL.
  • 16:00 #9: Not using SSL/TLS certificates on your WordPress site.
  • 19:00 #8: Using “admin” as your WordPress administrative username.
  • 22:30 #7: Using weak passwords.
  • 24:05 #6: Not using a Web Application Firewall like Wordfence.
  • 41:18 #5: Insecure hosting choices.
  • 44:50 #4: Poor user access management.
  • 48:13 #3: Using nulled plugins or themes.
  • 49:54 #2: Reusing passwords in multiple locations.
  • 51:28 Mistake #1: Not updating WordPress plugins, themes or WordPress core.

Mistake Number #10: Changing the WordPress login URL.

Some WordPress users request that Wordfence add the ability to change a site’s login URL. For example, instead of logging into WordPress at wp-login.php, a site owner can use methods of changing the login URL to something completely different. There is a reason we haven’t implemented the feature in Wordfence and why we don’t recommend hiding a site’s login as a security measure. Hiding the login URL is security through obscurity, which often leads to a false sense of security.

WordPress login URLs can easily be detected and bypassed by most attackers. Therefore, it’s not the best technique to limit login attempts and potential attacks. A site owner with a renamed login URL feels their site’s login is adequately protected, but is missing several very important security control mechanisms.

Instead of changing your sites login URL, we recommend:

  • Enabling brute force protections. This includes locking out excessive login requests. Brute force protection is available in both the free and premium versions of Wordfence by going to Firewall Options > Brute Force Protection. .
  • Using strong passwords. This will help prevent brute-force and password guessing attacks from being successful. Please see the section “Using weak passwords” for our recommendations on creating strong passwords.
  • Adding .htpasswd protection to your wp-admin area. On a web server, .htpasswd uses flat-files to store usernames and passwords for basic authentication of HTTP users. These protections are outside of your WordPress PHP/MySQL configurations and secure access to the files that your administrative dashboard uses for managing your site. Please know that when you do this, you may need to whitelist admin-ajax.php in the .htaccess file if your site uses any front-end AJAX requests.
  • Using two-factor authentication. This adds a second layer of protection to your login form. If an attacker is able to successfully get access to a compromised password, they will be unsuccessful at logging in due to the second layer of authentication. Two-factor authentication is available in both free and premium versions of Wordfence. You can find this by going to the Login Security section of your Wordfence dashboard. .

By taking these steps to improve your site’s login security, you’re addressing real attack vectors with solid protections.

Mistake Number #9: Not using SSL/TLS certificates on your WordPress site.

SSL/TLS certificates are often misunderstood and frequently a missed step in securing WordPress sites. However, they are vital to protect the confidentiality of the data in transit from your site visitors’ browsers to your webserver. They also have an impact on your site’s search rankings as Google favors sites using SSL.

What is an SSL certificate?

SSL/TLS certificates encrypt the traffic between clients and servers and securely send data over HTTPS. An SSL/TLS certificate essentially makes it possible to convert all of the traffic being sent over the internet between a client and your server into a non readable form by encrypting, or “jumbling” up, the data with the use of a key. Only the webserver has a key to decrypt or “de-jumble” that data and respond to the requests again with the data encrypted, or “jumbled,” in the response.

One simple example of why you need an SSL/TLS certificate is that WordPress sends credentials in plaintext. This is what an attacker sniffing a network can see if there is no SSL/TLS certificate installed on a site when someone logs on to a WordPress site:

Wireshark packet capture showing WordPress login with no SSL/TLS certificate.

With this data exposed, an attacker can take the host information, username, and password and then gain access to your WordPress site. Worse yet, sites that take payments may send payment information in plain text, a human readable format, due to the lack of an SSL/TLS certificate, making it possible for attackers to steal that information in transit. Your site users’ data can be significantly impacted if you are not using an SSL/TLS certificate, and that is why search engines favor sites with these important security measures in place.

Here is an example of what an attacker sniffing a network can see if there is a SSL certificate installed on a site when someone logs on to a WordPress site:

Wireshark Packet Capture showing same request encrypted from SSL/TLS certificate.

It’s clearly unreadable and impossible to decipher exactly what is going on in the requests.

Several hosting providers offer one click solutions that will deploy a free SSL/TLS certificate to your site. Let’s Encrypt is a nonprofit with a mission to create a more secure and privacy-respecting Web by promoting the widespread adoption of HTTPS. They offer free and easy to use SSL certificates so that every website can easily deploy HTTPS.

Mistake Number #8: Using “admin” as your WordPress administrative username.

Another common mistake that we see quite often is WordPress site owners still using the default ‘admin’ username for their primary administrative user account. This can have a negative impact on your site due to bots attempting to brute force a password for the ‘admin’ user or exploit vulnerabilities using ‘admin’ as the default username in their scripts.

We have seen some vulnerabilities in the past that have relied on WordPress site’s having the default user account username set to ‘admin,’ like the privilege escalation vulnerability discovered by WebARX in the ‘ThemeGrill Demo Importer’ plugin. Having a username other than the default ‘admin’ would have kept users safe from the privilege escalation portion of this vulnerability, thus making the exploit less attractive to attackers and reducing the impact if your site were to be compromised.

There are two ways you can correct this. The first way is to create a new administrative user account with a new username and delete the old ‘admin’ account. The username can be something complex or something relatively simple but unique. The more complex, the harder it may be for attackers to discover the username. If using this method to change the default username, you must make sure to attribute all content created to the new user when you are deleting the old admin account.

The second way you can change your username is by going directly to your database using phpMyAdmin from your hosting account, or similar database management tool, and updating the username in the *_users table. This is the simplest way to change your default administrative username, and what we recommend.

Changing default WordPress ‘admin’ username in phpMyAdmin.

Regardless of which method you decide, as with any change, we recommend taking a backup beforehand so that if anything goes wrong during the process you can quickly restore the site.

Once you’ve changed your username to a stronger username, navigate to the Wordfence Firewall and find the setting to ‘Immediately block the IP of users who try to sign in as these usernames’ and paste ‘admin’ into that field. This will provide another layer of login protection and automatically block any bots trying to attack your site using the default ‘admin’ username.

Mistake Number #7: Using weak passwords.

This is one of the most common mistakes across the web, and we are not just talking about WordPress sites. Strong passwords are the front-line defense against brute-force attacks and compromised user accounts, thus it is one of the most important things to take into consideration when making sure your site is secure.

Passwords like ‘password1234,’ ‘qwerty,’ ‘mydogsname,’ are all too common and way too simple. It takes just seconds to brute force or manually guess weak passwords, thus only taking attackers seconds to get into your account.

Testing the password strength for ‘ilovecats’ as a password.

We highly recommend taking the following measure to stop using weak passwords:

  • Create Strong Complex Passwords. Your passwords should consist of more than 10 characters, with at least one number, one symbol, and one uppercase character. The more diverse and complex the password is, the longer it would take an attacker to guess your password and gain access into your account or WordPress site.
  • Use a Password Manager. This will help you store the complex passwords for all of your various sites so you are not reusing passwords across sites. One compromised password used on one site can lead to several other site accounts being compromised if you are using the same password regardless of its complexities.
  • Check your password on haveibeenpwnd.com. Have I been pwned is a great resource to monitor online accounts that have known compromised passwords. In the event a password gets compromised for an account, you should change it immediately.

Mistake Number #6: Not using a Web Application Firewall like Wordfence.

Web application firewalls are vital for open-source projects like WordPress that have thousands of people contributing to the themes and plugins on the world’s most popular content management system.

What is a Web Application Firewall (WAF)?

A WAF acts as a gateway, checking requests from users to determine what is allowed and what is not allowed. Whenever a request is deemed “allowed,” like a legitimate user is logging on a site, the firewall will allow the request to go through. When a request is deemed “not allowed” due to a firewall rule, then the WAF will block that request.

What is a firewall rule?

A firewall rule is an instruction that tells the firewall when to accept or reject a request. A very basic firewall rule in the format of a statement would look like this:

If the request body contains <script> then block due to potential cross-site scripting attack.

Why is it important?

WAF’s block malicious attacks, like an attacker attempting to exploit a vulnerable plugin, and ultimately protect your site from getting compromised. Vulnerabilities are constantly discovered in WordPress themes and plugins, and WordPress, powering over 35% of the internet, is constantly under attack. Not having a firewall is like leaving your front-door unlocked with a sign in your backyard saying the front-door is unlocked in a neighborhood with roving attackers looking for their next victim.

You can harden and patch, but if a zero-day vulnerability is discovered and actively exploited before a developer has a chance to patch, then a WAF may be your only hope until a patch has been released.

Wordfence’s built-in Web Application Firewall.

The Wordfence plugin’s built in Web Application Firewall has a generic list of firewall rules that provide blanket coverage for the most targeted vulnerabilities like Cross-Site Scripting, Arbitrary File Uploads, SQL injection, Directory Traversal, and more. This means our web application firewall provides a very extensive coverage baseline. Our Threat Intelligence team then enhances that coverage by creating custom firewall rules for plugin, theme, and core vulnerabilities for specific coverage of vulnerabilities that will likely be attacked.

Wordfence web application firewall blocking a malicious request.

Mistake Number #5: Insecure hosting choices.

Poor hosting choices can have detrimental security consequences on your WordPress site. You want to make sure your hosting provider offers all the functionality you need to ensure that your WordPress site is secure, and that you are making the right choices when it comes to how you host your sites.

When setting up hosting, look for the following.

  • Will your account be properly isolated? Make sure your site will be properly isolated if running in a shared hosting environment. This includes making sure not to run multiple sites on the same hosting account, and making sure you remove old sites that are not in use. Make sure that, if another site hosted on the same server gets compromised, it won’t affect your site. It doesn’t matter how secure you make your main site if an older, insecure version of your site in a subfolder gets hacked.
  • Does the host provide access logging? Logs will help you determine when and if an intrusion has occurred. This helps you determine what happened so you can prevent it from happening again.
  • Do they allow you to install an SSL/TLS certificate for free? Most solid hosting providers let you know that security is a priority by offering this for free from providers like Let’s Encrypt.
  • Do you have a dedicated IP address? Sharing IP addresses can lead to your site getting blacklisted if another site hosted on the same IP address is hacked and gets blacklisted. This could affect your site’s reputation just by being in the wrong neighborhood.
  • Do they offer SSH/SFTP/FTPS? Just like with SSL/TLS certificates, SSH, FTPS and SFTP offer a means of transferring data over an encrypted channel so that data can’t be easily intercepted. You want to make sure your hosting provider offers this option instead of plain text FTP so that file transfer data can’t be easily read by an attacker on your network.

Mistake Number #4: Poor user access management.

User access management is often overlooked by WordPress site owners. User registrations and the default roles assigned to those users can lead to compromise when done haphazardly.

We recommend considering the following practices.

  • Grant users minimal access. Follow the principle of least privilege by granting users the minimum amount of privileges they need to on your site. For most standard sites this will be “Subscriber” and for most WooCommerce sites this will be “Customer.” You can set this value by going to the user management area of wp-admin
  • Disable user registration unless it is required. If your site has no areas that require user registration, then disable this feature. Several WordPress vulnerabilities discovered in the past have required some level of user permissions. By disabling user registration, you eliminate some risks of several vulnerabilities.
  • Enforce strong passwords. With your administrative accounts using strong passwords, ensure that your users are also using strong passwords. As these accounts can also become a target for attackers, make sure they are optimally secured. You can do this with Wordfence by going to the Wordfence Brute Force Protection section and enabling the option to “Enforce Strong Passwords.”
  • Require 2-factor authentication for administrators and publishers. This can be enabled in the Wordfence Login Security section.

Fine tuning WordPress User Registration.

Mistake Number #3: Using nulled themes or plugins.

Nulled themes and plugins are premium themes and plugins that are offered for free on “nulled” offering sites. These sites often look illegitimate and offer premium plugins and themes as “free,” “nulled” or “unlocked.”

Example of nulled theme/plugin site offering premium plugins for free.

These nulled themes and plugins almost universally contain malicious code that will infect your site, and any other sites hosted in the same account, as soon as they are installed. One recent example of an infection campaign stemming from nulled theme and plugin use was wp-vcd.

It can often be hard to determine the root cause of this type of infection as most people aren’t aware that they actually infected their own site with malware by installing one of these nulled themes or plugins. Always source your plugins and themes from the original developers, a reputable marketplace, or the wordpress.org directory.

Mistake Number #2: Reusing passwords.

A common, yet simple mistake WordPress users often make is reusing passwords across accounts. When our Security Services Team cleans infected sites, they often find sites using the same password for their hosting account, WordPress website, and FTP account. Of course, if one account gets compromised, all the accounts get compromised.

Even beyond your WordPress installation, we recommend using unique passwords for every account you use. Using the same password on another site that is then compromised as well as your WordPress site can be detrimental. Our Security Services Team has performed a number of high profile incident response investigations that determined passwords used on other sites, as well as the WordPress site or even on WordPress.com-connected sites using Jetpack, led to extensive intrusion with admin accounts being compromised.

Our simple recommendation for this is just to not reuse passwords. We highly recommend using a password manager such as 1Password or LastPass to store long complex passwords that will help make sure that all of your digital assets, from your WordPress site to your accounts with financial institutions are protected.

Wordfence also has an option to prevent the usage of passwords found in data breaches, This option applies to administrators by default, but can be set to include all users that can publish blog posts.

Mistake Number #1: Not updating core, themes, plugins.

The majority of hacked sites cleaned by our Security Services Team were compromised due to vulnerable plugins, themes, or even outdated core WordPress installations. All of these intrusions could have been prevented by practicing good habits in maintaining your WordPress installation.

To stop making this mistake, we recommend updating your plugins, themes, and core as soon as a security patch is released. Use a management or maintenance tool like Wordfence Central if you have numerous WordPress sites to manage. Wordfence Central is completely free, and it allows you to set up alerts for security events, including when the Wordfence Scanner detects outdated and vulnerable plugins. Wordfence Central links to each site’s wp-admin so that you can easily update your themes and plugins, and allows you to view which sites require action based on their scan results, making performing WordPress updates easier and faster.


We’re all human and mistakes happen. Sometimes important security decisions are simply overlooked or forgotten about, so it’s always a good idea to revisit your WordPress site and check on its current security posture.

We hope that providing you with these 10 WordPress security mistakes will encourage you to check on your site and make sure you are following the best practices associated with a secure WordPress environment. If you are not, we have provided you with some of our recommendations to help fix those security mistakes.

If you have any friends and colleagues using WordPress, share this post with them. The safer we make the entire WordPress community, the safer we all are from attackers looking to compromise WordPress sites.

Want more? Check out these three additional mistakes that you might be making not already covered by this post.

The post 10 WordPress Security Mistakes You Might Be Making appeared first on Wordfence.

Episode 82: Important Changes in the WordPress 5.5 Update

WordPress 5.5 was released on August 11 with a number of important updates, including a new feature allowing auto-updates of themes and plugins as well as changes to the block editor. The popular Astra theme was suspended from the repository for having affiliate links in the code.

A vulnerability found in Google Chromium browsers could allow attackers to bypass content security policy in order to steal data and execute rogue code, this vulnerability affects billions of users. The Wall Street Journal reported that government tracking software is embedded in over 500 mobile apps.

Here are timestamps and links in case you’d like to jump around, and a transcript is below.
0:12 WordPress Auto-Updates: What do you have to lose?
2:17 Astra theme suspended and reinstated
3:57 Google Chrome browser bug exposes billions of users to data theft
5:35 WSJ Report: Hundreds of apps have hidden tracking software used by the government

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast. Subscribe to our RSS feed.

Episode 82 Transcript

Scott Miller:
Hey everyone, it’s Scott from Wordfence. This is another edition of Think Like a Hacker, the weekly podcast about WordPress, security and innovation. let’s get right into the news.

Our first story of the day is the WordPress 5.5 update. So on Tuesday, August 11th, WordPress released their 5.5 update, and it allows automatic updates to be enabled for individual plugins and themes. Auto-updates will be disabled by default, but you can enable the ability for those plugins to update automatically by the plugin section of your site. Now, the addition of auto-updates improves site security by shortening the time that it takes to get plugins updated. And this can be big if there are security updates in those plugins. Now auto-updates do pose some problems, and we talked about that at length on our Office Hours stream this week, and you can find that on the Wordfence YouTube channel by searching Wordfence Office Hours on YouTube.

So depending on the kind of site that you’re running and how often you log in to check on things, auto-updates might be a good idea to keep things up to date and protected. If you’re a larger business and you have eyes on the site very frequently, it might be best to start off slow and continue updating your plugins manually for now. If you’d like to read more about how these auto-updates can impact your site, we have a great blog post on wordfence.com titled WordPress Auto-Updates: What do you have to lose? That was posted on August 6th and you can head over there and check it out on the blog.

Also introduced in WordPress 5.5 were multiple user interface changes to the block editor, which was initially introduced in WordPress 5.0 in 2018. These UI changes make adding, editing, and moving blocks in your posts and pages a bit more fluid. Also included in WordPress 5.5 were site maps, which WordPress will generate for you by default and a new lazy-load feature, which aims to save on bandwidth and speed your site up. How this works is it basically only loads images that are in view of the browser window for your visitor at any given time. So this is a nice impact on speed and performance.

Our second story this week is the Astra theme suspension. This is the first non-default WordPress theme to break the 1 million install mark and not long after it did, it was suspended due to breaking a rule on having affiliate links in the code. Shortly after a back and forth between the themes team and the theme authors, the theme was then reinstated. However, the ongoing penalty at the moment is that the theme is absent from the popular themes list. The way the popular themes list works is it uses the themes date of publication, as well as the number of downloads to determine a theme’s popularity. So what the theme team did was they changed the date for the theme to push it down the popular list. Delisting a theme like this is a way for the themes team to deal with guideline violations while not outright suspending a theme. And such as in this case, the users will still then have access to new updates.

It’s worth noting that this is the company’s first violation and while Brainstorm Force, the team behind the Astra theme, didn’t directly add affiliate links, they did inject the company’s referral ID into affiliate links for third party plugins. Since the initial encounter, an additional week has been added to the suspension when another affiliate related violation was found. These penalties can result in a large loss in revenue. And in a similar case, the Zerif Lite theme received a suspension and it resulted in a significant revenue loss. The Zerif Lite theme had only about one third of the active users that Astra has.

Next up, a vulnerability was found in the Google Chromium browsers, which would allow attackers to bypass CSP, content security policy, in order to steal data and execute rogue code. This vulnerability affects Chrome, Opera and Edge on Windows, Mac, and Android, which spans to potentially affect billions of users. The affected versions are Chrome version 73 through version 83. The issue was patched in Chrome version 84, which was released last month in July. The vulnerability was then present for more than a year before the patch. Now content security policy is a standard method to enforce data security and it’s used by a lot of major companies, such as Facebook, ESPN, Gmail, to just name a few.

And it’s used to prevent attacks such as cross-site scripting and data injection attacks. In order for this vulnerability to have been exploited, an attacker would have first had to have gained access to the web server. And that could have been done via social engineering or brute forcing, among other things. After gaining access, attackers could have then altered the JavaScript code that the server uses to load and inject code resulting in a bypass of the CSP. So a couple things, be sure to check and see if you’re on the latest version of your web browser, and it’s also advised to audit your browser by checking your browser extensions and remove anything that you either aren’t familiar with or that you no longer use.

And our last story for this week, a new report by The Wall Street Journal has exposed government tracking software in over 500 mobile apps. Anomaly Six, a Virginia-based company included it’s tracking code within their mobile apps, which then collected data from mobile devices and that data was then sold to the US government. In the report, it’s mentioned that Anomaly Six would not name any of the apps that their software is currently included in. Now, if there’s a bright side, it’s that the data collected is anonymous. Though, as we’ve seen in cases in the past, there are methods along the way for identifiers to be used to associate data with an individual. It appears that at the current time, what is being done here is legal and it’s also mentioned that it’s clear that we’re behind on laws and regulations with regard to collecting this kind of information, even anonymously.

Currently, there is no way to tell if we’re even using one of these apps right now. So it might be a good time to audit our phones as well. So you can do that by just going through and looking at some apps that you don’t commonly use, or you don’t use it all and go ahead and get rid of those. You also might be asking, “What is the government doing with this anonymous information?” And I think a lot of us are wondering the same thing. So drop us a comment in our show notes on wordfence.com/podcast and give us your thoughts on this or any of our other stories today.

That does it for this week’s edition of Think Like a Hacker. Be sure to check us out on Wordfence Office Hours, which airs every Tuesday at noon, Eastern 9:00 AM Pacific, where we talk all things WordPress and Wordfence security. I hope today’s news found you well, and we’ll be back next week on Think Like a Hacker. From all of us here at Wordfence, have a great weekend and we’ll see you next time.

Follow me on Twitter @wfscottmiller. You can find Wordfence on Twitter, Facebook, Instagram. You can also find us on YouTube, where we have our weekly Wordfence Live on Tuesdays at noon Eastern, 9:00 AM Pacific.

The post Episode 82: Important Changes in the WordPress 5.5 Update appeared first on Wordfence.

Newsletter Plugin Vulnerabilities Affect Over 300,000 Sites

On July 13, 2020, our Threat Intelligence team was alerted to a recently patched vulnerability in Newsletter, a WordPress plugin with over 300,000 installations. While investigating this vulnerability, we discovered two additional, more serious vulnerabilities, including a reflected Cross-Site Scripting(XSS) vulnerability and a PHP Object Injection vulnerability.

We reached out to the plugin’s author on July 15, 2020, and received a response the next day. After fully disclosing the vulnerability on July 16, 2020, the plugin’s author released a patch the next day, on July 17, 2020.

A firewall rule to protect against the Reflected Cross-Site Scripting vulnerability was released to Wordfence Premium customers on July 15, 2020 and will become available to free Wordfence users 30 days later, on August 14, 2020.

Although the PHP Object Injection vulnerability would require additional vulnerable software to be installed, and our built-in PHP Object Injection protection would have protected against the most common exploits, we determined that a bypass was possible. Out of an abundance of caution, we created an additional firewall rule and released it to Wordfence Premium users on July 28, 2020. The PHP Object Injection firewall rule will become available to free Wordfence users on the same date as the XSS rule for this plugin, on August 14, 2020.

Description: Authenticated Reflected Cross-Site Scripting(XSS)
Affected Plugin: Newsletter
Plugin Slug: newsletter
Affected Versions:
CVE ID: Pending
CVSS Score: 6.5(Medium)
Fully Patched Version: 6.8.2

The Newsletter plugin includes a full-featured visual editor that can be used to create visually appealing newsletters and email campaigns. It uses an AJAX function, tnpc_render_callback, to display edited blocks based on a set of options sent in the AJAX request. Unfortunately, the vulnerable versions did not filter these options, but passed them onto a second function, restore_options_from_request which used multiple methods to decode options that were passed in before displaying them using the render_block function.

    function tnpc_render_callback() {
        $block_id = $_POST['b'];
        $wrapper = isset($_POST['full']);
        $options = $this->restore_options_from_request();

        $this->render_block($block_id, $wrapper, $options);

As such, it was possible for an attacker to get malicious JavaScript to display in multiple ways. The simplest method would involve sending a POST request to wp-admin/admin-ajax.php with the action parameter set to tnpc_render, the b parameter set to html, and the options parameter set to arbitrary JavaScript. Alternatively, a similar request with the options parameter set to an empty array options[]= and the encoded_options parameter set to a base64-encoded JSON string containing arbitrary JavaScript would also result in JavaScript being rendered in a logged-in user’s browser.

            if (isset($_POST['encoded_options'])) {
                $decoded_options = $this->options_decode($_POST['encoded_options']);
    function options_decode($options) {

        // Start compatibility
        if (is_string($options) && strpos($options, 'options[') !== false) {
            $opts = array();
            parse_str($options, $opts);
            $options = $opts['options'];
        // End compatibility

        if (is_array($options)) {
            return $options;

        $tmp = json_decode($options, true);
        if (is_null($tmp)) {
            return json_decode(base64_decode($options), true);
        } else {
            return $tmp;

We discussed Reflected XSS vulnerabilities in a previous post. Despite the fact that they require an attacker to trick a victim into performing a specific action (such as clicking a specially crafted link), they can still be used to inject backdoors or add malicious administrative users. If an attacker tricked a victim into sending a request containing a malicious JavaScript using either of these methods, the malicious JavaScript would be decoded and executed in the victim’s browser.

Description: PHP Object Injection
Affected Plugin: Newsletter
Plugin Slug: newsletter
Affected Versions:
CVE ID: Pending
CVSS Score: 7.5(High)
Fully Patched Version: 6.8.2

Although the Newsletter editor did not allow lower-level users to save changes to a given newsletter, the same tnpc_render_callback AJAX function was still accessible to all logged-in users, including subscribers. This introduced a PHP Object Injection vulnerability via the restore_options_from_request function. This function unserialized data passed in via the options[inline_edits] parameter. As such, an attacker logged-in as a subscriber could send a POST request to wp-admin/admin-ajax.php with the action parameter set to tpnc_render and the options[inline_edits] parameter set to a serialized PHP object.

        if (isset($_POST['options']) && is_array($_POST['options'])) {
            // Get all block options
            $options = stripslashes_deep($_POST['options']);

            // Deserialize inline edits when
            // render is preformed on saving block options
            if (isset($options['inline_edits']) && is_serialized($options['inline_edits'])) {
                $options['inline_edits'] = unserialize($options['inline_edits']);

Although the Newsletter plugin itself did not use any code that would allow additional exploitation, this vulnerability could be used to inject a PHP object that might be processed by code from another plugin or theme and used to execute arbitrary code, upload files, or any number of other tactics that could lead to site takeover.

How does PHP Object Injection Work?

PHP can make use of a method called “serialization” to store complex data. In most cases serialized data consists of key => value arrays, for example:
This serialized data sample includes a productName property which is set to apple and a price property which is set to 10.

Serialized data is useful for storing settings in bulk, and many WordPress settings are stored as serialized data. Unfortunately, serialized data can also cause a security issue because it can be used to store PHP objects.

What are PHP objects?

Most modern PHP code is object oriented, meaning that code is organized into “classes.” These classes act like a basic template containing both variables (referred to as “properties”) and functions (referred to as “methods”). A running program can then create “objects” based on these templates, or classes. This creates not only a clear, concise structure for handling data, making code easier to maintain, it allows the same code to be reused for multiple similar tasks.

For instance, an online store could use a single class for products with properties(variables) including $price and $productName, and create a different object for each product. Each object would use the same function(method) to calculate tax, but could use a different price and product name.

If a plugin unserializes data provided by users without sanitizing that user’s input, then an attacker can send a specially crafted payload that would be unserialized into a PHP object.

On its own, an injected PHP object is not particularly dangerous. This changes, however, if the class it is based on uses so-called “magic methods”.

What are magic methods?

Magic methods are special functions that can be added to a class that describe what it should do when certain events happen.

For instance, the __destruct function is used in many classes to “clean up” once an object is done being used, and in many cases it does this by deleting files.

Here’s a very basic example of a vulnerable class that calculates product prices, stores a log, and deletes the log when it’s done:

class Product{

    public $price;
    public $productName;
    public $savedPriceFile;

    function __construct($price, $productName){

    function calculateTotal($quantity) {
        $total=$this->price * $quantity;
        echo ($total);
        file_put_contents($this->savedPriceFile, $total);

    function __destruct(){


If this code was running on a site that also had a PHP Object Injection vulnerability, an attacker could delete the wp-config.php file containing the WordPress site’s core configuration settings by sending a payload similar to the following:


This would inject a Product object, with the $productName set to apples, the $price set to 2, and a $savedPriceFile property set to wp-config.php. Even though the object might not be used by anything else, eventually the __destruct function would run, deleting whatever $savedPriceFile was set to. In this case, the deletion of the wp-config.php file would reset the site and allow an attacker to take over by pointing the site’s new configuration to a remote database under their control.

Successfully exploiting this chain of events, also known as a “POP chain”, does require some degree of effort, since it requires:

  • Code that unserializes user input (an Object Injection vulnerability).
  • Code that uses a magic method in an insecure way.
  • Both of these need to be loaded at the same time.

Due to the fact that many plugins and themes load some, or all, of their classes on each request to the site, this is not as great of a restriction as it might appear. Additionally, although insecure usage of these “magic methods” is less common than it was in the past, such usage is not considered a vulnerability on its own since it requires the presence of a PHP Object Injection vulnerability to exploit.

Finally, although an attacker might need to know which plugins are installed in order to tailor their attack to a given POP chain, it is often fairly simple to determine this with scanning tools. The good news is that such vulnerabilities are difficult to automatically exploit in bulk, except in cases where a PHP Object Injection vulnerability and an insecure magic method are both used in the same plugin.


July 13, 2020 – Our Threat Intelligence Team begins investigating a recently patched vulnerability in the Newsletter plugin.
July 14, 2020 – During our investigation, we discover 2 unpatched vulnerabilities.
July 15, 2020 – We release a firewall rule for the reflected XSS vulnerability to Wordfence Premium users and reach out to the plugin’s author.
July 16, 2020 – We receive a response from the plugin’s author and provide full disclosure.
July 17, 2020 – Plugin author releases a patch for both vulnerabilities.
July 28, 2020 – We determine that an additional firewall rule is necessary to ensure full coverage for the PHP Object Injection vulnerability and release it to Wordfence Premium users.
August 14, 2020 – Both firewall rules become available to free Wordfence users.


In this blog post, we discussed 2 vulnerabilities in the Newsletter plugin, including a reflected XSS vulnerability and a PHP Object Injection vulnerability. We also explained what PHP Object Injection vulnerabilities are and how they can be exploited.

We strongly recommend updating to the latest version of the Newsletter plugin as soon as possible. As of this writing, that is version 6.8.3.

Wordfence Premium users have been protected against the majority of potential attacks since July 15, 2020, and have been fully protected since July 28, 2020. Sites still running the free version of Wordfence will receive firewall rules protecting against both vulnerabilities on August 14, 2020.

Special thanks to Stefano Lissa & The Newsletter Team for their rapid response in patching these vulnerabilities.

The post Newsletter Plugin Vulnerabilities Affect Over 300,000 Sites appeared first on Wordfence.

Pin It on Pinterest