WP-MalWatch WordPress Security Plugin


Improving WordPress blog security requires a combination of vulnerability detection, attack blocking, and scanning.  The authors at How-To-Blog.TV have several recommendations when it comes to vulnerability detection and security attack blocking.  However, we could not find a simple solution for taking the chore out of scanning for evidence of malware in a WordPress blog.  So we contracted a great WordPress plugin developer to write WP-MalWatch for us.  WP-MalWatch was released on January 27, 2009.  It is a FREE plugin and is awaiting approval in the WordPress subversion repository.

WP-MalWatch 2.1.2
Downloaded 354 times

WP-MalWatch is a WordPress security plugin designed to scan a WordPress blog on a nightly basis to alert a blog owner of potential malware or other evidence of a compromised blog installation.  The current version of WP-MalWatch is 1.1.0 and supports:

  • Scanning the Uploads directory for PHP files. (symlink friendly)
  • Scan entire installs for multiple .HTACCESS files (symlink friendly)
  • Dashboard Widget
  • Report Page

WP-MalWatch requires WordPress 2.9 and PHP5.  If you aren’t on those platforms, shame on you as you are asking for security issues!


WP-MalWatch is a FREE WordPress plugin created by Orangecast Social Media in Dallas, TX.  There are three ways you can contribute:

  1. Provide constructive feedback and ratings on the plugin in the WordPress plugin repository.
  2. Donate to the future development of WP-MalWatch.
  3. Contribute to the plugin by writing a scanning module.

Future Development

WP-MalWatch was built in a highly modularized fashion that allows for detection tasks to be added to the overall WP-Malwatch framework.  Planned future scanning capability additions include:

  • Detection of Ecode64 PHP injection strings in core WP files.
  • Planting of multiple .HTACCESS files.
  • Detection of URLs in theme files based on specific keywords (e.g. http://abcdomain.com/cheap-software)
  • Custom Scheduling
  • Email notifications

If you are interested in contributing a scanning module to WP-MalWatch or having a scanning module idea, please contact us at wp-malwatch /@/ how-to-blog.tv.  If you would like to contribute to How-To-Blog.TV as a guest writer in the area of security or securing WordPress, please contact at info /@/ how-to-blog.tv as we can always use writers who are passionate and knowledgeable about WordPress and blogging.

WP-MalWatch Plugin

{ 3 trackbacks }

10 WordPress Plugins We Love | CAKE Web Services Blog | Blogging
February 12, 2010 at 1:57 pm
Securing Your WordPress Installation | Cartier Consulting, LLC
March 10, 2010 at 4:26 am
OpenCamp Dallas – Photos and Session Coverage – Online Marketing Consultant Mark Barrera
August 29, 2010 at 3:30 pm

{ 92 comments… read them below or add one }

Iain January 28, 2010 at 10:59 pm

Tried installing the plug-in and got this error message:
Parse error: syntax error, unexpected T_STRING in /wp-content/plugins/wp-malwatch/wp-malwatch.php on line 12
It’s probably a conflict with another plug-in.


Derick Schaefer January 29, 2010 at 9:21 am


This means that you are installed on PHP4 in your hosting. On services like MediaTemple, you can simply switch that with a selection in your admin. In other scenarios it might require your admin to make those changes. The only solid advice I can give you is that we don’t support PHP4 and you should disable WP-MalWatch. I do apologize for us not doing a better job at trapping that error and providing you a more sensible message. It will definitely be prettier in v1.0.3.

Softer advice would be to consider upgrading your hosting to PHP5. One of the biggest problems in WordPress security is hosting configurations that are out of date. In our case, a blog of ours that got hacked was because of a very old version of Apache that we really didn’t realize the shared hosting provider was using. DO NOT feel you have to upgrade today or break your blog if it is dependent on PHP4. Just something to think about.

Thank you for reaching out and let us know what other questions we can answer.


Eric February 9, 2010 at 2:28 pm

I just upgraded to version 1.03 and received the following error on every page of my admin pages:
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in…/wp-includes/plugin.php on line 339

I had to disable the plug-in to get the error to go away. Any thoughts?



Derick Schaefer February 11, 2010 at 11:18 am

Eric, thanks for the heads up. You aren’t alone. See the replies on this thread. I promise we’ll get this corrected!


Derick Schaefer February 11, 2010 at 11:24 am

Eric, thanks for the heads up and the pointer to the support topic. We are on it. The problem is on our side. A fix will be out shortly.


Eric February 9, 2010 at 2:44 pm

Also, I’m running the most current version of WordPress.

I did come across this in the support forums when a similar error occurred in the Google Analytics plug-in:

There weren’t any details on the actual cause or fix, just said they updated the plugin and the error went away.



Iain February 9, 2010 at 4:12 pm

Thanks for the in depth reply and the salient advice.
I don’t know why my host persists with the older v4, and I have actually had them upgrade some of my databases to v5 in the past, so I will look into this further.


just letting you know February 9, 2010 at 5:47 pm

call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in … on line 339

Got this after updating. Just letting you guys know. thanks


Derick Schaefer February 11, 2010 at 11:19 am

Thank you! We are on it. See the other replies. Hang in there with us.


Derick Schaefer February 11, 2010 at 11:25 am

On it. See other replies. Thank you so much for taking the time to provide feedback and your patience as we improve the plugin.


Nathan Lilya February 9, 2010 at 10:20 pm

Hello! I love the idea of your plugin! My blog hasn’t been up for long, so I don’t really have this worry *yet,* but I like to get my security in *before* something happens… ;) Anyway, I installed this on WP 2.9.1, and this is a warning I got at the top of all my dashboard screens:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in /home/www/everlinkweb.com/therestofus/wordpress/wp-includes/plugin.php on line 339

