frikafrax

I’ve been wondering about the possibility of a vulnerability or bug myself.

While I do have open registration, I’ve used a combination of an application firewall and several plug-ins that has proven to be highly effective in keeping spam and fake subscribers away.

The targeted blog in its current form has been online since 2008. Historically, I haven’t seen a fake subscriber sign-up within the last two years, though not for a lack of trying on the spammers’ behalf as shown by my logs.

But after upgrading to WordPress 3.2 and within the last day or so, I’ve had 70+ (and counting) fake subscriber sign-ups . Now the spam bots are able to create new subscriber accounts, waltzing through the application firewall and plug-ins as if they weren’t there.

I do concede the possibility that this could just be coincidence. But the timing of the upgrade and then the sudden success that spammers are having at creating subscriber accounts despite months/years of failing is certainly curious as well as disconcerting.

Yes, it’ll match that request.

It’ll change this:
/page/43/?s=ts&wpmp_switcher=mobile

To this:
/page/43/?s=ts

I’d recommend you use the second version of the redirect instead.

The first version of the redirect might break some requests since it will remove ALL query strings if it finds the Mobile Pack Switcher query string in the request.

For example:

https://www.myblog.com/article.html?somequery=foo&wpmp_switcher=mobile

…would be stripped down to just:

https://www.myblog.com/article.html

The second version of the redirect will retain any query strings that come before the Mobile Pack Switcher query string.

So in the example above, the request would be changed to:

I.e. https://www.myblog.com/article.html?somequery=foo

This is safer.

@vikrantsharma1

Use this code instead.

This will strip the Mobile Pack Switcher query string from the requested URL and redirect the visitor.

## Strip Mobile Pack query strings ##
RewriteCond %{QUERY_STRING} ^wpmp_.* [NC,OR]
RewriteCond %{QUERY_STRING} (.+)wpmp_.*$ [NC]
RewriteRule ^(.*)$ $1?%1 [R=301,L]

I used this on a few of my sites to deal with the “404” crawl errors reported by Google after I uninstalled Mobile Pack Switcher.

@zoddy11

Try this version of the code:

## Strip Mobile Pack query strings ##
RewriteCond %{QUERY_STRING} ^wpmp_.* [NC,OR]
RewriteCond %{QUERY_STRING} (.+)&?wpmp_.*$ [NC]
RewriteRule ^(.*)$ $1?%1 [R=301,L]

This version takes into account query strings that are placed before the wpmp_switcher query string.

I tested that redirect on my site and it works.

.htaccess is processed in a top-down order so make sure the redirect code comes before the Supercache code in .htaccess.

It would help if you provided a link to your blog and an example of one of the invalid URLs.

The problem is that search engines continue to crawl the previously generated and indexed Mobile Pack URLs after the plug-in itself has been deactivated or uninstalled.

So you need to tell the web server what to do when a request is made for a URL that contains the Mobile Pack Switcher query string.

In my case, what I did was use .htaccess to remove the Mobile Pack Switcher query strings from the requested URL, then redirect the search engine or visitor to the cleaned URL:

## Strip Mobile Pack query strings ##
RewriteCond %{QUERY_STRING} ^wpmp_.*$
RewriteRule ^(.*)$ $1?%1 [R=301,L]

You may have to tweak the code to suit your blog set-up.

Done! ??

Just installed the latest version of the fix and everything seems to be working perfectly.

No permissions issues, all changes to filters are being saved. ??

Thanks!

The fix worked. ??

I installed the fix on a couple of my blogs and I’ve got permissions back on all of them.

But I ran into another problem.

When I enter strings under the Filters section for “Referers to ignore” nothing is saved and slimstat_ignore_referers in the database remains empty.

The rest of the filter types seem to work, with all changes being reflected appropriately in the database.

Just to confirm, could you try to create another admin account and see if this new one has access to the configuration panels?

I tried creating a second administrator level account and no luck. The new administrator account is also denied access to Slimstat’s options.

Okay, I think I have a fix for your issue.

Great! I’ve send you an email via your website’s contact form.

Thanks!

One more question: does your “myadminname” contain any spaces or anything other than letters?

The admin name is purely alphanumeric with no spaces, punctuation or other characters.

Also, is this a network installation of WordPress? What version were you using before the upgrade?

All my blogs are currently “stand-alone” individual WordPress installations. I haven’t tried using the multisite features yet.

I was using WordPress 3.1.1 and had recently upgraded to WordPress 3.1.2.

1) Correct, I’m the (sole) administrator.

2) In the blog where I had Slimstat rebuild slimstat_can_admin, slimstat_can_view and slimstat_capability_can_view, they have been set to their default values. i.e. [a:0:{}, a:0:{}, 'read']

In the blogs that have not been reverted to the Slimstat default settings, they appear as:

[a:1:{i:0;s:11:"myadminname";},a:1:{i:0;s:11:"myadminname";},read]

…with the correct admin account user name entered.

3) Correct. I can view the stats but I do not have permission to access Views, Filters, Permissions, and Maintenance under the Options section.

Thanks!

I really appreciate you taking the time to have a second look at Syndicate Out.

Hi Andrew.

The Media button is enabled in the toolbar but the embedding tags are still being stripped when I switch from HTML to the Visual Editor.