WordPress 3.4 was released yesterday, with some nice new features. Our WordPress one-click installer automatically installs the latest version for new sites. If you’ve previously installed WordPress, you should upgrade it from within your WordPress Dashboard.
WordPress 3.3.2 was released today, and it contains an important security update to keep your site safe.
Our WordPress one-click installer automatically installs the latest version for new sites. If you’ve previously installed WordPress, you should upgrade it right away from within your WordPress Dashboard. (You should always do that when WordPress tells you there’s a new version available.)
Lots of people (and lots of our customers) use WordPress to run their Web sites. This unfortunately means that lots of “hackers” also try to guess the passwords of those sites.
That’s a problem, so we’ve had WordPress login “rate limiting” in place for a long time. When a single IP address tries loading the WordPress “wp-login.php” script many more times than a human would, we temporarily block that IP address from accessing the “wp-login.php” page until the requests stop for a while.
This works pretty well: we’ve blocked literally millions of password attempts this way. However, last week one of our customers had his site hijacked by someone who did indeed simply guess his WordPress password.
WordPress 3.2 was released a couple of days ago, and it looks like a great update. (We even contributed a little bit of performance-improving code to it ourselves.)
Our WordPress one-click installer automatically installs the latest version for new installs.
If you’ve previously installed WordPress, you can upgrade it from within your WordPress Dashboard. You should always do that when WordPress tells you there’s a new version available.
Today we detected that one of our customers had installed a WordPress plugin on his blog that did something malicious: when the plugin was activated, it sent a stranger an e-mail message allowing full administrator access to the blog.
How did this happen? Well, our customer simply searched the WordPress plugin directory for “Contact Form”, saw the popular “Contact Form 7” plugin listed, then clicked “Install Now”. That all sounds reasonable.
We’re pleased to announce our WordPress “one-click” installer. Using this new feature in our “My Account” control panel, you can easily install WordPress on your Web site.
We saw an interesting problem today. One of our customers’ Web sites uses WordPress with WP Super Cache to (dramatically) improve its performance. Every time the customer posts new content, though, the site is immediately swarmed by search engines, feeds, robots, and other non-humans retrieving the new post. There are a lot of unnecessary duplicate requests, but even excluding the duplicates there are hundreds of requests arriving almost simultaneously.
Unfortunately, WP Super Cache is configured by default not to serve cached results to any request that contains an “equals sign” in the query string — and the plugin that notifies the other sites of new content is including an equals sign.
So rather than being immediately served from the cache, all of the new requests were run through WordPress PHP scripts, driving up the script usage and causing “503 Service Unavailable” errors for up to two minutes on that Web site (not for other Web sites on the same Web server, though; we have protection against that).
If you use WordPress blog software on your site, be sure to upgrade to WordPress 3.0.2 as soon as possible. The upgrade contains an important security fix for a vulnerability that allows any WordPress “author” to become an “administrator”.
Although all WordPress users should upgrade right away, we’ve added security rules to our servers to protect our Web hosting customers who haven’t yet upgraded. Other people may find the rules useful if they use mod_security on Apache Web servers. The rest of this post contains more technical details.
A recently published Firefox add-in named “Firesheep” can be used by “hackers” to easily hijack the connection of any nearby WiFi users visiting many popular Web sites such as Facebook, Twitter, or Hotmail. This vulnerability is a basic artifact of the way the Internet works. In order to prevent this problem, these sites will need to properly implement SSL (https) security.
WordPress installations handle missing image files very inefficiently by default, running the entire WordPress script to build a custom “404 Page Not Found” page rather than simply letting Apache return an immediate default “404” response. Running the WordPress script when not necessary is a huge waste of processor time. For example, WordPress might be able to only process 8 requests per second for a missing image when WordPress generates a custom “404” page, but Apache can return process over 1,000 raw “404” responses per second. If your Web site contains references to missing files, this default WordPress behavior can be driving up your CPU usage unnecessarily. We’ve seen poorly-configured Web sites spend a significant portion of their CPU time processing missing images.