Any ideas?



Derick Schaefer February 11, 2010 at 11:17 am


Unfortunately it was a “bug” that slipped through our testing. The bug simply throws that message up but the scanner still works on the installs we have tested on. Regardless, we will get this fixed immediately and are going to be releasing new functionality to look for more malware. Thanks for the heads up and hang in there with us. We are dedicated to keeping the quality high on this plugin and evolving it.


Derick Schaefer February 11, 2010 at 11:26 am

Nathan, thanks for the details. The problem is on our side. See my other responses on this thread and thank you for your pro-activeness and patience in this issue.


Nathan Lilya February 13, 2010 at 10:50 pm

Hey Derick – thanks for the quick reply! I just want to confirm that this error won’t in any way impact my blog site. Remember, I’m knew, and haven’t tried my hand at php for quite a few years besides, so just want to make sure there are no conflicts! ;) Thanks a bunch, and it looks like a great plugin besides!!!

– Nathan


Derick Schaefer February 15, 2010 at 2:39 pm

You should be good. We will get the fix to that annoyance out quickly.


Barbara February 10, 2010 at 7:07 am

Hi –

Installed your plugin & getting this error:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in /home4/hoosierr/public_html/wp-includes/plugin.php on line 339

Can you please advise?


Derick Schaefer February 11, 2010 at 11:21 am


The plugin still works; it is just throwing that error message. We will get this corrected immediately. The problem is on our side. Be patient. I’ll get an update out so keep the plugin in your mix but deactivate it if you want the message to go away.

Thanks for helping to confirm this issue.


Alex February 10, 2010 at 8:45 am

Hi, I’ve installed the plugin, but upon looking at any page in the admin area, this warnign is displayed:
Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in [PATH TO WORDPRESS]/wp-includes/plugin.php on line 339

I’m running 2.9.1 on PHP 5.

Any thoughts on what could be causing it?


Derick Schaefer February 11, 2010 at 11:21 am

Alex, see other responses. The problem is on our side. The plugin still works. . .just throwing that annoying error message. We will get fixed immediately.

Thx for your proactive communication.


Rudi February 11, 2010 at 4:41 am

Hi Derick

When this plugin is installed I get the following message:

Warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, ‘WPMW::addAdministrativeWarning’ was given in /home/…/plugin.php on line 339

Any help with why it causes this would be appreciated.




Derick Schaefer February 11, 2010 at 11:16 am


