Protection against WordPress “Pagelines” and “Platform” theme security bugs

The researchers at Sucuri yesterday announced that they’ve discovered a critical security bug in the widely used Pagelines/Platform WordPress themes. If you use one of these themes or their many derivatives, “hackers” can easily take over your site unless you update the theme.

Since many of our customers use these themes, so we’ve added security rules to block attacks even if you haven’t updated. And we’re glad we did: our logs show that a large Chinese botnet started attacking every WordPress site we host last night, in alphabetical order (they’re currently up to domain names starting with “e”), testing whether each site is vulnerable to the bugs.

We’re again surprised to see how many customers are using versions of these themes that haven’t been updated in years. I know we sound like a broken record, but when WordPress offers to update something you’ve installed, you must update it if you want your site to stay secure.

Can I see the mod_security rules?

Although our customers are fully protected, we’re often asked to share our mod_security rules when we post something like this. If you’re the technical person running a server for other people who use unpatched Pagelines/Platform themes, these rules should stop the attacks:

# Ensure that if GET or POST data "action=pagelines_ajax_save_option",
# any "option_name" parameter is only "pl_section_desc_toggle"
SecRule ARGS:action "^pagelines_ajax_save_option$" "deny,auditlog,chain"
SecRule ARGS:option_name "!^pl_section_desc_toggle$"
#
# Block all requests where "page=pagelines" and "settings_upload=settings"
SecRule ARGS:page "^pagelines$" "deny,auditlog,chain"
SecRule ARGS:settings_upload "^settings$"


The second rule is not perfect because it also blocks legitimate settings uploads, causing false positives. However, our logs show that malicious uses of this “feature” are vastly more likely than legitimate uses.

Update March 4: We’ve seen some new attacks mixing these parameters in GET and POST, so we changed the original “ARGS_POST:” we recommended to “ARGS:”.