OWASP Website Running Outdated and Insecure Version of MediaWiki

The Open Web Application Security Project (OWASP) promotes itself as being “focused on improving the security of software”, but unfortunately they don’t even bother to keep the software running their website up to date. If you visit their website with our Meta Generator Version Check extension installed in your web browser (available for Chrome and Firefox) you will see that they are running an outdated version of MediaWiki:

OWASP Website is Running MediaWiki 1.18.0

OWASP has failed to update their MediaWiki installation for over a year, the next version, 1.18.1, was released in January of 2012. They failed to apply any of the five security updates that were released for version 1.18.x. Support for version 1.18.x of MediaWiki ended back in November, so they also should have moved to a supported version some time ago.

Keeping software up to date is one the basic steps and easier steps to keep software running a website secure. The fact that a project dedicated to security is failing to do that highlights how bad the state of security is and raises the questions if the security community is in fact actually interested in security.

White House Website Running Outdated and Insecure Version of Drupal

While “President Obama has declared that the “cyber threat is one of the most serious economic and national security challenges we face as a nation” and that “America’s economic prosperity in the 21st century will depend on cybersecurity.”“, the White House is failing to take a basic security measure with their website. If you visit the website with our Drupal Version Check extension installed in your web browser (available for Chrome and Firefox) you will see that they are running an outdated version of Drupal:

White House Website is Running Outdated Drupal Version

Further checking shows that the website is running Drupal 6.26 or 6.27, so the White House failed to apply one or two security updates. Keeping software up to date is one the basic steps and easier steps when it comes to cybersecurity and the White House is failing at that.

Updating between versions of Drupal 7 is relatively easy, so there isn’t any excuse for an organization with its resources to not be able to keep it up to date.


DHS Website Running Outdated and Insecure Version of Drupal

Ahead of a vote on the CISPA legislation the head of the Department of Homeland Security (DHS) will be briefing members of the House of Representatives today on cybersecurity. Maybe the briefing should be on how not to do cybersecurity as the DHS is failing to take a basic security measure with their website. If you visit their website with our Drupal Version Check extension installed in your web browser (available for Chrome and Firefox) you will see that they are running an outdated version of Drupal:

Department of Homeland Security Website is Running Outdated Drupal Version

Keeping software up to date is one the basic steps and easier steps when it comes to cybersecurity and the DHS is failing at that. The larger question that this raises is what else they might be failing to do when it comes to cybersecurity, since they fail to do something so basic.

Further checking shows that the website is running Drupal 7.14, so the DHS has failed to update the software for over 8 months, the next version was released back in August of 2012, and they have missed the last 4 security updates.

Kaspersky Lab’s US Website Running Outdated and Insecure Version of Drupal

When it comes to internet security one of the most basic steps is keeping your software up to date. In sign of how poor the state of internet security is, even security companies are not taking such a basic step. The US website of Kaspersky Lab, which the New York Times has described as “Europe’s largest antivirus company“, is running a very out of date version of Drupal:

Kaspersky Lab US Website is Running Drupal 6.19

Kaspersky Lab has failed to update the software for over two years, the next version Drupal 6.20 was released back in December of 2010, and they have missed the last 4 security updates. Updating between versions of Drupal 6 is relatively easy, so there isn’t any excuse for a tech company not being able to keep it up to date.

Kaspersky Lab is not alone in this, last year we posted about Panda Security’s failure to update software running their websites even after some of their websites had been hacked.

You can check if Drupal websites you visit are keeping the software up to date with our Drupal Version check extension for Chrome and Firefox.

SC Magazine Australia Blames WordPress Plugins for Unrelated Hack

SC Magazine Australia’s recent article “50,000 sites compromised in sustained attack” incorrectly claims that WordPress was associated with a past malware campaign and tries to link general security issues to WordPress. As we continue to see the harmful impact of the bad security information, particularly when it involves WordPress, we want to clear up some of the claims in the article and fill in the critical missing information on actually protecting against security vulnerabilities in WordPress plugins.

