Wordfence seeing files in uploads that aren’t in uploads

Mine is a multisite install created before WordPress 3.5 (I think!). I have:

* No symlinks
* The WordFence diagnostics page suggests UPLOADS is “wp-content/blogs.dir/1/files/”. That location doesn’t exist. I have a wp-content/blogs.dir directory, but the numbers in there start from 3 (I think I probably deleted blog ID 2 at some point in the past.)
* No mention of UPLOADS in wp-config.php
* The main site’s Settings page in the Network Admin sites list says Upload Path is “/var/www/sites/wordpress/html/wp-content/uploads”.
* If I actually upload a media file to my “main” site (site_id 1, blog_id 1) today it ends up in …/wp-content/uploads/2022/05/

I’ve just emailed in diagnostics and scan logs. Hope that helps!

Matt

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

Hi @staze,

Thanks for sending the query results. A developer also checked this out while I was away and is working on a solution. It does look like it’s caused by the path in the UPLOADS not being a real directory, and being handled internally by WordPress in certain kinds of installations.

Just to note — the www.ads-software.com forum rules don’t allow sending login information even if sent separately. Troubleshooting may take a few extra steps sometimes without it, but it’s generally safer to avoid that entirely. ??

It looks like we’re on our way to a solution though, based on the information from diagnostics reports and query results. I expect we’ll have a fix in our next small release, but don’t have an exact date for that yet. I’ll post back here if we do need any more details.

@gothickgothickorguk: Thanks for sending details too — it does look like this is the same issue as well.

-Matt R

Understood, thanks @wfmattr.

And yes, certainly not wanting to give access, but I work in tech, and sometimes you need to get get eyes on the actual problem when you can’t reproduce internally. =)

So I assume the reality here is I converted a standalone install to multisite, so my “blog.1” just stayed using uploads, and the others converted over to using blog.X as I imported them into the multisite. tbh, I’m now curious how modern multisite handles this as if they all use uploads, that could lead to naming collisions (two sites uploading the same file in the same month).

I’m honestly not sure where WF is getting blog.1 as it doesn’t seem to be defined anywhere. I’m also not sure how it’s looping back out to think stuff in wp-admin is in wp-contents/uploads unless it’s part of wordpress handling non-existent URLs and WF isn’t checking for a redirect.

Glad to hear a fix is on the way. No rush on this. I can ignore the warnings for now. I’d rather not exclude directories from scanning since that would potentially hide actual threats.

Thanks again!

I haven’t dug into all of the details, but did find where the UPLOADS constant is being set, while investigating the issue. If ms_files_rewriting is enabled, the site reaches the code here, that uses the “blogs.dir” path and the site ID:
https://github.com/WordPress/WordPress/blob/6e15f7fc9a7b30323e7f36aa92e8b5468145e077/wp-includes/ms-default-constants.php#L33

There’s a comment just before that, saying:
Note, the main site in a post-MU network uses wp-content/uploads. This is handled in wp_upload_dir() by ignoring UPLOADS for this case.

So that explains how the main site is using the regular upload path, at least.

The issue with incorrectly finding wp-admin files when trying to process wp-content/uploads/ is partly from Wordfence resolving symlinks with realpath() — if there is no symlink, we’d get the same path back — but since the path we’re getting from the UPLOADS constant isn’t actually a valid path, we end up with an empty string in part of processing the path, which was not expected.

-Matt R

Ahh… okay. will be curious to know how it is fixed. Not sure if just adding an “is_dir”, or even if($dir) to see if the string is null makes sense in this case.

Thanks much!

Hi @wfmattr Any update on this?

The constructor of wfScanPath does not validate the realpath output. This is set to false for the none-existing wp-content/blogs.dir/1/files. Resulting in the mix-up of folders.

To work around, I created wp-content/blogs.dir/1/files manually and then the scan runs fine.

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

I just tested @brbrbr work around on the one (and only of several) multi-site installs that I have that was flagging a slew of non-existent upload files reported in this thread.

Steps:
1. Re-enabled “Scan wp-admin and wp-includes for files not bundled with WordPRess” that I had unchecked as a containment action.
2. Started a scan, which again began to report no-existing files in upload
3. Aborted the scan
4. Implemented the work around
5. Ran a full scan . . . NO non-existing files reported in Upload!

FYI only comment: Of the total of five existing directories that I found in blogs.dir, one of them (blogs.dir/4/files) had no contents at all, the same as the blogs.dir/1/files folder I added.

Thank you @brbrbr for this easy to implement, nil risk to leave in place (as I see it) work around!

Scott

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

Can confirm this workaround fixes issue. for “safety” sake I added an “index.html” into blogs.dir/1/files.

Thanks for posting the workaround. Trying to think if this potentially has downsides…

Hi @staze,

We’re planning a fix in the next release. Timing just depends on testing it and the other changes we’re planning for the same release.

I haven’t tested the above workaround here, but it sounds ok since there isn’t an alternate directory that would need to be also scanned (the UPLOADS path only actually needs to be scanned separately if it’s not within wp-content).

-Matt R

This should be resolved in yesterday’s release, 7.5.11 — the next scan run should clear the results if they are still present.

If you temporarily turned off Scan wp-admin and wp-includes for files not bundled with WordPress, it can be turned back on.

-Matt R

confirmed fixed. Thanks!

resolving