This release fixes issues in the remote publishing interface, which under certain circumstances allowed Author- and Contributor-level users to improperly edit, publish, or delete posts.

If you have remote publishing enabled on your site you are urged to upgrade. You can do so easily via the built-in automatic upgrade feature. If upgrading the old fashioned way is your cup of tea here is the list of revised files …

wp-includes/version.php
xmlrpc.php
readme.html
wp-admin/includes/update-core.php

I have not tested any of these with the latest WordPress 3.0 beta.

Monitoring

In my first article on WordPress security I mentioned Open Source Tripwire as an option for monitoring your WordPress install for unexpected changes. A reader pointed out that it wasn’t the best solution since it’s no longer maintained and suggested a couple other alternatives. Since then, I’ve discovered a much easier way of monitoring your WP install: WordPress File Monitor.

What it does: monitors all the files in your WordPress directory (except the ones you tell it not to) and e-mails you whenever something changes. This means nothing changes without you knowing about it. If someone edits your theme files to include spam links or uploads weird php scripts, you’ll know right away.

Above is a screenshot of the settings I use.

Dashboard Alert: I had this set to yes for a while, but having clear the notification pretty much anytime I made a post (because I upload images, and the sitemap.xml changes) got tedious. Just keep up with the e-mail alerts if you turn this off.

Scan Interval: 30 minutes might be a little too often, I should probably cut this back to something more sane like 2 hours.

Detection Method: My main site is quite large and performance is a big concern for me, so I keep it set to Modification Date. If you’re really paranoid and have a small site, change this to Hash.

E-mail address fields: self explanatory.

Notification format: Detailed. Why would you want anything less?

Site Root: Theoretically, you shouldn’t have to change this.

Exclude paths: I exclude my cache folder (if you don’t use WP Supercache or something similar, you don’t need to worry about this) and error_logs that get a lot of errors. I do have it monitor my Uploads folder in case someone tries to slip an exploit disguised as an image in there somewhere.

AntiVirus for WordPress

I learned about this one from the plugin author in the comments on my original post. As far as I can tell, it scans the core WordPress files and template files for exploits.

You can also have it do a daily scan and send you the results. I don’t do this since I’m constantly monitoring my site for changes with WordPress File Monitor. If you don’t want to monitor every single change in your WP directory, this could be a good alternative.

WordPress Exploit scanner

This seems to do a more thourough scan than Antivirus for WordPress, but I always run into memory problems if I try to run it with the “Files” option checked.

What to do if you’ve been hacked

Detailed instructions will have to wait for a future post. For right now, see the WordPress Codex entry for what to do.

Bonus: greping for great justice

grep is a UNIX command for searching the entire text of a file or files on a computer. If you know the exploit you’re looking for, it’s extremely useful. To do this you’ll need SSH access to your web server, and you’ll need to be comfortable using it.

I had a nightmare of an exploit a while back that I eventually figured out: somehow someone had uploaded a copy of webadmin.php (with a different name so it would be harder to spot) to a few places on my server. They could then navigate straight to that file and change any file on my server whenever they wanted. I found one instance of it and deleted it, and thought that would be that. But I was still finding that my template files were getting edited. Here’s what I did:

1. Logged into my web server by SSH
2. Changed directory to my public directory (you may need to ask your web host where this is)
3. Ran the following command: “grep -r ‘webadmin’ *”

I was then able to locate the file because even though the file had been renamed, it still contained the text “webadmin.” I was then able to delete the file.

As before, I’ll emphasize a few things:

1. Your WordPress security is only as good as the security on your local computer. If you’re not running good antivirus and anti-malware software or are using an insecure wireless connection, none of this will matter.
2. Likewise, if you’re not keeping your WordPress install updated, none of this will matter.
3. I should have at least mentioned this in my previous security article but didn’t: your WordPress security is also only as good as your web server’s security. Since the audience for these tutorials is beginners, I’m going to assume that you don’t have a lot of control over your host’s security settings. So I’m not going to say anything else about this other than to look for a reputable host with experience hosting WordPress.
4. Make sure you’re using a strong password. See step 2 of my previous tutorial.
5. I’m going to assume you already know how to install WordPress plugins.