The most blatant error in the article comes near the end of the article where it is stated that “Vulnerabilities in WordPress plugins have been long understood. Last year, large malware campaigns including the LizaMoon attacks exploited those holes” The LizaMoon attack was part of a frequently hyped multiyear campaign that targets ASP and ColdFusion based websites that have fairly basic SQL injection vulnerabilities. It had nothing to do with WordPress or any WordPress plugins. The link they provide about the LizaMoon attack makes no mention of WordPress and we are not aware of any source that ever claimed that it had a connection with WordPress. The rest of the article isn’t much better. Earlier it says:

Attackers targeted holes in a string of plug-ins for blogging software — such as WordPress— including timthumb, uploadify and phpmyadmin.

None of those things are themselves plugins for WordPress or other blogging software, nor is blogging software the only thing targeted by hackers. We probably deal with as many websites that are hacked due to outdated Joomla extensions as WordPress plugins, so there doesn’t appear to be a good reason to spotlight WordPress for special attention as the article did.

phpMyAdmin is web based administration tool for MySQL database. Several years ago there was WordPress plugin that added phpMyAdmin to WordPress which contained an exploitable vulnerability, but at this point it isn’t a major target of hackers as the plugin was removed back then. phpMyAdmin itself is frequently probed for on our website, so that is likely why phpMyAdmin would be listed as being targeted. That doesn’t explain why it be listed as a being a plugin for WordPress or other blogging software, though.

The TimThumb and Uploadify libraries are included in some WordPress plugins and those have been targeted (though since we last discussed recent serious security vulnerabilities in WordPress plugins we have seen attackers expand from targeting just the recent Uploadify based vulnerabilities to the other upload vulnerabilities recently identified).

Later in the article it claims then claims that Plesk is being targeted (web hosts are not always good about keeping that up to date), so it appears somebody involved in the article just threw together an incomplete list of software that gets targeted without any specific relation to the malware mentioned, while singling out WordPress.

Another worrisome aspect of the article is that it cites a “malware researcher” from Sucuri, the company that has a malware scanner that doesn’t actually bother to scan a website for malware before falsely flagging it.

Protecting Against WordPress Plugin Vulnerabilities

What the article lacks, as stories about hacks often do, is any information on protecting websites from the vulnerabilities they are warning about. For WordPress plugin vulnerabilities, you would hope the answer is to update your plugins, as by the time a vulnerability is being exploited it should have already been patched. Unfortunately, in an analysis of WordPress plugin vulnerabilities in the second quarter of 2012, that we just did, we found that a fourth of the plugins had not been fixed (we will have a post with the full details of the analysis in the next few days). What makes this even worse is that most of the vulnerabilities in those plugins were serious vulnerabilities that are the most likely to lead to website being hacked. So what happens when plugins are not fixed?

When the maintainers of the WordPress.org Plugin Directory are made of aware of a security vulnerability in a plugin they will remove the plugin from the directory until it is fixed. Unfortunately, when we started looking into this earlier this year we found that many plugins had never been reported and had remained in the directory including one in which hackers were attempting to exploit at the time. Since then we have been making sure that any plugins with reports of unresolved security vulnerabilities are reported and appropriate action is taken (we have also been warning them about security issues that impact plugins, including notifying them about the recent Zend Framework vulnerability that impacted several plugins). While removing the plugins until they are fixed prevents any additional websites from being exposed to the vulnerabilities, websites already using the plugins don’t receive any warning and remain vulnerable as we have discussed before. The process of adding alert in WordPress when plugins that have been removed from the Plugin Directory are installed has begun and you can help to make sure it is given a high priority by voting for implementing that change. Until an alert is added in WordPress itself, you can get a more limited version of this functionality using our No Longer in Directory plugin (we released update for the plugin, with new vulnerabilities, at the beginning of the week).

