Renaming /readme.html is extremely poor behaviour

/readme.html is a core WordPress file shipped with every release and Wordfence is tampering with that despite that fact that every third-party WordPress developer is told to never modify/rename/delete core WordPress files!

I think it’s OK to modify readme.html. You’re the first to complain about this. If we get more feedback about this issue from the community that indicates they want a different behavior, we’ll consider changing it.

The default behaviour of the /readme.html renaming has dubiously changed between recent releases – it used to be an option the end-user had to turn on, but it has silently been changed to be enabled by default in the latest release.

We enabled this by default to defeat certain very popular vulnerability scanners. If you don’t like it, just disable the option. It’s as easy as unchecking a box. Nothing dubious about it.

If you are concerned about version leakage (e.g. the latest /readme.html contains the 4.3.1 version string), then ask the WordPress maintainers to remove that version string, which is the correct way to fix this, not to rename a core file randomly!

Why don’t you? The maintainers of WP core value community feedback. You can report your issue here:

https://make.www.ads-software.com/core/handbook/testing/reporting-bugs/

The WP-CLI tool has the command “wp core verify-checksums” – Wordfence’s renaming of /readme.html now breaks that useful security-checking command because /readme.html is part of WP’s checksumming. Yep, a security plugin breaks a core WP security feature – well done.

WP-CLI is not part of core. Again, if you don’t like the feature in Wordfence, just uncheck the box.

If all of that wasn’t bad enough, Wordfence has a horrendous multi-version leak of its own, far worse than /readme.html. Yep, go here on Wordfence’s own product site:

https://www.wordfence.com/wp-content/plugins/wordfence/readme.txt

Every Wordfence install on the net leaks this readme.txt with far more version-related info than /readme.html !

Yup, we’re aware of that, and the version leak that every other plugin with a readme.txt has.

Can I please request that you remove this ludicrous /readme.html renaming and ask the WP devs to take the version number out of the file upstream instead. This is the only sensible course if you’re concerned about the correct way to secure that file.

As I mentioned above, I’d encourage you to participate in the community effort that goes into WordPress and file the issue yourself. Here’s the URL you want:

https://make.www.ads-software.com/core/handbook/testing/reporting-bugs/

We’ve noted your comments and will wait for more community feedback before making a call on whether or not to change the default behavior of our version hiding.

Mark

I was unaware of this change to the readme file.
When I upgrade WP to 4.4 it broke because of the readme file change.
( as in broke the website instead of catching the error )

Luckily I had backups.

I was still unaware until I read this post. Now I will disable the feature as per your response. (I was worried my server was compromised when I saw the hashed file ).

It seems like it would be better to simply 403 these files in .htaccess.
Or better yet (if you can) do it in your conf.d or vhost.d files respectively.

@061375: Do you know how the renamed readme file affected the 4.4 upgrade? We haven’t had trouble on any of our servers with this option enabled.

-Matt R

In my case,”after” everything appeared to have completed and just before the database would have been updated I saw “failed because of readme.html” – (paraphrasing,..I don’t remember the error exactly).

Afterwards I was able to see the website initially.
But the admin page was just blank.
I turned on errors and saw that a function was missing.
Again, not totally sure what function.
But I know it was missing from wp-admin/includes/misc.php
I downloaded the new V from WP and uploaded the file.
Then the website stopped altogether and stopped producing errors or anything…just blank.

At this point I didn’t pursue it any further and simply went to the backup.

Looking at the folder I saw that the readme was changed on a different date than any the surrounding files.
( This made me a little alarmed ).

But then, I found this article, renamed the file and upgraded without issue.

I don’t think anything else in the directory is particularly unusual permissions wise.

This was the first upgrade of a few installations and I renamed all the other readme files before I upgraded, so I don’t know if this would be an issue elsewhere on the server.

Replying to Wordfence’s post:

> I think it’s OK to modify readme.html. You’re the first to complain about this.

It’s certainly not OK to rename a core WP file as I’ve said earlier. I might be the first to directly post into the Wordfence section of the official WP support forum, but Google did find this, which looks like the hand of Wordfence:

https://www.ads-software.com/support/topic/readmehtml-renamed-hacked?replies=3

> If you don’t like it, just disable the option. It’s as easy as unchecking a box. Nothing dubious about it.

Silently changing a default (you should have put up a warning banner about the change) between releases is bad, especially when the default now actually renames a core WP file, which you should *never* do.

> WP-CLI is not part of core. Again, if you don’t like the feature in Wordfence, just uncheck the box.

WP-CLI might not be part of core, but as WP devs you surely know that WordPress has a checksum API documented here *as part of its core* for tools to use:

https://codex.www.ads-software.com/www.ads-software.com_API#Checksum

Wordfence now breaks that checksum API call when it is installed (or upgraded from an older release that didn’t rename /readme/html). and I suspect WP-CLI isn’t the only security tool using that API. Ironically, you either aren’t making that API call in your Wordfence or you’re deliberately ignoring the missing /readme.html – neither of which is decent security!