NOTE: I’m writing this guide for WordPress 2.92, the current stable release. All of these plugins seem to work with WordPress 3.0, but I haven’t thoroughly tested them.

WP Security Scan

Let’s start by checking for the biggest security holes first, using the plugin WP Security Scan.

After you install you should see a new “Security” section on the left column of your dashboard:

Let’s click “Scanner” and check our file permissions, the most crucial of security settings in WordPress. Chances are everything will be shaded green, and everything’s ok. However, if anything’s not set correctly it will be highlighted in red. Changing file permissions is beyond the scope of this tutorial – contact your web host if you need to change anything.

Next, let’s change our database prefix. This is a “security through obscurity” technique. What we want to do is make your WordPress database harder to exploit by using a database prefix other than the default one – this way any sort of generic, automated attack on the database will likely fail because the hacker will be using the wrong database prefix.

BEFORE ATTEMPTING THIS MAKE SURE YOU BACKUP. I can’t stress this enough. I wrote a tutorial on backing up your WordPress tutorial. Even if you don’t use the plugin I describe there, make sure you’ve got a good backup before proceeding.

If you followed my last security tutorial and changed your database prefix during install, you can skip this step.

Otherwise, click “Database” on the Security section. You’ll see something like this:

If you see something other than “wp_” in the field labeled “Change the current” field, then you can skip the next step.

Change “wp_” to something else. It’s highly recommended that you still keep the _ for database readability in the future, however.

Click “Start Renaming”

If this fails, you’ll either have to change the database prefix manually or not at all. Manual changes of the prefix table are beyond the scope of this tutorial.

Secure WordPress

Next, let’s install Secure WordPress. After you install it click “Secure WP” in the settings column of the left column of the dashboard. Most of the defaults should be fine, except one: if you’re not planning on using Windows Live Writer, check the box next to that option and click “Save Changes.”

WordPress Firewall

The steps above will help prevent attacks by hiding information about your WordPress install from attackers, making sure the correct file permissions are set, and plugging a few potential security holes. Next we’ll install some plugins that actually stop attacks on your blog.

WordPress Firewall is a handy plugin for preventing a variety of attacks. This one is especially important if you weren’t able to change your database prefix. It’s quite simple – just install it. There should be no need to change the default settings. Important: WordPress Firewall has only been tested up to WordPress 2.8. It has not been tested with WordPress 2.92 or WordPress 3.0 beta 2.

Bad queries

Block Bad Queries, like Firewall, prevents hackers from performing certain common dangerous actions on your site. This one you just install and activate – there are no settings to change.

Chap Secure Login

If you’re not using SSL to login (once again, beyond the scope of this tutorial), you can use Chap Secure Login to encrypt your password. This is especially recommended if you use a lot of different computers to access WordPress, or frequently use public wireless Internet connections. Chap is another remarkably simple plugin – just install it and activate it and you’re ready to go. Note: you’ll get a warning the first time you login after installing. According the plugin developers, this is to be expected.

Login Lockdown

Finally, we’ll want to protect against brute force or dictionary attacks. In an out of the box WordPress installation, users can attempt and fail to login an infinite number of times. This means someone could try thousands of password combinations until they got the right one. Login Lockdown will ban users from IP addresses that have tried and failed to login too many times.

Install the plugin and click “Login Lockdown” in the “Settings” section. You should get an options menu that looks like this:

If you have a hard time typing your password correctly, you might want to set the “Max Login Retriess” a little higher.

I also recommend using the “Mask Login Errors” option. Normally, if a user types an incorrect username WordPress will return an invalid user name error. But if the user types a correct username but an incorrect password, WordPress will return an invalid password error. This gives someone trying to crack your password an extra hint as to whether they at least have the right username. If you use the “Mask Login Errors” option, WordPress will return a generic “username or password is incorrect” error instead.