Panda Security Still Fails to Take Basic Security Measure Months After Being Hacked

Nearly four months ago a Panda Security web server was hacked into and about two dozen of their websites were defaced, including the PandaLabs Blog. It is probably reasonable to be concerned that a major computer security company isn’t able to keep their websites from being hacked, but once they have been hacked the more important issue is how they respond going forward. Do they promptly take actions to insure they are now following best security practices or do they do the least possible to resolve the issue?

When it comes to website security, the number one thing you are probably are going to hear is that you need to keep your software up to date. By doing this you prevent a known vulnerability in the software from being exploited (assuming the software’s developers promptly fix security issues). When it comes to keeping web software up to date WordPress is one of the best, if not the best, at making the update process easy, so we would expect that any WordPress installs Panda Security is running would be up to date now if they had taken the hacking seriously. Let’s take a look if they have done that:

The PandaLabs Blog:

PandaLabs WordPress Version

The blog for their support forum:

La Piazza WordPress Version

The Panda Research Blog (which admittedly hasn’t been active for nearly a year):

Panda Research WordPress Version

All three WordPress installs we found were using a year and half old version of WordPress. There have been eight releases with security improvements since WordPress 3.0.4 was released.

Websense Continues To Falsely Implicate WordPress in Malware Infections

Several times in the past we have looked at instances where Websense has inappropriately implicated that WordPress was connected to malware infections. In the most recent instance they falsely claimed that a malware infection was only infecting a certain version of WordPress and that there were known vulnerabilities in that version of WordPress. Just a month later they came out with another post that falsely implicated WordPress with another infection. We missed this at the time they put it out because we don’t follow their reporting as it has proven to be so bad. The post was recently brought to our attention and it is worth discussing it now, as what they continue to do is inappropriate and damaging.

This time it began with a posting titled “New Mass Injection Wave of WordPress Websites on the Prowl“, which is a pretty clear implication that the WordPress software had some involvement in the infection. But if you actually read the body of the post you find that they only mention of WordPress is in saying that a “majority of targets are Web sites hosted by the WordPress”. They don’t make any claim of an actual connection between the infection and WordPress. This isn’t a small distinction, as many websites are running WordPress and therefore it would not be unexpected that a more general issue would impact many WordPress based website. (As we will come back to in a little bit, there is also the issue of how accurately Websense measures what software websites are running.) If the issue isn’t related to WordPress than WordPress shouldn’t be emphasized, if mentioned at all, as many people will unnecessarily worry about the security of WordPress. It is quite clear there posting had that effect by looking at the comments on the post and the title of their follow up post “I have the latest WordPress version – is my Website protected?“.

Because Websense provided such little actual information about the malware infection, probably because they didn’t actually have any, it is hard to determine for sure what infection they are referring to and therefore the source. The infection looks to be related to a hack of many Dreamhost based websites, due to Dreamhost’s poor security. That occurred during the same time period, the malware code looks very similar to what we saw with those websites, and the comments on the first post reference that as well. If Websense’s security researchers were actually interested in doing security research, they would have actually investigated what the underlying source of the infections was instead of creating a post that baselessly implicated WordPress as somehow being related to the infections.

We don’t think Websense is intentionally trying to damage WordPress; the reason for doing this appears to get them press coverage. Unfortunately, just as they did with Websense’s last false report, some of press spread this and its non-existent WordPress connection. PCWorld’s article is titled “30,000 WordPress Blogs Infected to Distribute Rogue Antivirus Software” (Websense’s post actually only claimed that a majority of a total “close to 30,000 unique Web sites” were running WordPress) and the WordPress logo is at the top of the article. Dark Readings’ article actually introduces more harmful information to the mix. The article says that a Websense researcher says that “WordPress is so widely used around the world, every version of it is studied and exploited by hackers”, which is highly alarming but not even close to the truth. While there have been a number of security vulnerabilities found and fixed in WordPress in recent years, there haven’t been any that have lead to a major hack of WordPress based websites. That doesn’t mean that there haven’t been targeted attacks using them, though we haven’t seen any reports of that, or that a serious vulnerability couldn’t be found (so make sure you are keeping WordPress updated), but it does mean that running WordPress, as opposed to less popular software, doesn’t put you at some great threat of being hacked.

