Wordfence seeing files in uploads that aren’t in uploads

Thanks for reaching out.

Can you send a diagnostic report to wftest @ wordfence . com? You can find the link to do so at the top of the Wordfence > Tools > Diagnostics page. Then click on “Send Report by Email”. Please add your forum username (@staze) where indicated and respond here after you have sent it.

NOTE: It should look as follows – Screenshot of Tools > Diagnostic > Send by Email

Also, can you email the scan log to the same address? On the Scan page look for the EMAIL ACTIVITY LOG link right above the scan progress box.

Tim

done. emailed both diagnostic (including forum username) and the scan log.

Thanks.

I’m seeing the same thing here—absolutely tons of errors saying things like “Unknown file in WordPress core: wp-content/uploads/admin-ajax.php”. There’s not an admin-ajax.php there, but it reports this error even on a new scan.

A “find” from the root of my WP install finds admin-ajax.php only in “wp-admin/admin-ajax.php”, as expected.

• This reply was modified 2 years, 6 months ago by Matt Gibson.

@gothickgothickorguk you might do the same, and send in logs in case mine are inconclusive…

@staze Out of interest, is yours also a Multisite WP install? That’s about the only major thing that’s different about mine to most installations.

Yup. It’s multisite.

Hi Staze,

Thanks, we received the diagnostics report and scan log.

Diagnostics shows a custom uploads directory, which is ok in itself, but it seems like there is a symbolic link to wp-admin somewhere — this might be at wp-content/uploads/, or it might be another subdirectory. Can you check if there is a symbolic link, pointing to wp-admin? This is best done on the command line like find /path/to/wordpress -type l -ls, since some file managers may not show symbolic links correctly. (The path can be relative to your current directory, or just . if you’re in the site’s document root.)

If you find a symbolic link pointing to wp-admin, do you know why it is there?

The scan results currently show a “normalized” path instead of the actual path when symlinks are involved, which is making it confusing, but the symlink to wp-admin is not expected, if that is the cause. (We’ll be adjusting the display of paths in an upcoming version so it’s clearer how the WP core files are being found, seemingly in the wrong location.)

You can temporarily turn off the scan option “Scan wp-admin and wp-includes for files not bundled with WordPress” while solving the underlying issue, so these results aren’t in the way.

-Matt R
Wordfence QA Lead

Woke up to see the same thing this morning in a WP network install Wordfence email alert this morning. It freaked me out!

Wordfence FREE is reporting 574 instances of “Unknown file …”

Here is one example:”Unknown file in WordPress core: wp-content/uploads/js/inline-edit-post.min.js.

After reacting too quickly, in hindsight, by manually and then automatically deleting all of the files . . . WHICH BROKE THE WEBSITE . . . and after doing a full restore, the problem was back!

The second time, I started by looking for a selection of the reported files using cPanel File Manager and Filezilla FTP. None are in the the uploads (or other?) directory/directory as reported by Wordfence. I then clicked on VIEW FILE link for a few of the instances. Wordfence displayed the files but indicated they are located in their apparent correct locations in wp-admin (for the instances I checked). So, I believe I’m seeing the same issue that others have reported.

I’ll post this and then capture/send the diagnostic report.

Scott

Just sent both requested diagnostic items
Scott

Hi @wfmattr,

Find is not turning up anything. This broke with the latest update. I’ve had WF installed for years at this point. =/

find . -type l -ls

results in nothing found when in my WP root, or in WP-Content.

I don’t have anything non-standard other than being Multisite. Where does diagnostics think my custom uploads folder is?

Uploads are in wp-content as expected. So it must be getting “lost” somewhere else. =/

Hi @staze,

Thanks for checking that — I could cause similar results with a symlink on a test site (though not quite the same), but if you’re not finding any symlinks, there must be something else. It definitely is a new issue in this release — we reworked part of the scanner that finds files in order to support some less common structures, though this issue is not happening on any of our own multisites.

The diagnostics reports shows that the WP UPLOADS constant is set to wp-content/blogs.dir/1/files/ which I’ve seen on older multisites. It looks like this might have been the default when WP multisite was originally installed on a WP version below 3.5 or so, but could still be in place in sites that were upgraded since then.