Ask Apache

Many people swear by AskApache Password Protect. However, I have not been able to get it to work with my host. Your mileage may vary. If I understand it correctly, this plugin adds an additional password to the /wp-admin directory. If you allow open registrations and have lot of users logging in, you might not want to use this plugin.

Conclusion

There’s still much more you can do, such as using .htaccess to protect directories, moving core WordPress files, and monitoring for exploits. Those are things we’ll have to cover in the future. If you have need to harden things further now, please see the Hardening WordPress Codex entry. Remember no (usable) site will ever be completely secure, but if you’ve installed the plugins above your chances of getting hacked will be greatly reduced.

This guide should be relevant for both WordPress 2.92 (the most recent stable release as of this writing) as well as WordPress 3.0.

Overview:

-Preliminary steps for securing your WordPress install
-Changing defaults in WordPress to implement “security by obscurity”
-Choosing strong passwords
-Installing and configuring the Secure WordPress plugin
-Keeping WordPress updated and backed up
-And we’ll take a first look at some advanced security measures

Preliminary steps:

1. Secure your computer
As the WordPress codex says: “None of the following makes the slightest difference if there is a keylogger on your PC.” Make sure you are running anti-virus and anti-spyware software, and make sure said software is up to date. If you’re on Windows and don’t have any antivirus installed, I recommend AVG Free and Windows Defender.

2. Make sure you’re installing the latest stable version from WordPress.org.

3. If you already have another installation or WordPress or other database software on your server, and your host allows it, create completely new database and a brand new database user that only has access to the new database. This is to insulate your other sites in case someone compromises this installation of WordPress.

Installation:

We’ll follow the basic steps of the famed 10 minute install, but we’ll make a few changes to the default settings along the way.

1. First we’ll change the default table prefix (You won’t be able to change this if you’re installing using Fantastico):

If you’re installing manually you’ll see a screen that look like this:

Change the “Table Prefix” field to something else. Be sure to leave the underscore (_). You should have something that looks like this:

2. Next we’ll change administrator’s username. The default is “admin.” Change this to something secret. You’ll have the option later to set a “nickname” – that’s what your readers will see.

Be sure to use a strong password. Notice how WordPress helps let you know whether your password is weak or strong.

Some tips for creating a strong password:

You shouldn’t use any part of your name, username, or the site name in the password.
It should be at least 8 characters long
It should include numbers and symbols in addition to letters
You child’s first name and date of birth may be easy to remember, but is easy for anyone who knows anything about you to guess.
Here’s a strong password generator to help you out.

If you’re using Fantastico you’ll change the administrator username when you setup the new installation. Fantastico doesn’t help you create strong passwords, so you’ll be on your own. Follow the advice above and you should be ok.

3. Finish installing WordPress and login.

4. Next we’ll want to stop WordPress from displaying its verstion number anywhere on the site. I use the plugin Secure WordPress. It also provides some other security features we’ll look at in a moment.

On the dashboard, mouse over Plugins and click the arrow

Click Add New

In the search field, type “Secure WordPress” and click “Search Plugins”

Find Secure WordPress. To make sure you have the write plugin, verify that it is the one by Frank Bültge.”

Click “Install Now” and then click “OK.” On the next screen click “Activate Plugin.”

5. On the next screen, click “Settings” under “Secure WordPress”

You can leave all these settings alone, but if you’re not planning on using Windows Live Writer you should check “Remove Windows Live Writer link in wp_head of the frontend” and then click “Save Changes.”

Congratulations! You’re now ahead of the curve in terms of WordPress security.

Keep WordPress up-to-date, keep plugins up-to-date

The most important thing you can do now is keep WordPress up-to-date. When new versions of WordPress area available you’ll see a notice on the dashboard when you login:

Click the “Please update now” link to see your update choices. The easiest way is to just click “Upgrade Automatically.” If for whatever reason you can’t upgrade automatically, you can download the newest version and follow the included upgrade instructions.

