Security Advisory: XSS Vulnerability Affecting Multiple WordPress Plugins

Multiple WordPress Plugins are vulnerable to Cross-site Scripting (XSS) due to the misuse of the add_query_arg() and remove_query_arg() functions. These are popular functions used by developers to modify and add query strings to URLs within WordPress.

The official WordPress Official Documentation (Codex) for these functions was not very clear and misled many plugin developers to use them in an insecure way. The developers assumed that these functions would escape the user input for them, when it does not. This simple detail, caused many of the most popular plugins to be vulnerable to XSS.

To date, this is the list of affected plugins:

There are probably a few more that we have not listed. If you use WordPress, we highly recommend that you go to your wp-admin dashboard and update any out of date plugins now.

This issue was first identified by Joost from Yoast in one of his plugins (he did a great write up about it as well). We worked together with him to investigate the issue and found that it likely affected a lot more plugins than just that one.

Our research team, along with a few friends (especially Joost from Yoast ) have been going through the WordPress repository for the last few days in an attempt to find and warn as many plugin developers as possible – to warn and help them patch the issue.

Coordinated Disclosure

This vulnerability was initially discovered last week, due to the varying degrees of severity and more importantly, the large volume of plugins affected, we coordinated a joint security release with all developers involved and the WordPress core security team. It was great team work, and a pleasant experience to see so many developers united and working together for the common good. We can happily say that all plugins have been patched, and as of this morning updates should be available to all users. (yes, everyone pushed their updates in unison 2 hours ago).

If you use WordPress, now it is your turn to update your plugins!

If you have automatic updates enabled, your site should already be patched, especially in the most severe cases.

There are more plugins vulnerable

Our team only analyzed the top 300-400 plugins, far from all of them as you might imagine. So there are likely a number of plugins still vulnerable. If you’re a developer, check your code to see how you are use these two functions:


Make sure you are escaping them before use. We recommend using the esc_url() (or esc_url_raw())functions with them. You should not assume that add_query_arg and remove_query_arg will escape user input. The WordPress team is providing more guidelines on how to use them here.

Update Time!

If you use any of these plugins, make sure to update them now! We will continue to investigate and look for more plugins vulnerable and keep our list here current.

This is also a good time to remind everyone that all software will have bugs and some of those bugs will inevitably lead to security vulnerabilities, such is the life we live in. This applies to plugins, themes, webservers, CMS’s and basically anything that is written by people and based on code. As much as developers try to minimize them and deploy secure coding principles, mistakes will inevitably still happen. We just have to be prepared and find ways to minimize the affect of any vulnerability in your environment; a perfect example of such an approach is what you’re seeing today with this coordinate release.

Here are some tips and tricks to remember to help reduce your overall threat risk, helping to improve your individual security posture:

  1. Patch. Keep your sites updated.
  2. Restrict. Restrictive access control. Restrict your wp-admin directory to only white listed IP Addresses. Only give admin access to users that really need it. Do not log in as admin unless you are really doing admin work. These are some examples of restrictive access control policies that can minimize the impact of vulnerabilities in your site.
  3. Monitor. Monitor your logs. They may give you clues to what is happening on your site.
  4. Reduce your scope. Only use the plugins (or themes) that your site really needs to function.
  5. Detect. Prevention may fail, so we recommend scan your site for indicators of compromise or outdated software. Our plugin and Sitecheck can do that for free for you.
  6. Defense in Depth. If you have an Intrusion Prevention System (IPS) or Web Application Firewall (WAF), they can help block most common forms of XSS exploits. You can even try our own CloudProxy to help you with that. If you like the open source route, you can try OSSEC, Snort and ModSecurity to help you achieve that.

These principles are commonly applied to most secure networks (or on any business that needs to be PCI compliant), but not many website owners think of them for their own site / environment.

These are but a few high level recommendations; we recommend going through our blog for more ideas on how to keep your sites safe and ahead of the threats.