Thanks for the confirmation on this. We identified this based on feedback when we released 1.0.3 and are working to fix it. It doesn’t break the plugin and the scanning still works. . .it simply throws up a message that isn’t helpful! We expect to have a 1.0.4 correction out quickly.

Sorry for the inconvenience and thanks for the follow through.


Peter Green February 12, 2010 at 1:08 pm

Hi, my site is constantly being attacked and malicious code injected somehow, so I installed your plug-in. I had no more problems for a few days but they are back now :-(
Though I had chmod set to 775 on all files could this have been the problem?
If not would you like more information on the code that I have to keep cleaning?
Thanks for all your great work!
Peter :-)


Derick Schaefer February 12, 2010 at 3:19 pm

MalWatch will simply let you know they’ve got in. the goal is to save you time from having to look through directories for clues that they are in. It is very early stages and we have a lot more to add to it.

If they are in your blog, it is likely through a piece of code they have injected or dropped in somewhere. In many cases this is in the base WordPress files will be infected or some additional files will be dropped into a plugin directory. We will have an upcoming post series that will take you through everything you can do to get them out. Once they are out, we love SecurePress for blocking attackers. http://bit.ly/aRa4uF . We use this on all of our blogs. Thanks for the comments and I will get some posts up next week on this topic. Subscribe to our RSS email feed and you won’t miss them.


Derick Schaefer February 16, 2010 at 9:31 pm

Sorry Peter, I missed this in the comments. I am working on an in depth series of posts to help people in locking their site down and dealing with this. Shoot me an email at the orangecaster.com domain (info@) and we can trade some info on the exacts of your situation.

Yes, it is a pain. We’ve had to deal with it too!


Derick Schaefer February 22, 2010 at 4:12 pm

Just published 1.0.4 to the WordPress repository at http://wordpress.org/extend/plugins/wp-malwatch . Sorry for the delay in that fix. Nick was out on vacation.


Hardy February 25, 2010 at 12:36 am

Tried to do my first scan with this and I got this message:

Fatal error: Call to a member function on a non-object in /nfs/c04/h03/mnt/66177/domains/boulderhighsoccer.com/html/wp-content/plugins/wp-malwatch/modules/scan-uploads/scan-uploads.php on line 41


Derick Schaefer March 1, 2010 at 6:23 am

We have not seen this error. We are in the midst of another release so we will dig into this and see if it is something obvious. If not, I’ll come back to you and get a few details as it could be something permissions related. Thanks for the heads up!


Johnny Underscore March 4, 2010 at 10:55 pm

Hi. I’m using WP-Malwatch and it’s been great. It’s drawing my attention to a directory that seems to be used by the captcha function of the WP Contact Form 7 plug-in, but the files in there seem OK as far as I can tell. I’ve been using this contact form for a while now and it’s never given me this warning. Should I assume the files in this directory are a problem and get rid of them? I can always use a different contact form I guess.


Derick Schaefer March 4, 2010 at 11:20 pm

Ask the contact form’s author whether these files are normal. Another option would be to copy them down (so you can put them back if you need to) and delete them. Contact forms are constantly the attack of remote file injection attacks and other nasty things so I’d definitely ask questions but don’t throw the baby out with the bath water! Glad we could be of help. We have a lot more to come.


Trevor Wells March 10, 2010 at 6:10 pm

The following directories have items in them that you might want to examine. Visit the security section of How-To-Blog.TV for detailed information on WordPress security.


How do I fix this? My URL normally flag-sa and not flagsa as shown. What is swift- custom doing here?


Simon Draper March 16, 2010 at 7:21 pm

I’ve installed your plugin, looks very useful on the screenshots, I’m using WordPress MU 2.9.2 on php5. However all I get is a message saying For WP-MalWatch to work appropriately, the upload directory must be set to the default WordPress value of wp-content/uploads. You can change the value here.

How ever the page it links to is blank, is this something on my side or is this plugin not designed for Mu


Derick Schaefer March 17, 2010 at 4:15 pm

We have not tested on MU and are targeting our efforts in that space for WP 3.0. I wish I had a better answer for you on that one.


Simon Draper March 17, 2010 at 4:58 pm

