A critical vulnerability in WordPress 3.9.2 and earlier has been addressed with the release of versions 3.9.3, 3.8.5, and 3.7.5. The vulnerability does not exist in WordPress 4.0. Anyone running WordPress 3.9.2 or earlier should apply the appropriate update as soon as possible.
Several less critical – but still important – security issues have also been addressed in WordPress 4.0.1. WordPress sites that are configured for auto-update should be automatically updated in the next day or so.
One of the more popular WordPress e-commerce plugins is WP eCommerce.
Recently, security researchers discovered a vulnerability that could allow attackers to obtain private data from WordPress sites that use the plugin.
The plugin’s developers released a new version that fixes the vulnerability. Anyone who manages a WordPress site that uses this plugin should install the new version (3.8.14.4) immediately.
Drupal is a Content Management System, similar to WordPress and Joomla. On October 15th, a very dangerous vulnerability in Drupal was announced. Within hours, exploits attacking this vulnerability started to appear on the web.
Yesterday, a special follow-up Public Service Announcement was posted on the Drupal web site. From the Drupal PSA:
Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 – Drupal core – SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement. Simply updating to Drupal 7.32 will not remove backdoors.
Anyone who runs a Drupal site should deal with this issue immediately.
A new version of WordPress was announced on September 4.
WordPress 4.0 has some new features, but nothing groundbreaking. Mostly this version is about tweaking existing features to make them more useful: for example, media embedding is now slightly easier. The official change log has the complete list of changes.
WordPress 4.0 doesn’t include any security fixes, so there’s no need to rush your site updates.
WordPress is still an extremely attractive target for malicious hackers. One of the ways they can gain access to WordPress sites is to examine third-party WordPress plugins, looking for security vulnerabilities. Plugins aren’t subject to any kind of approval or auditing process; anyone can develop and publish them.
Many of the most famous WordPress hacks were actually hacks of plugins, not the WordPress core software. The TimThumb graphics library is a good example.
A new version of the popular WordPress CMS was released yesterday. Version 3.9.2 includes a fix for a serious potential Denial-of-Service bug, and a few other changes that improve overall security.
Anyone who operates a WordPress site is strongly encouraged to update the software as soon as possible. Sites that are configured to allow auto-updates should be automatically updated in the next day or so.
WordPress site admins who manage sites using MailPoet should upgrade to version 2.6.7 as soon as possible to avoid problems. WordPress sites are an extremely tempting target for nefarious hackers and news of this vulnerability has undoubtedly spread rapidly among them.
Update 2014Jul24: According to Sucuri, once a web server has been compromised via this MailPoet vulnerability, all sites on the server are vulnerable, including sites not even running WordPress or MailPoet. Ars Technica has more.
TimThumb is a toolkit for cropping and resizing images that’s used in numerous WordPress themes and plugins. A serious flaw in TimThumb was widely exploited several years ago to hijack thousands of WordPress sites.
A new vulnerability in TimThumb was recently revealed. This new flaw allows attackers to execute malicious code on vulnerable WordPress sites. Thankfully, the vulnerability only exists when TimbThumb’s ‘webshot’ feature is enabled, and that feature is disabled by default.
If you administer any WordPress sites, you should check for the use of TimThumb and make sure webshot is disabled. Search your site’s files for ‘timthumb.php’ and if you find it, make sure webshot is not enabled. In other words, if you see this:
WEBSHOT_ENABLED == true
… either comment out that line or change ‘true’ to ‘false’ and save the file. There may be multiple copies of timthumb.php on any given site.