You’ll also want to keep you plugins updated. You should frequently click on the Plugins link on the dashboard and check for notification that look like this:

Again, upgrading automatically is the easiest method. If you can’t upgrade automatically, follow each plugin’s upgrade instructions.

Backup often

Finally, you’ll want to backup your WordPress database frequently in case anything should ever happen to your WordPress install. WordPress Database Backup makes this a snap. We’ll cover database backups in a future article.

Advanced security

If you want to get your hands dirty with advanced security measures, you can lockdown your WP-Admin folder. We’ll look into the specifics of doing this in the future, but if you want to get started now check out the AskApache Password Protect plugin.

And for bonus paranoid points, you can use Open Source Tripwire to monitor your WordPress files for unexpected changes. In the comments, David pointed out that Open Source Tripwire is no longer maintained, and suggested some alternatives. But here’s a plugin specifically designed for monitoring your WordPress files. Works right out of the box!

However there are several more ways in which you can protect your WordPress admin from getting misused or hacked.

The folks at WP Beginners have come up with a list of 11 vital tips to better protect your WordPress admin area, the tips include using a plugin to create stealth login URLs, limiting login attempts to a certain limit so that you don’t get hit with a brute force attack among other things.

11 Vital Tips and Hacks to Protect Your WordPress Admin Area

Well today Ryan Boren has just posted at the WordPress.org blog about the release of the WordPress 2.8.3 Security Release.  As he mentions in the posting this fix is related to the privilege escalation issues in version 2.8.1.

What he says next is the real reason why WordPress is so popular and well supported:

Luckily, the entire WordPress community has our backs.  Several folks in the community dug deeper and discovered areas that were overlooked.  With their help, the remaining issues are fixed in 2.8.3.

Ryan is right – it is the community that looks after each other.  Where else would you have such a diverse and talented group who points out any issues instead of just taking them public even though it would draw a lot of attention and maybe fame for themselves?  How easy might it have been for someone to just point out those additional areas/issues for someone to exploit and get all the traffic? 

Well, it could have been very easy – just send that info to the web instead of into the hands of the developers of WordPress.

This site is another great example of the community around WordPress and the help everyone provides each other to make their understanding of WordPress even better and to share their experience.  I think there are many places that could look at what happens in the WordPress Community and see the positive impact an open environment can do for things.

Thanks to all of you here at WLTC and your willingness to be frank with us on each and every post and to assist each other in the comments and forums. You all definitely rock!

So the next question is – how do we make it even better?

However, WordPress 2.0 was revolutionary in many ways.  Think back to WordPress 2.0 and how that changed WordPress as we knew it at the time. Some of those changes we now take for granted included:

• Completely Redesigned Backend
• Included Spam and Backup Plugins
• Inline Uploading
• Faster Posting
• Post Preview
• User Roles labelled
• Header Customization

WordPress 2.0 certainly set us on the path to the WordPress we know and love today.  Congratulations 2.0 on a terrific service life – rest in peace “Duke”.

Time For An Upgrade?

What does this mean for you as an individual blogger, website developer or site admin?  Well the first thing it means in my opinion is that you should get upgraded to the latest and greatest version of WordPress which is version 2.8.2 and was mentioned on this site about two weeks ago by Keith – WordPress 2.8.2 Security Update.

Although it was published to fix a XSS vulnerability it has been out in the blogosphere for long enough to reveal any issues with the fix.  In fact for me it fixed an issue of posts not being published when they are scheduled ahead of time.  Plus I am a geek and like all my stuff to be the most up to date they can be

What about you though? Have you updated to the latest version of WordPress? Have you made the jump to version 2.8 at least?  What keeps you from making that leap to the latest version of WordPress?

Anti-spam WordPress Plugins

Akismet – One of the best plugins to protect your WordPress blogs against spam comments, this plugin has worked like a charm for many users, saving then time and effort while moderating and managing comments.