Ok thanks


Daniel September 22, 2010 at 5:14 am

Hi, Derick, I got the same problem. The plugin asked me to turn back the default upload folder. But it seems a bit difficult. I wonder whether I have any good way to use the great plugin. Thanks so much.


Derick Schaefer September 23, 2010 at 9:46 pm

What is your current upload folder? (send it without your domain name. . .meaning http://domain.com/wp-content. . . .)


Arbert March 20, 2010 at 7:53 am

I’ve got this error too:
plugins/wp-malwatch/modules/scan-uploads/scan-uploads.php on line 41


ASLIF March 20, 2010 at 10:14 am

Hello, very much like your blog


Ed March 29, 2010 at 4:54 pm

Hi, great plugin! Having a problem though. I’m getting this error, just started today:

You have more .htaccess files in your system than expected. You are running Apache and should have, at most, 1 .htaccess files in your WordPress install. WP-MalWatch located 5 .htaccess files. You can find them in the following directories:


Weird thing is, the /html/.htaccess and /html/wp-admin/.htaccess were always there and I never got a duplicate error from Malwatch. Any ideas?


Derick Schaefer March 30, 2010 at 10:33 am

Yes, we have feedback on this and have discovered multiple scenarios in which other .HTACCESS files existing. The most prominent one is WordPress Stats (and we trust them!). So, we are changing the UI on the dashboard to simply show a count and lightening the verbiage to entice people to check these out. Then we’ll link to updated documentation that tells a little more about each one. The challenge we have here is that a hacker still could hijack one of these files and we have to do some testing to figure out what the implications could be. We’ll post some documentation around each one of the known HTACCESS files that are out there and document what the contents should be so that you can examine each one of these.

Thanks for your feedback and patience while we growth this plugin.


Matthew Lucas March 30, 2010 at 6:52 pm

yeah i get same error and i think they updated something and there are many scenarios where multiple .htaccess files would exist in those directories.
password protecting is one of them.


Derick Schaefer April 1, 2010 at 10:40 pm

Thanks for the feedback. One option we are thinking of is simply listing them and providing a “quick view” where you can look at what is in each one of them very quickly and know that nothing is wrong. The other thing is looking for 301 redirects in them and flagging that.


Matthew Lucas April 6, 2010 at 1:13 pm

do we know when we should expect to see an update for this issue?
I assume it will be automatic and show up as an update in the plugins correct?


Nick March 30, 2010 at 8:04 pm

Hello! Thank you for the great plugin! Really gives me some peace of mind.

I just got a report with the following message:

htaccess Scan

You have more .htaccess files in your system than expected. You are running Apache and should have, at most, 1 .htaccess files in your WordPress install. WP-MalWatch located 2 .htaccess files. You can find them in the following directories:

/hermes/bosweb/web282/b2825/glo.[removed for this post]/blog/wp-admin/
/hermes/bosweb/web282/b2825/glo.[removed for this post]/blog/

I don’t have any directory called “hermes”. I did a search on all my site files and can’t find anything close to what’s listed above. Any ideas?


Derick Schaefer April 1, 2010 at 5:30 pm


sorry for the delay. . it’s been a busy week. Yes, this is perfectly normal. Hosting companies “virtualize” web servers so they can put 100′s (if not thousands) of sites on a machine. For example, a typical path looks like:


The actual site is found under the /httpdocs/. . .

Nothing to be alarmed about as all that you see before what you recognize is related to the physical machine.

Now, if I’m not getting something here, let me know as we have found some hosting setups that cause malwatch to break and try to solve for those as people let us know about them.


Nick April 11, 2010 at 4:52 pm

Thank you, Derick! I really appreciate your help!


Ed March 31, 2010 at 8:02 am

Thanks Mr. Schaefer!


Gayle Pescud March 31, 2010 at 8:43 am

‘Im wondering if you can help. I just rved this message today: Thank you.

‘he and should have, at most, 1 .htaccess files in your WordPress install. WP-MalWatch located 2 .htaccess files. You can find them in the following directories:

* /home1/glishorg/public_html/wp-admin/
* /home1/glishorg/public_html/


Derick Schaefer April 1, 2010 at 5:26 pm

Gayle, it is possible that there is a perfectly legit reason for the second HTACCESS file in the wp-admin directory. Have a look at it. If it is not referencing a 301 redirect to other sites, then you should be safe. if that is techno jargon to you, then open both files, cut/paste, and send the contents to me at info@how-to-blog.tv and I’ll have a look and tell you my opinion.

We just released 1.1.2 which makes the dashboard reporting for this a little less alarming.


Denis April 1, 2010 at 4:44 am

Just installed on a hacked site but it seems the plugin missed the hacked index that had an eval and decode JS malicious file in it, with that blog having most of its files chmoded to 777. Any way to change that detection ?
I still have all the files if required.
Thanks for the great project.


Derick Schaefer April 1, 2010 at 5:23 pm


Yes, right now we do not detect those hacks but that is next up. . .encode64′s, etc. Can you send those files to me at malwatch@how-to-blog.tv and I will take a look and we’ll incorporate into our approaches for next release.

thanks for the feedback and patience while we grow this. I just put 1.1.2 up which makes the HTACCESS thing a little smoother.


Doug April 4, 2010 at 5:16 pm

We were hacked recently in a way that the plugin did not detect… a bit of html code consisting of an iframe got inserted in our wordpress theme’s footer.php file that was width=0,height=0. It loaded malicious code from whatever the URL originally was (can’t remember).

I would like to suggest you also keep track of recently modified files. There is typically no reason for footer.php to change, and of course there is not much reason for a zero height, zero width iframe for that matter.

Thanks for the plugin and I look forward to additional detection rules


Derick Schaefer April 4, 2010 at 8:21 pm

Doug, yes, our 1.2.X releases will start to look for things in footer, header, and index files. However, you bring a really good point for just base level scanning which is a simple list of recently modified files in the theme. Let me throw that one up on the board for perhaps earlier consideration.

Thanks for sharing your feedback!


Doug April 6, 2010 at 5:20 pm

If you need a beta tester, let me know!

Here is another suggestion that wouldn’t be too bad to do:
Typically when an attack occurs, the wp backend is unaffected. In our particular case, its not affected at all. Therefore, an interface to provide the ability to “grep” a file pattern across the wp-content sources for the injected code would be fantastic. Many times the victim knows where sites are being redirected to as Safari or IE blocks the attempt and warns you… so there are two methods to recovery:
1) Look for recent file changes where there shouldn’t be
2) Grep for the website URL users are being redirected to.

