Different website urls in 'wfcache' file

Looking at the files you sent me and doing some research. I’ll let you know what I find out.

tim

Hi – did you all figure this out? What was the outcome? I’m having the exact same problem. There are folders with different domain names that are in my wfcache file. They obviously shouldn’t be there.

How were these generated and is it malicious?

Let me know – Thanks in advance!

To be honest I just moved on, they didn’t get back to me about the files.

It was removed however. I just checked and the files are now normal. I am not sure what caused it and also why it reverted back to normal.

Best

Thanks for the fast reply mxracer388! Bummer support never got back to you.

@wfsupport – would be great to hear what you have to say regarding this. I searched the source code in the cached files and the domain names are getting added to the hidden HTML debugging data.

How is this possible?

Thanks

This might be attempts at malicious activity, but could also be a misconfiguration at the host or at another domain. If it is only one domain, it may be that the domain owner typed the IP address incorrectly in their DNS settings, so their domain is currently pointing at your site instead of where it should be.

If more than one domain appears, it’s possible that an attacker is trying to use your site as a proxy, but it isn’t working.

Wordfence will cache the requests for other domains that reach your site, so that future requests for the same domain can get a cached page, which is useful if the site really does have multiple domains or subdomains pointed to the same WordPress installation.

If you’re on a VPS or dedicated server and only have one domain for your site, you can prevent it by making your site only respond to the correct domain name. I believe this can only happen on sites that are the default site for an IP address, or possibly also sites that have apache’s mod_userdir enabled.

Are either of you on shared hosting?

-Matt R

Hi Matt,
Thanks for the reply. The two sites that are having this issue are both on the same VPS with dedicated IP address and forced SSL. I checked this morning and multiple folders with crazy domain names are back again, after I deleted them. Some are even new names.

I do have multiple websites on the VPS and what’s strange is the ones with shared IP’s aren’t having this issue. Just the two mentioned above.

You lost me a bit on the mod_userdir part.

– Thanks

Ok, since they have dedicated IPs, you probably have something in Apache’s config files like: <VirtualHost 10.0.0.5 *:443>

So, any request that comes in to that IP will be served by that site’s WordPress installation. Normal browsers fill in the “Host:” in the HTTP headers, and they’ll only ask for a domain that makes sense, but bots can ask for any hostname, and Apache will just send it on for the site to handle if the host was defined by IP. Hosts can also be defined by name, but it might not be what you want to do in all cases. More details from Apache are available here:
https://httpd.apache.org/docs/2.4/vhosts/name-based.html

You could change Apache’s config if you want, but as long as these cached items aren’t filling up all of your disk space or causing any other issue, it might not be worth the time.

You might be able to find the visits that used incorrect hostnames in the Live Traffic page on the Wordfence menu — if they’re all coming from one IP (or just a few), blocking those IPs within Wordfence may help.

The sites with shared IPs would have VirtualHost directives with the site’s domain name instead, so only requests for those domains will be served by those sites’ WordPress installations. Attempts with a bad hostname would go to the default site for that IP (if any).

mod_userdir probably isn’t an issue in this case since you mentioned it is only on the sites with dedicated IPs, but it might be possible for attempts to reach sites with shared IPs this way. If the shared IP is 10.0.0.10, this module allows visits to 10.0.0.10/~username/ for any linux username on the site, without using their domain name in the request, so a faked “Host:” header might produce the same result.

-Matt R

Hi Matt,
Thanks for the detailed response. You’ve given me a lot of routes to explore further. I’ll keep you posted on what I find.

Thanks!

Great, thanks! I just noticed a typo in my last response — the space and “*” shouldn’t be in the VirtualHost line. (I copied the line from a test server and meant to replace that with the sample IP.) Anyway, let us know how it goes.

-Matt R