WP-SpamFree Anti-Spam – An extremely powerful WordPress anti-spam plugin that eliminates blog comment spam, including trackback and pingback spam. Includes spam-free contact form feature as well.

WP-Hashcash – WP Hashcash is an antispam plugin that eradicates comment spam on WordPress blogs. It works because your visitors must use obfuscated JavaScript to submit a proof-of-work that indicates they opened your website in a web browser, not a robot.

WP reCAPTCHA – reCAPTCHA is an anti-spam method originating from Carnegie Mellon University which uses CAPTCHAs in a genius way. Instead of randomly generating characters, reCAPTCHA uses a combination of these words from digitalized books and  further distorts them to construct a CAPTCHA image.

Math Comment Spam Protection – Probably the most simplest way to thwart spammers robots from posting comments on your blog, it adds a new field to the comment form asking users to enter a sum of two numbers, you will have to edit your contact template to include the comment spam field to it.

Security Related WordPress Plugins

WP Security Scan – Scans your WordPress installation for security vulnerabilities and suggests corrective actions. It allows you to generate strong passwords, check improper file permissions, database security, version hiding, admin panel protection and more.

WordPress Exploit Scanner – This plugin searches the files on your website, and the posts and comments tables of your database for anything suspicious. It also examines your list of active plugins for unusual filenames.

AskApache Password Protect – You can set up Password Protection for your blog using HTTP Basic Authentication, or you can choose to use the more secure HTTP Digest Authentication.

TTC WordPress Security Tool – This plugin blocks cross-site script attempts, ip numbers of ill behaved people and bots and bans bad user agents.

Secure WordPress – Little help to secure your WordPress installation: Remove Error information on login page; adds index.html to plugin directory; removes the wp-version, except in admin area.

WordPress Firewall – This WordPress plugin investigates web requests with simple WordPress-specific heuristics to identify and stop most obvious attacks.

Did I miss anything out? Do you use any plugins for optimizing security and protecting against spam comments? Do share them with others by commenting here.

Antivirus for WordPress is a useful plugin that will scan your templates and also can monitor it on a daily basis for malicious injections in the themes.

You can also setup the Antivirus plugin to run a check daily and send you a email if it finds anything wrong in your templates, definitely another good tool to keep your blog safe and secure. Thanks Sid.

10. Easy Installation

I have seen plugins that require you to modify code after plugin activation to be able to get it to work properly. The instructions were documented clearly in the readme.txt file, but most of the users seem to have missed it (I could tell from the frustration in the plugin support thread). Not everybody reads the installation instructions inside the readme.txt file. The plugin should make an attempt to be able to run straight out of the box after activating no matter how complicated it is.

A good example of this can be found in the “cSprites” plugin. Just activate the plugin and it stitches all images in your posts into CSS sprites to reduce HTTP requests.

9. Seamless Upgrade

As a plugin gets revised, there are bound to be more configuration options or database changes. A good plugin should be able to handle these database changes seamlessly upon upgrade. There are a few ways to do this.

One method is to keep track of configuration option fields. If the option field is missing, then populate it with the default value.

Another method is to keep track of the last upgraded version as one of the hidden plugin settings. On each wp-admin page load, the plugin can check the last upgraded version against the current version and perform a database upgrade operation if necessary.

A good example of seamless upgrade can be found in the “Top 10” plugin.

8. Uninstall Option

The majority of plugins I see leave a bit of a foot print in the database after the user deactivates and deletes it. Some even leave a whole table in the database. Great plugins give you the option to “uninstall” and wipe out all information regarding the plugin.

A good example of this uninstall feature can be found in the “WP-PostViews” plugin.

7. Meaningful Error Messages

When things go wrong with the plugin, there should be a meaningful error message hinting at the problem. That way, the user can troubleshoot it themselves without having to ping the author for support. For example, there are quite a few plugins out there that require you to grant server write permissions to a folder before it can work properly. Failing to do so causes the plugin to silently fail or to bark with weird error messages.