> Yup, we’re aware of that, and the version leak that every other plugin with a readme.txt has.

You do realise that this makes it “one rule for us and another rule for everyone else”. Your readme.txt is a far bigger security leak than /readme.html, but it’s “la la la, head in the sand, we’re a security company and we know what we’re doing”. I think it’s time to write a WP plugin that renames /readme.html back again and renames your readme.txt to readme.this.is.security.leak.txt instead ??

> As I mentioned above, I’d encourage you to participate in the community effort that goes into WordPress and file the issue yourself.

OK, so *you* rename /readme.html and break a core WP checksum API and *I’m* expected to chase up WordPress devs asking them to change /readme.html because a “security” company has gone against WP guidelines about not changing core WP files? I’m going to get short shrift there I suspect.

As another poster pointed out (and I should have suggested it myself) – how about an .htaccess entry that Wordfence can add that forbids the loading of /readme.html ? This satisfies your “security through obscurity” measure and doesn’t modify the WP core files either. It seems a decent compromise if you won’t budge on this issue.

Oh and how this issue is marked “resolved” when absolutely nothing’s been done about it is beyond me.

@061375 I think your issue is unrelated to renaming readme.txt.

@rklrkl You’re an anonymous troll who is attacking others on the WP forums, like Otto who is an incredibly nice guy (who I’ve met in person) and has made an enormous contribution to the WP community. We’re always happy to provide support to those who need it, but not at the expense of common decency. You’re an idiot. Buzz off.

For reference: https://www.ads-software.com/support/topic/please-use-relative-urls-in-the-wordpress-database?replies=6

Let’s all play nice and stop the name calling.

Even if someone else just seems to be picking fights, you don’t have to be the one to continue it.

How did I get mentioned in this conversation?

My 2 cents: trying to hide your version number is pointless. Doing so by renaming core files and thus breaking checksum utilities is counterproductive.

Just my opinion.

Edit: if you want to hide the readme, add an .htaccess rule to block it.

Guys, the nice thing about being volunteers is that we can choose when and where to spend our time. Our team, specifically Tim, Matt, Brian and Colette (and me) freely donate their (and our company’s) time supporting these forums to the tune of thousands of hours. We’re happy to do it. We expect a modicum of common decency from the folks we spend our valuable time helping and we do our best to be polite and courteous ourselves.

When the level of sarcasm exceeds a threshold, I think it’s completely acceptable for us to simply withdraw and help others who want to focus on the issue rather than personal attacks and venom. So we’re done with this thread.

Yeah, we’ll probably change the way we handle the WP readme with regards to version hiding. But jeez, what a painful way to get there.

~Mark

I understand both sides of the argument. (Ignoring poison) I do think renaming is not the best way. My default setup blocks it in the .htaccess

Might I suggest you add a few apply_filters so developers can modify behaviour the way they like.

Example in: content/plugins/wordfence/lib/wordfenceClass.php:3601

if (wfConfig::get('other_hideWPVersion')) {
        wfUtils::hideReadme();
    }

To

if (wfConfig::get('other_hideWPVersion') && apply_filters('wordfence_hideReadme', true)) {
        wfUtils::hideReadme();
    }

Might not be the best example, but something like this.

I’m with rklrkl here, this is very annoying and should be disable by default!

Just to add to the fray, indeed some polite discourse is the style of this forum. Sorry to see it get a little bit too lively, but good to see some passion. The support here is amazing, strange but true it can be more timely in my experience than if you try for premium paid support! So even though I’m a premium subscriber I always go for support here first (unless for a premium feature, of course…)

As for renaming WordPress core files, in my opinion that’s a basic security practice that stops some bots cold in their tracks. Examples of files we rename because we don’t need and they just attract pests:

readme (renamed by WF, fine)
wp-mail.php (hmmm, some email to hack into, I’m there!)
wp-signup.php (sounds good, let’s all sign up!)
wp-trackback.php (you have to be kidding me)
xmlrpc.php (one of the latest pest attractants courtesy WordPress)

As for the necessity of renaming the readme by Wordfence, in my view, if a bot is looking for a file and it’s not needed, it should be renamed or deleted, and probably added to the Wordfence honey pot. It doesn’t matter if those files are security risks in of themselves or not. If they attract pests, they are a risk by default.

Basic tip, just as WF does with the readme don’t just rename as for example xmlrpc-renamed.php as that’s too easy for a criminal to guess. xmlrpc-random-characters-renamed.php is better.

Suggestion for Wordfence, any time you rename a file, perhaps you should include the word “renamed” in the added filename text, so we know what we’re looking at when we see those random strings of characters. I got confused when I first saw the Wordfence renamed readme file…

MTN

I wouldn’t consider renaming WordPress core files as basic security practice…

*IF* I would want to prevent bots from accessing readme.html, I’d use web server to limit access to it OR file permissions – that would not break “wp core verify-checksums”.

Good point, but my feeling is it’s best just to make the files pretty much disappear if they’re not needed. Much easier for a novice like me, as well. MTN

they *are* needed for “wp core verify-checksums” to work properly.