A Majority of Infected Websites Running WordPress?

The last time Websense brought up WordPress they originally claimed that all of the infected websites they found were not only running WordPress, but that they were all running a specific version of WordPress. When we did our own small analysis of 11 websites that had been listed as infected by Google, we found that 2 of them were currently infected and either not running WordPress or running an older version of WordPress. There were others that also were not running WordPress, but were not infected at the time so we couldn’t independently confirm they had been infected. Based on that data and the fact that they later admitted that the infection was unrelated to WordPress, there data in that instance was at least unrepresentative, if not faulty in some way. The information provided this time doesn’t provide any confidence that they have improved things since then.

In their first post it says that the “majority of targets are Web sites hosted by the WordPress”. A week later in their second post it says that “when we discovered the attack, we found only WordPress sites, and after a week or so, the picture did not change that much” and that “WordPress still serves the majority of the compromised websites; however, we did see a small amount of other CMS as well”.  It’s not clear why the second post says that WordPress went from the only thing found to just the majority over a week, when the first post from a week earlier said it was only a majority at that time. There definition of a small amount seems off as well. They say that they found 14 percent were running something other than WordPress, with 10 percent being Joomla and 4 percent being “other”. That is a number far beyond what you would expect if this was truly something related to something in WordPress and had then spread to other parts of websites, which were running WordPress and other some software on different portions of their websites.

Another piece of their analysis seems even odder. They have a rather odd chart:

Websense Chart of PHP Use

The chart shows some use of PHP versus an undefined other. PHP is a scripting language, so this could be a measurement of what language the code powering the website was written in, that website is capable of running PHP code, or maybe something else. The text preceding the chart doesn’t do much to explain what it is measuring or how they measuring it:

We checked several aspects of each of these compromised websites and concluded that most of them are served by Apache webserver and PHP environment. As you can see in the pie chart below, PHP dominates the server side:

Both WordPress and Joomla are written in PHP, so even if all of the “other” were not PHP based you would expect that a measure of either websites written in PHP and websites capable of running PHP code to be 96 percent but on the chart PHP is only 94 percent. One possible explanation of this is that it could be due to some of the websites being served by CDN or some other caching infrastructure, so the underlying server powering the website isn’t measured. Another possibility is that it another example of the poor quality of their measurement infrastructure. Whatever the cause of the discrepancy, it is something that would expect to be explained if they were going to present that chart as part of their analysis.

The larger issue is why they brought up PHP in the first place. Based on the fact that so much web software is written in PHP you would expect that many hacked websites would be using PHP, without the hack having anything to do with that. While there was a recent vulnerability in PHP, found two months after Websense postings, that could lead to websites being hacked some very limited circumstances, PHP isn’t something that is generally going to be the source of the hack. In this case, their data says that six percent of the websites are not using PHP, which would be a pretty good indication that it wasn’t related to PHP. The most likely explanation for highlighting PHP usage, and not many other things, is that they highlighted this finding simply based on PHP high usage among the infected website, without having a reason to believe it is connected to the actual source of the infection. You would hope that a researcher would understand that correlation is not causation, especially in an instance where you would expect there to be a correlation.

24 More WordPress Plugins With Publicly Known Vulnerabilities Were in Plugin Directory

Last week we mentioned that we had found that a WordPress plugin that had a security vulnerability in its current version, that had recently been attempted to be exploited, had remained in the WordPress.org Plugin Directory for six months after it was publicly disclosed. That plugin had received an advisory from Secunia and we have reviewed the rest of Secunia’s WordPress advisories to check for any other plugins in the directory that also had unresolved security vulnerabilities. We identified 24 more plugins that have vulnerabilities in their current versions and had remained in the Plugin Directory since the advisory was released. We have reported those plugins to WordPress and they have been removed from the Plugin Directory. If and when the vulnerabilities are fixed they should return to the directory.