FBI Public Service Annoucement: Defacements Exploiting WordPress Vulnerabilities


The US Federal Bureau of Investigation (FBI) just released a public service announcement (PSA) to the public about a large number of websites being exploited and compromised through WordPress plugin vulnerabilities:

Continuous Web site defacements are being perpetrated by individuals sympathetic to the Islamic State in the Levant (ISIL) a.k.a. Islamic State of Iraq and al-Shams (ISIS). The defacements have affected Web site operations and the communication platforms of news organizations, commercial entities, religious institutions, federal/state/local governments, foreign governments, and a variety of other domestic and international Web sites. Although the defacements demonstrate low-level hacking sophistication, they are disruptive and often costly in terms of lost business revenue and expenditures on technical services to repair infected computer systems.

Read More

Website Malware – The SWF iFrame Injector Evolves

Last year, we released a post about a malware injector found in an Adobe Flash (.SWF) file. In that post, we showed how a .SWF file is used to inject an invisible, malicious iFrame.

It appears that the author of that Flash malware continued with this method of infection. Now we are seeing more varieties infecting both WordPress and Joomla websites. Though it’s uncertain how many iterations existed in the wild when we first reported the issue, this time we’ve found a lot of websites where the infection looks similar:
Identifying the Flash Infection

The similarities are easy to spot once you know what they are. The malicious .SWF file is always stored in /images/banners/ and the file name is three random characters followed by .SWF with an ID parameter appended:


So, how does the infection look this time around? Here is the Flash file decompiled:

Malicious SWF Infection

Malicious code has similarities to the infection reported in November

The Same Hacker at Work

Apparently, the malware author is the same. Variable names, coding logic, and UserAgent condition are all indicators of this. However, the source website delivering the malicious payload is different. Also, while there were mostly Joomla based websites affected previously, we’re also seeing WordPress sites with this infection.

Ben Martin, a member of our Remediation Team, found infected Flash objects matching our description that were injected inside a WordPress database:

SWF infected the WP database

Similar infected .SWF found in the WordPress database

The Impact Five Months Makes

This time, many more sites are being affected — several hundred, maybe more.

Another difference is that at the time of my original post on this infection, no AntiVirus company detected this threat. This time, about half of vendors are detecting the issue:

VirusTotal Results show 23/57 vendors detect the malware

VirusTotal: 23/57 vendors detect malicious content

Malware evolves every day, and I’m sure we’ll see more variations of this particular strain in the future. You can be sure that we will share our findings with you every time. In the interim, if you find yourself troubled with something similar be sure to look for professional help and get back to business.

Stay safe and keep your eyes open!

Understanding WordPress Plugin Vulnerabilities

The last 7 days have been very busy with a number of vulnerabilities being disclosed on multiple WordPress plugins. Some of them are minor issues, some are more relevant, while others are what we’d categorize as noise. How are you supposed to make sense of all this?

To help provide some clarity on the influx of data, we want to provide some insights to help you, the website owner, navigate and understand these vulnerabilities. We will provide a summary and an explanation of the ones that matter and the ones that do not.

The Impact of Roles (Authentication) in Vulnerabiltiies

Contrary to popular belief, just because you hear “SQL Injection”, it doesn’t mean someone can actually hack your site. The real problem comes in remote and unauthenticated attacks. These can lead to mass compromises; compromised can be mean leveraged to distribute malware, spam and can lead to brand reputation issues like getting blacklisted by Google.

When an attack requires an authenticated user, the severity drops. However, it is not that uncommon for sites to allow subscribers to register. So, any vulnerability that requires a subscriber user can also lead to serious issues.

Once a vulnerability requires a higher role, think authors or editors, the severity and our overall score drops though. The reason this is true is because users with higher roles often have higher permissions and abilities to do things that can sometimes be seen malicious, but are in fact by design. A perfect example of this can be seen in WordPress core.