Consider these “attack vector identification” tools. I don’t know much about WordPress’ SQL internals but there may be things to scan for there too.


Sue James April 4, 2010 at 9:42 pm

After the recent updates to WP-Malwatch, where it is now checking the existence of .htaccess files, we have a huge list of files to check on one of our sites – 20 in all! Most of these are there because we are using Zen Cart for the shopping area of our site. Others are legitimately in place for password-protected directories.

I’ve manually checked every one, and all are legit. But it was somewhat frightening to see this full list as a warning on the Dashboard! :)

I gather this will appear permanently as a list of files to be monitored, so I should again manually check each one from time to time for any changes that might have been made without my knowledge?

I don’t know if this would be possible in development of WP-Malwatch, but it would be fantastic to have the capacity to have it somehow store the content of each .htaccess file and, after each file has been checked for legitimacy (and perhaps ticked as such??), only produce a report if there have been changes made to the file.

It would make the process of checking all those darn files SO much easier! :) May not be feasible – in which case I’ll just have to put up with checking all the existing files manually from time to time.

This plugin is excellent, by the way! The security on one of our blogs had been breached by a trojan, so I installed WP-Malwatch on that as well as the other fivec sites I manage. It’s now protecting our main site, three blogs and a website where I’m the volunteer webmaster for a nonprofit organisation. I’ve been delighted with the plugin – it’s been monitoring all sites effectively, and has made me so much more confident about security on all sites.



admin April 6, 2010 at 7:39 am

Great insight and feedback. Yes, we are currently mapping out some features that allow for blog owners to check when things have been recently updated and/or simply dump the contents of these files to a text file and display somewhere in the report.