I can’t reproduce this by changing the UPLOADS path to the same thing here, but there still may be more to it — so a few questions:
1. Do you see the UPLOADS constant set in your wp-config.php?
2. Does this path actually exist, alongside the real uploads directory?
3. Either way, does your .htaccess have a rewrite that changes the blogs.dir paths to use the uploads directory instead?

@scott5598: Thanks for sending the diagnostics. Normally I’d ask you to make a separate forum post, since the www.remarpro.com forum rules require it (mainly to avoid confusing posts with multiple problems for different people) — but if you want to follow along and compare notes, we might find some common differences.

-Matt R

Matt R,

Thanks for the feedback. From what I have read so far based on the concern as reported by others in this thread, starting with @staze, it appears to me we’re all seeing/reporting on the same thing!

To quote the title of the thread: “Wordfence seeing files in uploads that aren’t in uploads” in a WP multi-site installations. That’s exactly what I’ve seen, including literally hundreds of severe warnings for files that aren’t in the uploads directory but turn out to be in the admin directory, as @gothickgothickorguk noted.

I’ll keep following the thread, as whatever resolution is identified I believe is what I’m looking for as well.

Thanks again.

Scott Simpson

@wfmattr,

1. UPLOAD isn’t defined in WP-Config.php.
2. blogs.dir does exist in wp-content, but /1/ doesn’t exist within that. Looking in All Sites, Edit (for “Upload Path” and “Upload Url Path”), my first site is site 2, and my primary site is set to use wp-content/uploads.
3. There’s no rewrite for blogs in my .htaccess.

Because it’s multisite, WF runs from Network dashboard, which might be issue?

Not sure what else to look at. Happy to look in DB if needed.

Hi @staze,

Thanks for the additional details. It is normal for Wordfence only appear on the network dashboard on multisite, so there’s something more to the issue — during testing, the scan worked normally on several multisites, including one that’s still on WP 3.8, and one running the WP 6.0 release candidate. I don’t have any that are old enough to have had blogs.dir, which looks like it ended around WP 3.5 for new installations, but that carries through upgrades if the site was originally on an older version — so I may have to install a very old version and upgrade in steps to reproduce the issue (and use old PHP versions since I’m sure WP 3.4 won’t run on PHP 7+). It looks like there’s a chance it may be testable using the option ms_files_rewriting too, if this is the issue.

If you haven’t temporarily turned off the option “Scan wp-admin and wp-includes for files not bundled with WordPress” yet, can you run this query?
select * from wp_wfissues where shortMsg like '%admin-ajax.php' limit 5

Edit: If your Wordfence installation is old enough without having reinstalled in the past few years, the wfIssues table needs a capital I, and of course if you have a custom db need to change the wp_.

This will show some internal data for one of the scan results (and potentially a few duplicates or similar results) — if you can email the result to the wftest address in Tim’s original message above, I can take a look. The data can include full paths, so it’s best not to post the results in the forum.

@scott5598: Thanks, and I agree it sounds like the same issue. I don’t make the forum rules, so I’m just trying to follow them too. ?? But I think any commonality between your site and the OP’s will be helpful in finding the underlying cause.

I may not be able to answer further until after the weekend, but if we can narrow down the cause enough, I expect we’ll have a fix in the next release.

-Matt R

• This reply was modified 2 years, 6 months ago by WFMattR.

Okay, emailed that info.

I don’t believe I started with multisite way back in 3.5 days, but I definitely had this wordpress install back then and converted to multisite from that same install. I am on PHP 7.2.

If you all are able/willing, I can give you access to my install. Not sure how much it would help, but I’m willing if you are.

One thing of note, possibly, is I’m set up for mutiisite, and subdomain installs, but I don’t have the domain specified because all of the sites have full domains, rather than being subdomains. Also of interest is there are some WAF statements in my .htaccess, not sure if that’s for everyone, or might be from some older install. Looks like statement for litespeed (which my hosting provider uses).

Thanks!