A good example of highly meaningful error messages for troubleshooting can be found in the “WP Super Cache” plugin.

6. Localization Support

Not everybody is comfortable with English. Great plugins are aware of this and are coded with localization support.

A good example of a plugin with localization support is the “All in One SEO Pack” plugin.

5. Intuitive Admin User Interface

Huge plugin configuration pages can confuse the user. It is best to group similar options into it’s own sub-page. It might also be helpful to group advanced features onto its own page or have them hidden by default. That way new users won’t get intimidated by confusing options.

A good example of intuitive plugin admin user interface can be found in the “Referrer Detector” plugin.

4. Reset/Import/Export Options

I am happy to see that a lot of plugins now have the “Reset options” feature which lets you restore configurations if anything bad happens. I have yet to see “Import” and “Export” configurations widely used though. If the plugin has a lot of options, it would be nice to offer the user the ability to import and export those options. That way people can make a backup of their settings or use it as a way to easily manage multiple blogs.

A good example of reset/import/export options can be found in the “WP Greet Box” plugin.

3. Optimized

There are a many things to consider here aside from code performace and optimized database calls. Here are a few outside-of-the-box examples:

• A plugin should not load unnecessary CSS and Javascript files if it doesn’t need to. For example, there is no need to load the same CSS and Javascript files on every wp-admin page if it is only being used on one plugin settings page.
• Since WP Super Cache is one of the most popular ways to fight traffic storms, a good plugin makes an effort to be compatible with WP Super Cache.
• WordPress is always being enhanced (new functions/features added and old ones deprecated). A good plugin stays up to date with these API changes. For example, wp_enqueue_script() and wp_enqueue_style() help avoid reloading the same CSS or Javascript file. wp_enqueue_script() has been available since version 2.1 and wp_enqueue_style() since version 2.6, but I still see many plugins not using them.

2. Secured

A good plugin does not ignore security. There are also many things to consider when thinking about security.  Here are a few basic examples:

• A good plugin makes use of nonce validation in wp-admin.
• A good plugin does not print sensitive information into the Javascript code since it is visible on the client side.
• A good plugin makes an effort to protect against SQL injection and XSS exploits.

1. Good Support and Thorough Documentation

Finally, no one will use the plugin if it’s not supported or documented properly. There are plenty of awesome plugins out there that I don’t use just because it is not supported (e.g. Popularity Contest).

Do you Disagree?

Do you think that there should be something else on that list? If so, please share in the comments section!

I personally follow a few simple rules to make sure that I never fall for a social engineering or covert code trap on my blogs.

• Always download core WordPress code from http://WordPress.org. Type the link into your browser address bar rather than following a link from another blog or site. This includes updates and security fixes. If your web host offers one click installs or upgrades through their control panel, they are probably safe (they are safe if they are on a current version). I still suggest either installing a fresh copy from WordPress.org or using WordPress.com, but I do understand that one click installs are convenient.
• Try to download plugins and themes only from the official WordPress Extend. There are way too many themes and plugins (though much less plugins) that contain convert code and new WordPress theme download sites seem to be popping up everyday. We have covered shady themes many times on this blog.
• Never download “hacks” or “patches” to WordPress from anywhere. If you are unfamiliar with PHP, I would suggest that you ask people in the WordPress forums for help or contact us through our form on this blog for help. Always download official patches, updates and installs from the WordPress.org site.
• If you find a cool new trick, theme, plugin or hack for WordPress via a Google search, please be careful. I know the following is a cliche’, but if it looks too good to be true, it probably is.

Do you have any suggestions for our other readers? Have you found strange code on your blog or theme?

If you have open registration on your blog, the WordPress.org team recommends that you upgrade your install to WordPress 2.6.2 A handful of other fixes are also included in this upgrade. Here is a list of changed files.

Multiple vulnerabilities have been identified in Photo Album (plugin for WordPress), which could be exploited by remote attackers to execute arbitrary SQL queries. These issues are caused by input validation errors in the “wppa.php” script when passing user-supplied parameters (e.g. “photo” or “album”) to certain functions (e.g. “wppa_album_name()” or “wppa_photo_name()”), which could be exploited by malicious people to conduct SQL injection attacks.