You can check if your WordPress installation is running any plugins that have been removed from the Plugin Directory, whether for security issues or other issues, with our plugin No Longer in Directory. We have just updated it with the plugins that we reported to WordPress and have added links to Secunia Advisories for any of the plugins that have received them.

The oldest Secunia advisory for a plugin with an unresolved issue that had remained in the Plugin Directory was from January of 2008 and the most recent was from February of this year. The types of vulnerabilities in these plugins included cross-site scripting (XSS), cross-site request forgery (CSRF), SQL injections, and file inclusion. These plugins had over 560,000 combined downloads. The number of downloads that individual plugins had ranged from 300 to 93,000. Four of the plugins had over 50,000 downloads, which should be a reminder that just because a plugin is popular it doesn’t mean that it is more secure than less popular plugins.

We also found a situation where a plugin had been removed from the directory but a fork of the plugin has remained in the Plugin Directory despite also containing the vulnerability and two plugins that had their vulnerabilities fixed but the version number was not changed so that people that already had the plugin installed will remain vulnerable to being exploited. Resolution on those plugins’ issues from WordPress is still pending.

We plan to review other sources of claimed vulnerabilities to see if there are more plugins with publicly known vulnerabilities in their current versions that have remained in the Plugin Directory.

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.

WordPress Plugin With Publicly Known Vulnerability Remained in Plugin Directory For Six Months

While reviewing recent logs for attempts to exploit WordPress plugins, for another post on this blog, we spotted one plugin that seemed out of place. While nearly all of the exploit attempts involved plugins that were no longer in the WordPress.org Plugin Directory or had recently been updated with security fixes, the WP CSS plugin was in the directory but hadn’t been updated since 2009. We then got a copy of the plugin to see if the vulnerability that was being attempted to be exploited worked in the current version. A quick check showed that the exploit worked. According to Plugin Directory statistics as of Friday the plugin had been downloaded 17,803 times. That a plugin was available in the Plugin Directory that has vulnerability that is actively being exploited was troubling, but what we found next was more troubling.

Before contacting the developer of the plugin and WordPress, we decided to take a look if there was more information about the vulnerability available. We first found a post from someone who had also had recent attempts to exploit the vulnerability on their website. We then found a Secunia advisory for the vulnerability that was release on August 26, 2011. We also found that a company named SecPod had created a OpenVAS plugin for the vulnerability. It is also likely that exploit attempts were caught in various honey pots.

With the vulnerability being publicly known for at least six months and recent attempts to exploit it, the question that needs to be asked is how the vulnerable plugin continued to be available in the WordPress.org Plugin Directory all of that time. Did no one ever contacted WordPress about the vulnerability or were they contacted about it and decided not to remove the plugin, pending a fix? It seems highly unlikely that WordPress was contacted and left the plugin in the directory as they responded to our message, and removed the plugin, within in two hours of us contacting them. It is possible that some of the people who had spotted the vulnerability contacted the developer of plugin and had not contacted WordPress despite the plugin being hosted in the Plugin Directory and it being recommend that they be contacted about WordPress plugin security issues.

While it appears no one contacted WordPress, they still should have been monitoring for plugins included in the Plugin Directory that have a publicly released vulnerabilities. For Secunia, all WordPress related vulnerabilities can be found here.

For anyone running the WP CSS plugin they should remove the plugin or remove the w-css-compress.php file until it is fixed, unless they are comfortable making a modification to the file to prevent exploitation. Deactivating the plugin will not prevent the plugin from being exploited.

The other issue that this situation raises is the lack of information provided to those running plugins that have been removed from Plugin Directory for security issues, we have addressed that in another post on this blog and plugin that provides an interim solution for the problem.