In core, an administrator is able to inject unfiltered html in posts and pages, and can also execute any command they want via plugins they install. Is this a vulnerability? No, it’s a feature and it’s based on one very important element – Trust. The user that is given that role is given permission to do whatever features have been made available, so if that’s to inject unfiltered html, then the user is expected to do so responsibly.

In security, this is why we place so much emphasis on concepts like Least Privileged – the principle of giving someone the permission they require to do their job, no more, and no less. If they require higher permissions, then give them what they need, for as long as they need it, then reset the role to its original configuration. This however is a topic for another day, but worth understanding as it sets context moving forward.

Scoring Vulnerabilities on WordPress Plugins

We like to use the DREAD score when assessing a vulnerability in WordPress Plugins. A question we often get is, why did you not report on this recent release? Or, why did you report on this release? DREAD allows us to take a more objective approach to released, in hopes that we’ll be able to cut down on the noise and market confusion.

DREAD was developed by Microsoft many years ago and is not that widely used anymore. For us however, we find it to be very useful for web applications, especially when it comes to Content Management System (CMS) disclosures.

DREAD breaks a vulnerability down into 5 categories:

Damage – How bad would an attack be?
Reproducibility – How easy is it to reproduce the attack?
Exploitability – How much work does it take to launch the attack?
Affected users – How many people will be impacted?
Discoverability – How easy is it to discover the threat?

Each category gets a score from 0 to 10 and at the end, you sum them all and divide by 5 to get the final value.

How we classify each category is what counts the most in the work we do:

  1. Damage – 0:same as what the role has, 3:Information Leaks, 5:XSS, 8:Authenticated RCE or SQL Injections, 10:Unauthenticated Remote command execution or SQL injections.
  2. Reproducibility – 0:requires admin, 2:requires editor, 3:requires author, 6:requires subscriber, 10: unauthenticated
  3. Exploitability – 0:fully manual and takes very long, 3:hard to automate, requires author+, 5:hard to automate, requires login, 8:easy to automate, multiple steps 10:one click on a browser
  4. Affected users – 0:less than 1k installs, 5:100k+ installs, 10:1m+ installs
  5. Discoverability – 0:you have to attempt an exploit to see if it works or not, 3:you have to guess and it requires a log in,6:you have to guess but can attack remotely, 10:plugin announces that it is installed.

With these ranges in mind, let’s see how each vulnerability stacks up.

Gravity Forms: SQL Injection / Severity: Low

The gravity forms team just released an update fixing a SQL Injection (SQLi) on the “sort” argument on their edit page. Only an authenticated admin or editor can actually reach that part of the code, so we consider it a low severity vulnerability. Editors and admins can do so much already, that only trusted people should have this role. If the admin user is performing a SQLi attack, they are likely conducting a number of other attacks and SQLi is probably the least of your concerns.

It can be used on targeted attacks, due to the lack of nounces, but we will not see any major issues coming out of it.

Looking at DREAD:

D: 8
R: 2
E: 3
A: 7 (since it is a paid plugin, we don't know exactly the number of installs)
D: 3

The final score is 4 – Low (8 + 2 + 3 + 7 + 3 / 5)

Pods Plugin: SQL Injection / Severity: Low

The Pods vulnerability is actually very similar to the GravityForms and the WordPress SEO ones. Looking at the DREAD score:

D: 8
R: 2
E: 3
A: 2
D: 5

Final score is 3 – Very Low (8 + 2 + 3 + 2 + 3 / 5)

MainWP-Child: Password Bypass / Severity: High

The MainWP vulnerability was found by our team and we gave it a high severity. The reason we did so is that it was very easy to exploit (unauthenticated) and allows anyone to get admin access to the vulnerable site.

D: 10
R: 10
E: 9
A: 5
D: 6

Final score is: 8 (high) (10 + 10 + 9 + 5 + 6 / 5)

WooCommerce: SQL Injection / Severity: Very Low

The WooCommerce vulnerability is interesting, since it requires an admin or shop manager in order to exploit it. We would not treat is a vulnerability, but as a bug, since it does not allow more damage than what the role (admin) actually can cause.

D: 0 (same damage as the role itself can cause)
R: 0 (requires admin)
E: 1
A: 10 (1m+ installs)
D: 3

Final score is: 2 (very low) (0 + 0 + 1 + 10 + 3 / 5)

WordPress SEO: SQL injection / Severity: Low

The WordPress SEO vulnerability got a lot of media coverage due to its popularity. Was it valid? Let’s look at the scores again:

D: 8
R: 3
E: 3
A: 10
D: 3

Final score is: 5 (Low) (8 + 3 + 3 + 10 + 3 / 5)

Judging Vulnerabilities

Judging vulnerabilities and its impacts is always very hard. A low severity score on DREAD, doesn’t mean it can’t be used on a targeted attack against your site. It doesn’t mean you do not have to patch it and keep your site updated.

That’s why we always make sure our Website Firewall (WAF) is protecting against all of them. For every new vulnerability disclosed, our research team invests the time to test, verify and validate their impacts and ensures that our protection mechanisms are effectively patching and protecting or users.

When looking at the internet as a whole, low severity vulnerabilities will have a small impact overall and requires less marketing to get to the ear of the users. It’s also difficult to decipher the amount of noise being disclosed, we hope this helps provide some guidance into how to make sense of all the information you might be reading.

– Your Trusted Security Team


Zero-day in the Fancybox-for-WordPress Plugin

Update: We posted an analysis of the vulnerability following this post.

Our research team was alerted to a possible malware outbreak affecting many WordPress websites. All the infections had a similar malicious iframe from “203koko” injected into the website. We were also directed to a forum thread where users were sharing their concerns and describing similar issues they were experiencing.

In analyzing the infected websites, we found that all the websites were using the fancybox-for-wordpress plugin.

Zero day in fancybox-for-wordpress

The fancybox-for-wordpress plugin is a popular WordPress plugin with more than 550,000 downloads. There doesn’t appear to be any public vulnerabilities being reported, which piqued our interest. To understand how it was connected, we decided to do our own code / vulnerability review.

After some analysis, we can confirm that this plugin has a serious vulnerability that allows for malware (or any random script/content) to be added to the vulnerable site. Because it is currently unpatched, we will not disclose more information.

What makes things worse, is that it’s being actively exploited in the wild, leading to many compromised websites.

We could confirm via our Website Firewall logs by seeing many exploit attempts blocked.

This is what the attacks looks like: – – [04/Feb/2015:00:25:09 -0500] “POST /wp-admin/admin-post.php?page=fancybox-for-wordpress HTTP/1.1″ 403 4207
INPUTBODY:action=update&mfbfw%5Bext.. malware payload hidden

Remove this plugin Immediately!

The plugin was just removed by the team from their repository and you need to remove it from your site as well! If you require it for specific features you really need to look at deploying alternative security solutions to help protect your website and block exploit attempts.

Users of our Website Firewall are already protected, but if you do not employ a similar service and leverage this plugin consider yourself highly vulnerable and high risk of compromise.

We will post more details about this vulnerability once we have given time for everyone to patch (when it becomes available).

Special thanks to Konstantin Kovshenin and Gennady Kovshenin for notifying and working with us on this issue.

Advisory – Dangerous “nonce” leak in UpdraftPlus

Advisory for: UpdraftPlus
Security Risk: High
Exploitation level: Remote
DREAD Score: 7/10
Vulnerability: Privilege Escalation
Patched Version: 1.9.51

If you’re a user of the UpdraftPlus plugin for WordPress, now is the time to update. During a routine audit of our Website Firewall (WAF), we detected a “nonce” leak vulnerability affecting the UpdraftPlus WordPress plugin. The vulnerability allows a malicious actor to perform various operations that he normally wouldn’t be allowed to, such as uploading files on the target server, downloading the site’s backups and retrieving WordPress Secret Keys.

What are the risks?

If you’re hosting a WordPress site that uses the free version of UpdraftPlus and allows users to create accounts (ie. subscribers), you’re at risk. A logged-in attacker could use this bug to leak a specific token (which WordPress calls a “nonce”) that can be reused to trigger other mechanisms within the plugin, for example uploading arbitrary files on the server (if they pass WordPress extension filters) and downloading the site’s file and database backups, which could result in a site compromise.

Technical details

The plugin’s admin_action_upgrade_pluginortheme() method was hooked to WordPress ‘admin_action_’ action, which can potentially be executed when a logged-in user visits a page in /wp-admin/ that includes the /wp-admin/admin.php file and has the ‘action‘ GET parameter set to a specific value.


As you can see from the above snippet, the target method is hooked to both ‘admin_action_upgrade-plugin‘ and ‘admin_action_upgrade-theme‘ hooks. These can be directly called by adding “?action=upgrade-plugin” or “?action=upgrade-theme” to the user dashboard’s URL.


Doing this would result in the plugin leaking the ‘updraftplus-credentialtest-nonce’ nonce, which was also used at several other places in the code, namely in the plugin’s AJAX handler:


From there, an attacker could do a lot of things like displaying a phpinfo() page including all of the website’s defined constants (which includes WordPress Secret Keys, database credentials and prefix), executing every hook present in the current context and downloading the site’s backup files.

Brief comment on UpdraftPlus’s way of handling the issue

We’d like to take a few lines to mention that the plugin’s developer was exceptionally effective at understanding what the issue was, patching it and notifying his users of the issue. This is a great example of what people means when they say no software can be 100% secure. UpdraftPlus was (and still is) a very secure piece of software, overall. We can say for sure that this bug was a result of a misunderstanding of how ‘admin_action_ hooks could be used, definitely not from a lack of WordPress security best-practices.

If you are a developer, you can read his blog post for an example on how to deal with vulnerability disclosures (only 12 hrs after we notified them).

Update as soon as possible

Again, even if you’re not necessarily affected by this particular vulnerability, we suggests you to upgrade to the latest version. If for any reasons you cannot do this, we highly recommend you to have a look at our Website Firewall (WAF) to get rid of the risk this vulnerability (and many others) represents to your site.

RevSlider Vulnerability Leads To Massive WordPress SoakSoak Compromise

Yesterday we disclosed a large malware campaign targeting and compromising over 100,000 WordPress sites, and growing by the hour. It was named SoakSoak due to the first domain used in the malware redirection path (

After a bit more time investigating this issue, we were able to confirm that the attack vector is the RevSlider plugin. We disclosed a serious vulnerability with this plugin a few months ago, it seems that many webmasters have either not heard of or did not take seriously the vulnerability.

The biggest issue is that the RevSlider plugin is a premium plugin, it’s not something everyone can easily upgrade and that in itself becomes a disaster for website owner. Some website owners don’t even know they have it as it’s been packaged and bundled into their themes. We’re currently remediating thousands of sites and when engaging with our clients many had no idea the plugin was even within their environment.

The Attack Sequence

We have investigated thousands of compromised sites with this injection and based on the logs, we are able to confirm the exact attack vector being targeted.

  1. Discovery: There appears to be an initial reconnaissance scan occurring where the attacker[s] are looking to see if the file exists. Snippet of the code
  2. – – [14/Dec/2014:09:59:35 -0500] “GET /wp-content/plugins/revslider/rs-plugin/font/revicons.eot HTTP/1.1″ 200 – – [14/Dec/2014:00:12:07 -0500] “GET /wp-admin/admin-ajax.php?action=revslider_show_image&img=../wp-config.php HTTP/1.0″ 202

    The first entry looks for the revicons.eot files and the second one attempts to use one of the Revslider vulnerabilities to download the wp-config.php file.

  3. Exploit:If the discovery phase is successful and they find a site using Revslider, they use a second vulnerability in Revslider and attempt to upload a malicious theme to the site: – – [14/Dec/2014:04:31:28 -0500] “POST /wp-admin/admin-ajax.php HTTP/1.1″ 200 4183 “-”
    Content-Disposition: form-data; revslider_ajax_action
    update_plugin; name=”update_file”;…

  4. Take over: If the exploit is successful, they inject the popular Filesman backdoor into the website, which they access directly at /wp-content/plugins/revslider/temp/update_extract/revslider/update.php this provides full access by circumventing existing access controls: – – [14/Dec/2014:04:31:28 -0500] “GET /wp-content/plugins/revslider/temp/update_extract/revslider/update.php HTTP/1.1″ 200 5287
    “-” “Mozilla/5.0 (Windows NT 5.1; rv:33.0) Gecko/20100101 Firefox/33.0″

From there, they inject a secondary backdoor that modifies the swfobject.js file and injects the malware redirecting site visitors to

This campaign is also making use of a number of new backdoor payloads, some are being injected into images to further assist evasion and others are being used to inject new administrator users into the WordPress installs, giving them even more control long term. Some users are clearing infections and getting reinfected within minutes and the reason is because of the complex nature of the payloads and improper cleaning efforts.

Do not just clean these 2 files!

We are hearing a lot of recommendations online to just replace the swfobject.js and template-loader.php files to remove the infection.

It does remove the infection, but does not address the left over backdoors and initial entry points. The website will be reinfected quickly. If you are affected by this, expect to find yourself riddled with backdoors and infections, you have to not only clean, but also stop all malicious attacks. You can stop malicious attacks through the use of a Website Firewall, ours or someone else, just use a Firewall, a real one preferably.

We have posted a full payload analysis as well as our original release on SoakSoak:

Protecting Against Unknown Software Vulnerabilities

Bugs exist in every piece of code. It is suggested that for every 1,000 lines of code, there are on average 1 to 5 bugs to be found.

Some of these bugs can have security implications. These are known as vulnerabilities, and they can be used to exploit and compromise your server, your site and your users.

As long as there are people involved in the process of writing code and setting up systems, mistakes will happen as it is part of human nature. As such, security problems will always be something we have to deal with.

Impact of Vulnerabilities on Websites

Why does it matter that much? Last week, both WordPress and Drupal released new versions of their Content Management System (CMS) to patch important security vulnerabilities. Other popular WordPress plugins also released updates to fix their vulnerabilities.

Once a vulnerability is found and a patch is available, the solution is simple: Apply the patch (by doing an update) and you are now protected. It is the endless cycle that is known as software development. A bug will be found, a patch will be available, the patch is applied, another bug is found, a new patch is available, the patch is applied. Every time a new feature is introduced, new bugs are also introduced with it.

It seems like a simple process for a webmaster that as long as he is updated, he is safe.


How do you protect against unknown software vulnerabilities?

What if you do not know about a specific vulnerability, how do you patch and protect your website?

What if an update goes out over a long weekend? A 0-day gets disclosed before an update is available? Or what if a vulnerability is discovered by the bad guys and they start using it without telling anyone?

  • The latest SQL injection vulnerability in the Drupal platform was being exploited within 7 hours of it’s disclosure.
  • Websites were being compromised via TimThumb before the public knew about it and a patch was available
  • We have hits in our logs from days before the latest XSS vulnerability in WordPress was disclosed.

So the question is, how do you increase your security so that you can minimize the risk and the chances of being compromised when (not if) someone tries to attack your site misusing an unpatched / unknown vulnerability?

You have options:

  1. Restrict who can access parts of your site to minimize the attack footprint.
  2. Employ prevention solutions that try to block exploit behaviors (generally called WAF’s or IPS’s).
  3. Harden parts of your stack to minimize the effect of an exploit.
  4. Constant network and log monitoring to identify Indicators of Compromise (IoC).

These are just some examples. They may sound hard or too advanced, but they are actually doable and every website owner should look into it.

Think about your desktop / notebook computer for a second. Why does every (or almost every) desktop have a personal firewall, an anti-virus, a spam filter and other similar tools? Yes, even Macs have them as well.

Why do most networks (including home networks) run behind a router with basic / advanced firewalls working to filter and prevent attacks from the Intranet?

The reason is simple: minimize the footprint and options for an attacker.

Now think about your website[s]. Let’s look at a few examples into how that can be applied to your Website security:

WordPress 4.0 Long Password DOS

Both Drupal and WordPress had a vulnerability disclosed last week that allowed an attacker to DoS (Denial of Service) a site by sending many, very long passwords in the login requests.

Prevention: Access Restriction / Reduced Footprint.
Block wp-login and wp-admin access only to authorized IP addresses. If an attacker can’t reach your login page, he won’t be able to exploit this vulnerability.

Simple solution that anyone can do by adding an .htaccess to your wp-admin allowing just a few IPs. We find this feature important enough that we employ it to our stack by default and set it as default for all users of our Website Firewall product.

Paid Memberships Pro Path Traversal

Paid Memberships Pro is a popular WordPress plugin that had a path transversal (arbitrary file download) vulnerability disclosed last week. The exploit is possible by accessing: wp-admin/admin-ajax.php and passing a file to be downloaded via getfile:


Prevention: Access restriction / reduced footprint.
The same as before, restrict access to only whitelisted IPs.

Prevention 2: WAF/IPS.
Even if the previous restriction was bypassed, an Intrusion Prevention System (IPS) or Web Application Firewall (WAF) would prevent it from being exploited through generic Local File Inclusion / Remote File Inclusion (LFI/RFI) rules.

WordPress 3.9.x stored XSS

WordPress versions 3.9.2 and earlier are affected by a critical cross-site scripting vulnerability, which could enable anonymous users to compromise a site. This was reported and patched last week as well.

This vulnerability abuses the core commenting system, an attacker is able to craft a simple comment to send a malicious payload that when viewed by the administrator, allows the attacker to take over the site. This explains it’s severity.

Prevention: Reduced footprint.
First, if your site does not need or use comments, why leave it open? You can block any access to wp-comments-post via .htaccess and be covered right away. If you do need comments, you can use external commenting systems that keep untrusted (user data) away from your trusted data (posts, pages, etc).

Prevention 2: Prevention technology.
Even if you do allow comments, employing a WAF or IPS would probably have blocked this XSS via generic XSS signatures that most good prevention products have.

WP-Statistics XSS

Our research team found a stored XSS in the very popular wp-statistics plugin.

Prevention: WAF/IPS.
This is where having a good WAF / IPS solution in place becomes a must. A WAF have (or should have) a XSS detection that will block this attack generically, without even knowing about this specific vulnerability. On our own WAF, we were blocking it automatically before even knowing about this bug, in a way that we did not even need to write a virtual patching for it.

Staying ahead of Unknowns

Last weeks releases are growing in number each month, as they do the importance of being able to tackle the problem of unknowns grows. Following some of the steps above would improve your over Security posture allowing you to better recognize and respond to these issues, reducing your overall risk footprint.

We offer a product that can do this all, but many of the recommendations you can employ on your own by leveraging open technologies and .htaccess changes:

  • Restrict access to wp-admin/wp-login (and any other access point) only to authorized IPs.
  • Limit footprint. Do you need comments? Do you use XMLRPC? Blocking everything and only allowing what you really need.
  • Leverage a WAF / IPS and you can do this with products like Modsecurity and OSSEC.

We’ve obviously built a technology that automates all these things for you, allowing you to get back to running your business, but you can see there are various options available to you. If you’re interested in a free trial, ping us at