Thanks for the compliment and definitely more to come on this plugin!! Slowly but surely!


Doug April 6, 2010 at 5:32 pm

One thing I was thinking of doing (a while back) was a plugin that builds a CRC32 of files the user would identify (or folders with recursive descent). A quick scan would find deltas against the CRC. During a scan if a CRC differs, a text editor view of the file with an “approve it” button would then update the CRC entry for that file.

This would help with .htaccess in case your trojan fools the server timestamps.


admin April 6, 2010 at 11:49 pm

Doug, we’ll definitely get you in the loop for beta test. Our next release was going to include the ability to search for any text string in theme files and WordPress backend files that are effected like locale.php. This would include URLs or keywords. I agree that you usually know when you’ve been hit and what to look for.

Still, I really like some of your ideas on creating a sum check for the files.

More to come on this topic. I’ve noted your contact info.


Togan April 10, 2010 at 4:48 am

I am getting the following error in my logs everytime wp-malwatch is doing a scan

PHP Fatal error: Call to undefined function get_plugins() in /srv/www/vhosts/wordpress/wp-content/plugins/wp-malwatch/modules/scan-htaccess/scan-htaccess.php on line 29


Derick Schaefer April 13, 2010 at 3:50 pm

This is because you are running PHP4. We don’t support PHP4. sorry about that.


Ross April 29, 2010 at 4:00 pm

“Fast and Secure Contact Form” Plug-in uses a .HTACCESS file in it’s CAPTCHA directory. Is there a way to identify valid .HTACCESS files as known, so they don’t cause a warning?


Derick Schaefer April 30, 2010 at 12:42 pm

We have gotten a ton of feedback on this and are taking care of this in our next release which will be out soon. More to come on this. Thanks for the feedback and the plugin specifics.


Rahul May 2, 2010 at 3:31 pm


I used this plugin in my website but it wasn’t much fruitful, my site got affected with malware n not got any prior notice but fortunately i took the back up…
so i recover everthing perfectly….
Pls advise better protection plugin so it won’t be happen again ….


David J McClelland May 7, 2010 at 9:29 am

I tried your plugin and got memory errors. Tried the link to report bugs but it didn’t load a webpage. So here is the message:

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 233309 bytes) in /home2/davidjmc/public_html/eLearning/wp-includes/wp-db.php on line 478


Derick Schaefer May 7, 2010 at 11:06 am

David, thanks for the heads up here. Let me ask one question, are you on PHP4 or PHP5. I have not seen this error yet and this one concerns me.


davidjmcclelland May 28, 2010 at 8:28 am


Error went away after I applied an update to the plugin. I originally installed using the built-in install in admin tool, not a zip download.


Derick Schaefer June 1, 2010 at 9:33 am

David, thanks for following up with the information. We did just release the 2.0.X plugin to WordPress.Org which is a complete re-write and has some compelling features to it. Check it out and let me know if you see any problems.


Ralph Johnson May 21, 2010 at 9:36 am

Is there a configuration option to include the “status” on the WP Dashboard, but to also see the remainder of the normal WP Dashboard.



Derick Schaefer May 28, 2010 at 8:12 am

Is it messing up your WP dashboard? Let me know the version and I will get you a drop of our upcoming release to see if that does it too. If so, easier to fix in the new release. Let me know or email direct.


Maf May 21, 2010 at 3:54 pm


I’ve tried to install the plugin & i keep getting this error:

Unpacking the package.

Installing the plugin.

Destination folder already exists. /home/mobileaf/public_html/wp-content/plugins/wp-malwatch-1.1.22/

Plugin Install Failed.

I can’t find where its installed to uninstall it.


Derick Schaefer May 28, 2010 at 8:10 am

Are you installing from the downloaded zip off of our site? If so, go to the wordpress codex from the Ad New Plugin search and install it from there. The directory should be WP-MalWatch without any version numbers. We have a new version coming out in the next few days that is a total rewrite and has a lot of great functionality. Let me know if this helps.


Chris May 28, 2010 at 7:35 pm

