romtek

It might be more accurate if the message was just “Not a core, theme or plugin file from www.remarpro.com”, so that it is clear that it may be from another source

Hmm… I think the following would be clearer to me: “Not a core, theme or plugin file from a public repository at www.remarpro.com”

Matt, today I got a similar problem with two of YOUR files (wp-content/plugins/wordfence/lib/wordfenceClass.php and wp-content/plugins/wordfence/lib/wfConfig.php).

File appears to be malicious: wp-content/plugins/wordfence/lib/wordfenceClass.php

Filename:	wp-content/plugins/wordfence/lib/wordfenceClass.php
File type:	Not a core, theme or plugin file.
Issue first detected:	7 secs ago.
Severity:	Critical
Status	New

This file appears to be installed by a hacker to perform malicious activity. If you know about this file you can choose to ignore it to exclude it from future scans. The text we found in this file that matches a known malicious file is: "strtoupper($qV[4].$qV[3].$qV[2]".

——————
However, for wordfenceClass.php, there is another item in the SAME report that offers to replace this file with a good copy. So, the scanning process, later on, realized that the file is, in fact, a part of Wordfence plugin.

I am using version 6.0.20. It seems bad.

RolyPablo, how have you resolved this?

On this website, WordPress is used as a blog, in addition to the main site, and is installed in a subdirectory.

Thanks for the advice to remove themes I don’t use. It’s good advice.

Yes, this hosting account is home to several websites, and the infection has spread to other parts of this site and other sites. I believe that it started with WordPress (but can’t be sure), when it was 3.x. The infection first appeared, I think, in the upload directory. I’ve read that WordPress used to have a security hole related to upload directory.

I also suspect InstaBuilder plugin, but can’t be sure either.

By the way, version 6.0.17 of WF still exhibits the behavior with header.php that I reported.

a dup post

I have these selected:

Scan for the HeartBleed vulnerability?
Scan core files against repository versions for changes
Scan theme files against repository versions for changes
Scan plugin files against repository versions for changes
Scan for signatures of known malicious files
Scan file contents for backdoors, trojans and suspicious code
Scan database for backdoors, trojans and suspicious code
Scan posts for known dangerous URLs and suspicious content
Scan comments for known dangerous URLs and suspicious content
Scan for out of date plugins, themes and WordPress versions
Check the strength of passwords
Monitor disk space
Scan for unauthorized DNS changes
Scan files outside your WordPress installation

I have these UNselected:

Scan image files as if they were executable
Enable HIGH SENSITIVITY scanning. May give false positives.

Exclude files from scan that match these wildcard patterns. Comma separated.: *.sql,*.tar,*.zip

Yes, I get “Not a core, theme or plugin file” for twentyeleven, twentyfifteen, twentyfourteen, twentyten, twentythirteen, and twentytwelve themes. Has just happened again — header.php were infected.

Please have this fixed as soon as you can because I have to manually replace those files.

And WordFence has missed other hacked files inside InstaBuild directory. So, yes, if WordFence can’t check a plugin or another package against a clean repository, it should report that it wasn’t able to verify validity of the particular package, and it should state the reason. This way, the user won’t be foolishly thinking that it he has things under control.

Also, did you notice the last item I reported: header.php files in all of my themes. I meant default themes that came with WordPress. They WERE hacked, but they ARE essential parts of of the themes. So, it is incorrect to mark them as “Not a core, theme or plugin file”.

I think the marking mechanism is faulty because the files were correctly identified as malicious. It is the flagging them as “Not a core, theme or plugin file” that is incorrect.

Then why did only those two files get flagged? If WordFence can’t do the comparison, it should avoid marking some files as malicious. It should, instead, report that it wasn’t able to verify validity of the particular plugin, and it should state the reason.

By the way, I’ve confirmed that the flowplayer.php IS part of InstaBuilder.

NOTE: both of the flagged files WERE, in fact, corrupted. But they ARE part of InstaBuilder 1.19. So, they can’t just be deleted. They need to be replaced by clean copies.

I’ve been battling the hackers that leave exactly this kind of content for weeks. The infection comes back every week, once or twice a week.

The first thing that is reported by an error message, when I visit my blog, is what you posted above about wordfenceClass.php. I then replace the files using FTP and able to then use Wordfence to clean the rest of the WordPress installation.

This infection corrupts PHP and HTML files outside the WordPress installation too. I don’t know how it enters the site or how to prevent it.

I don’t know (haven’t changed options since installing Wordfence). However, how is it relevant considering that wp-includes/fonts is WITHIN wordpress installation?

Fabian, is this method really beneficial to you considering that PHP files can easily be decoded? (There are online decoders.)

That’s because style.css for your theme contains this rule on line 765:

table {
border-collapse: separate;
margin-bottom: 1.5em;
width: 100%;
}

You need to provide a more specific rule for the table in your form to override that setting.

The developer of this plugin could generate specific CSS rules to control the appearance of the form better.