Tools like wpscan are out there in the open, which make the scanning of any WordPress website plugins without any authentication and receive sensitive data like wp-admin login names (which usually contain PII), plugins used, etc.

Is this exposure of this info done intentionally or not?

  • @schroeder Maybe I'm making a logical error myself. What I mean is that scanning WordPress sites can easily and quickly determine the plugins used, users set, which in my opinion is quite sensitive data. – Sir Muffington Mar 18 '20 at 23:52
  • @MechMK1 for example scanning a ssh agent returns mostly only information such as version number of the service and that's about it. Scanning WordPress returns much more information, some of which as in my previous comment I see as sensitive and a move before attack (i.e finding out the username may lead to a dictionary based attack). – Sir Muffington Mar 18 '20 at 23:54
  • How does one get wp-admin login names from a scan? – schroeder Mar 19 '20 at 7:20
  • @schroeder you use the parameter --enumerate u. It quickly bruteforce the JSON API IIRC (or at least it's the method that was used in my use case) – Sir Muffington Mar 19 '20 at 13:06
  • How are you imagining that they could design a way to avoid that? – schroeder Mar 19 '20 at 13:19

Information Disclosure is a kind of vulnerability that different people have different views on. Usually, it boils down to two competing philosophies:

  • It's a vulnerability, because it gives an attacker an unnecessary advantage, however small, that they would not have, would I not have disclosed this information.

  • It's not a vulnerability, because knowledge of the installed plugins and version in itself is not a problem, as long as these plugins themselves are not vulnerable.

Both of these views are valid, but when first confronted with them, most people tend to be on the "better safe than sorry"-side, and want to prevent information disclosure at all cost. However, sometimes it may be beneficial to disclose information, such as when scanning for vulnerabilities. This may seem paradoxical at first, but if you run a WordPress instance with a number of different plugins, having an easy way to access the version for every plugin and checking that against a list of known vulnerable plugins can be helpful.

Could all of these have been concealed?

Yes, absolutely. WordPress could have been designed in a radically different way, which would have made plugin detection a lot harder. But then again, WordPress was made by developers who primarily focussed on making a system that is easy to work with and easily extensible. Avoiding information disclosure at all cost was likely not very high up on their priority list. If it was developed by developers with very little exposure to security topics - which is absolutely nothing abnormal back in 2003 - then they might just not have thought about it.

So why not change it now? Because changing the architecture of a system that is as widely deployed as WordPress is a very, very monumental task, and such a task requires a damn good reason to undertake. Preventing people from knowing you use ACME Corp's Best Plugin Ever in version 13.3.7 is really not such a big vulnerability - even for people who consider it one.

To Summarize

Did the WordPress developers expose all this data on purpose?

Probably not, but I don't speak for them.

Can this still be "fixed"?

Yes, in theory. But in practice, the impact is so low and it would break so much, that nobody bothers.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.