I’ve just attempted to install this plugin on two sites that are both hosted on (mt).

On the first site, everything went fine. On the second site, I get this error message:

“For WP-MalWatch to work appropriately, the upload directory must be set to the default WordPress value of wp-content/uploads. You can change the value here.”

My upload directory IS wp-content/uploads, as far as I can see. Unless I’ve been hacked, and something, somewhere, is telling WP not to use that directory for uploads?




Derick Schaefer June 1, 2010 at 7:20 am

Chris, we just released a re-written version to the WordPress.Org repository. Try this version and if the problem persists, let me know. Likely there IS NOT a problem on yourside but simply a hosting scenario we hadn’t accounted for.


Chris June 1, 2010 at 6:35 pm

I get an error after installing:

“For WP-MalWatch to work appropriately, the upload directory must be set to the default WordPress value of wp-content/uploads. You can change the value here.”

My uploads directory IS wp-content/uploads, although the system path in the settings shows the preceding directories on the server.


Derick Schaefer June 1, 2010 at 9:54 pm

Chris, our bad on this. Some of the one touch installs uses the full var/www/vhosts/. . . directory path for the uploads directory. We should handle this but didn’t get to it in this release. Do me a favor and copy/paste that path somewhere safe and change it to wp-content/uploads which should work just find as WordPress realizes where the wp-content directory is. This should fix it for you and I promise we’ll get to this or at least allow modules to be turned on/off.

Thanks for the info and my apologies for the hassle.


Gary Gress June 17, 2010 at 9:36 am

The Mal-Ware scan tells me I have 179 hidden files in my install, and to check the Detailed Report. When I do, I only get a DR title and a blank page. Gary


Derick Schaefer June 22, 2010 at 10:01 am

Gary, if MalWatch does not pull the content of the files, they are binary (e.g. image .jpg) so you might want to investigate them manually. Unless your hosting is doing something unusual, there really should be no reason to have all of those hidden files. A typical WordPress install has ZERO hidden files. We ignore HTACCESS files in that scan.


Jack Heape June 21, 2010 at 9:03 am

I get this error message when I installed the plugin.
“For WP-MalWatch to work appropriately, the upload directory must be set to the default WordPress value of wp-content/uploads. You can change the value here. ”

When I click on the change value link I get taken to an error 404 page.


Derick Schaefer June 22, 2010 at 10:05 am

which change value link? In WordPress upload config?


Bernard July 4, 2010 at 12:05 pm

Thanks a lot for your free plugin and your work.
I have installed it and it works perfectly.
Hope I will never had to detect any malware or so ;-)
Thanks again !


Lee Sutton July 8, 2010 at 1:10 pm

I’m currently running WP 3.0 and I just updated to version 2.1.2. As soon as I finished upgrading, my plugin screen turned into a blank white screen. I tried deactivating and reactivating, uninstalling and reinstalling, no good. Any advice? Mal-watch has worked fine up until now, and I do like it a lot. It’s a solid app and I hope I can continue using it. :)


Derick Schaefer July 9, 2010 at 10:18 pm

Wow! We have tested across 3.0 platforms but your scenario concerns me. Can you email me directly with some details as to your hosting, etc. derick@orangecaster.com


Madhu Rao July 21, 2010 at 9:50 pm

Had what looked like eval/base64 type malware attack. I’m a tad too tied up to totally re-build the site so trying the quarantine and cleanup. The good thing is the site seems up (no more redirects) but the bad thing is I restored from a 2 week old DB and deleted about 200 dead-wood users. I cleaned up plugins and themes I was not using and then installed WP-Antivirus and WP-Malware watch. Neither found any issues with the files when I kicked off the manual scans ; but when I look at Keyword scan for WP-Malwatch, it shows it found 500 matches (have eval,base64,base64_decode now). But when in detailed report it does not show anything. It shows the description only.

Please help…


admin July 27, 2010 at 5:43 pm

Wow, I’d be really interested to see the file that it is pulling on these base64′s. I’m not saying that we might not have an issue with the detailed report piece but it sounds like you have some funny code in your install. One quick fix is a re-install of the same version of the files in WP-INCLUDES and WP-ADMIN to overwrite any infected ones. This won’t impact your theme. If you have the suspected file (e.g. locale.php) let me know and send it as I’d like to see it.