Multiple security advisory services places this round of vulnerabilities as a Moderate Risk. For example, FrSIRT describes the Moderate risk as being:

Remotely and locally exploitable flaws, which could lead to denial of Service or privilege escalation.

Versions 1.1 and prior of this plugin are vulnerable. As always, it is recommended that you disable this plugin until a patch for it is released.

[EDIT] Version 1.1 is a fix for this vulnerability. Versions 1.0 and prior might be vulnerable.

First and foremost, there are various version of this problem and they might have different causes stemming from the same source. I list them here in no particular order. I found all the topics starting with a search for the dreaded “Method Not Implemented” 501 error code from the admin panel of WordPress.

POST to /test/wp-admin/index-extra.php not supported: This error is also noticed on post.php and theme-editor.php. Now there are various WordPress Forum posts providing somewhat workable solutions to the problem. I tried some of the solutions but either they did not work for me (I had not looked that closely at the error before trying them) or they were too broad and I did not care for the results. There is some finger pointing in both the forums and the various other pages I found but I believe that the answer lies somewhere in the middle.

In my case, posting caused a “PHP Injection Attack. Matched signature” error that I found in my Apache error logs and the error generated on the browser said “Method Not Implemented 501 error code” with the name of the offending file. This error was caused by ModSecurity which is an Apache module that helps secure web applications on the fly. Now the errant bit of text was in ARGS:content that was bring posted to the server and it matched the regex in one of the ModSecurity rules. It could have been generated by WordPress itself or it could have come from one of the various plugins I have on my blog. I am not sure and I have not taken the time to investigate it further. (please provide more information if you have any). This was a false positive from my perspective and I needed to find an elegant and safe solution that would work.

On reading further about false positives, here is the solution that worked the best. Since I wanted to disable the rule that was catching the post, and not disable the whole mod security for either a file inside the admin folder or the whole admin folder, I found a way to do just that through the Apache configuration files for the virtual host. I found the rule number that was being triggered in the Apache error logs and though I will not disclose the rule number here for security reasons, it was relatively easy to spot. Then I added the following code to my httpd.include (or httpd-vhosts.conf depending on your hosts’ version of software) at the end of the file.

<LocationMatch "/wp-admin/post.php">
SecRuleRemoveById XXXXXX
</LocationMatch>

where XXXXXX was the rule number. Now an ever better solution would be to readd a new rule with the offending regex trimmed out or a !ARGS:content to the Secrule section to only apply to post.php inside the admin folder.

Some caveats: This case ONLY applies to a blog I was working on and the content that was being posted. Your case might be different. If you want to use this method to fix the problem and have no access to your server, just direct your administrator to this post. The secret is to find the offending rule in your error logs and use the rule number to isolate it from the file that it breaks by using LocationMatch and SecRuleRemoveById in your Apache vhosts config file.

Any insights or suggestions will be highly appreciated by me and I am sure by other readers.

Input passed to the “pre_footnotes”, “priority”, “post_footnotes”, and “style_rules” array elements in the “wp_footnotes_current_settings[]” array in the admin_panel.php script is not properly sanitised before being returned to the user. This can be exploited to execute arbitrary HTML and script code in a user’s browser session in context of an affected site.

The good news this time around is that, ‘register_globals‘ must be turned on for exploitation to occur. If you are using this plugin on your site, it is advised that you disable the plugin until a security patch has been released. According to the security bulletin, the solution is to edit the plugin source code to ensure that input is properly sanitized.

Again, if you know that your webserver has register_globals turned off, you are in the clear.

S@BUN has reported an “id” based SQL injection vulnerability within the WordsPew plugin version 3.x for WordPress.

Input passed to the parameter “id” in wordspew-rss.php is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code.

The solution again is to edit the source code of the plugin to make sure that input is sanitized.