NVO Logistic July 24, 2010 at 12:28 pm

I get this error message when I installed the plugin.

“For WP-MalWatch to work appropriately, the upload directory must be set to the default WordPress value of wp-content/uploads. You can change the value here. ”

When I click on the change value link (that pointing to the URL http://www.mydomain.com/wp-admin/options-misc.php) I get taken to an error 404 page.

My server OP is Linux with Cpanel and PHP version 5.2.13


admin July 27, 2010 at 5:41 pm

So are you saying that you cannot get to your options page from even within WordPress? If so, something is seriously wrong and the easiest way out of that us to use the Upgrade part of wordpress to upgrade to the same version of WordPress or a new one so you get all new files. Let me know the answer to that and I’ll try to provide additional insight.


bowei August 1, 2010 at 1:57 am

I get the same thing. I had this when I was on WordPress 2.9.x, and now as well after I’ve upgraded to WordPress 3.0.1. The WP-Malwatch plugin is also upgraded to the latest (2.1.2).

I downloaded a fresh copy of wordpress 3.0.1 from wordpress.org, unzipped it, and searched for options-misc.php, but found nothing. Looking at the WP-Malwatch code, I see that administrative-warning.php is the source of the error message, where it calls here.’ I find the definition of the function in load_scripts.php, but it doesn’t have parameters defined. Maybe there’s something with inheritance in the code or something, but could it be that administrative-warning.php requires a code change to admin_url() (i.e. no parameters) instead? I tried changing this, and it just goes to the default admin page. Not sure where I’d actually make the change for WP-Malwatch.

I think the options-misc.php page is from an older version of WordPress – perhaps WP-Malwatch needs to be updated? As I note above, I’m not sure what that would change to.


bowei August 1, 2010 at 1:43 pm

Following up on my previous post, in the wordpress admin interface, I go to
Super Admin -> Sites -> click on ‘Edit’ for a site -> scroll down to ‘Upload Path’. By default, it shows “wp-content/blogs.dir/index-number-here/files”, which is specific for that site. I don’t think it would be wise to change this to “wp-content/uploads’.

Yet, the readme.txt for the latest version says:

Sub-domain installations and “One Click” installations have been found to put a fully qualified file system path in the “Miscellaneous -> Store Uploads In This Folder setting”. The default is “wp-content/uploads”. WP-MalWatch WILL NOT activate if the uploads folder is not set to the default setting.

Does this mean that WP-Malwatch isn’t meant for a multisite wordpress install?


Emerald August 30, 2010 at 7:04 am

I installed this (version 2.1.2) on my WordPress blog (3.0.1) and am unable to see the detailed report. I click the ‘see detailed report’ link from the mini-report which is flagging suspicious files on the dashboard, and I can see the headings, but no information on any of the files is visible.


SD September 30, 2010 at 5:30 pm

I’m having the same problem as NOV LOGISTICS, above. The plugin is working fine on my sub-domain site, but not on my main domain. Can you tell me how to fix? Thanks.


Derick Schaefer October 3, 2010 at 11:08 am

Can you provide a little more detail? Drop an email to our info [AT] how-to-blog account


BlogGrrl October 5, 2010 at 5:52 pm

I get same problem as NVO Logistic above. Can you help to make the plugin work properly. When I click on the link it gives a 404 Error. Thanks


Derick Schaefer October 11, 2010 at 12:51 pm

So, WordPress has a default uploads directory of /wp-content/uploads . The example in the plugin, using “mydomain.com” is just an example and clicking on that will definately render a 404 error as whomever owns mydomain.com definately doesn’t have WordPress installed it. Go to your options section from with the WordPress admin and make sure your uploads directory is correct. In many cases, a hosting provider will feed this variable as a full path that will look something like /var/www/mydomain.com/wp-content/uploads . No need for all of the internal hosting garb in that path as any plugin (or theme for that matter) will understand the value of /wp-content/uploads .

Let me know if this corrects it for you.


Leave a Comment