FixItDik

(marking as Solved)

Just to say a huge thank you to Sanju – with the help of the User Registration log file (accessible via the Tools sub-menu when you hover over the User Registration admin menu item) the problem was located in my own code and resolved super quick after that.

Just in case anyone else hits the same or similar issues:

• Check the log (Admin menu > User Registration > Tools) as the errors trapped there were not even being trapped by the WP Activity Log plugin I have installed
• If your own code (or that of another plugin) is attempting to fiddle with the logic that sends an email to the administrator when a user resets their password, make sure it is using the latest version of the parameters (my own code was for an older version of the event hook that only had 3 parameters, the current version expects one parameter, an array)

Thank you again!

Dik

• This reply was modified 8 months, 1 week ago by FixItDik.

Hi Sanju, I did reply to your email yesterday (sorry to make my request both here and by email). Can you let me know if you got my reply as I would rather not publicise the web site unless absolutely necessary. Thanks. Dik

Just to note: The new password does appear to be set correctly and the normal (logged in) method for changing your password as a user is working fine.

I take it back – Daniel replied almost immediately, here’s his response:

Hi Dik,

I just report my findings to wpscan.com and they file a CVE on request.
CVEs are for more than just vulnerabilities. It is an individual report for a CWE (Common Weakness Enumeration).

An IP block bypass is definitely a security issue at most, and a weakness / configuration issue at least.
IP spoofing via headers (if not REMOTE_ADDR is used) is covered by a CWE: https://cwe.mitre.org/data/definitions/16.html

See also https://portswigger.net/kb/issues/00400110_spoofable-client-ip-address for further details.

Using something else than REMOTE_ADDR as header is definitely not the correct way to check IP addresses by default.
So this is quite easy to fix for the plugin developer by using only REMOTE_ADDR by default and allow users to define a different header via configurable option.

The advice to uninstall is not from me. It is from WPScan and others because the plugin has not patched it.
In summary the CVE is valid and won’t be disputed or changed.

Best regards,

Daniel Ruf

• This reply was modified 2 years ago by FixItDik.

Hi Pascal, I have tried to contact “Daniel Ruf” who appears to be the person that raised this “Vulnerability” against your plugin. I asked him to re-categorise the CVE he raised (or indeed close it) as it would be more accurately defined as a “Deficiency” rather than a “Vulnerability”.
My argument would be that a “vulnerability” is a bug in code that allows hackers to bypass inherent security in the core code (for example code that would allow hackers to modify the core code or override its functionality). That cannot be true of your code – if you uninstall the plugin then WordPress will be less secure.
I did suggest he explain on the CVE why we should uninstall your plugin if he does not agree that WordPress is stronger with it than without it, we shall see what he does (my guess would be nothing) but I just wanted to let you know that you have users out here who really appreciate the security your plugin does provide. Keep up the good work mate. Dik.

Hmmm – if that’s the case I will dig deeper – but I have done nothing special on the site, it simply ticks over so I can’t think why that capability would have been removed from my user. The only thing to change for months is the version of PHP and WordPress but I’ll have a deeper dig, thank you.

Sorry Leo, I wasn’t sure if this was Guttenburg or not but the only thing that came up when I searched was this (previously linked) topic and as we also use your theme I had hoped it was something like a clash of JavaScript versions.

As I can’t now get the panels to appear anywhere else it really is simple: open the page in the editor, click the three dots in the top right (above the page/blocks tabs) and select Preferences and select Panels then turn off and back on the “Additional Panels” (layout, custom fields and Yeost SEO in our case) and as you turn each on it appears at the foot of the page edit main panel.

As I mentioned earlier, this wasn’t happening for me until I did a shift-refresh while on the edit-page page.

I hope this helps. I hope to get time to try to reproduce this on a clean install of WP and your theme but have to be honest I’m a bit bogged down at the moment and this isn’t a big issue (my client, a friend, couldn’t find the layout options which caused us to start looking and I found them when she shared her system with me over zoom)

I hope this helps

Dik

Hi Leo, sorry for the slow response – the notification went to my spam folder, ho hum.

So we have version 3.0.4, I don’t appear to be able to attach a screenshot to show you what I mean but I hope it really is a re-occurrence of the same issue that was mentioned in the old topic I linked to (the description was spot on for what I am seeing pretty much).

I can do a screenshot and share it on DropBox, Google Drive etc then PM you the link if that helps?

Cheers

Dik

Sorry, ignore me – the User Registration plugin was the problem, I created the registration form before I installed your plugin and each form allows you to set the default role for the user the form creates (defaulting to the default role at the time you created the form) – I will message that team and suggest they have a default option of “as per system” so if you change the default role elsewhere, such as in your plugin, it works as expected ??

Sorry again to bother you.

Regards

Dik

Sorry – forgot to mark this as “resolved” – I suspect I may not find the cause but the solution was to find a plugin providing contact forms and use that.

Crikey this time difference make this hard work doesn’t it ?? Sorry again for the long delay in responding.

So I am not sure why you think a Theme would impact the built-in short codes of WordPress but as switching themes has such a minimal impact (esp if done when the site is least likely to have any visitors) I switched to “Twenty Nineteen” and it made no difference what so ever to this issue, sorry.

As no one else is shouting about this then it must either be something specific to my site or to one of the plugins (as I know plugins can impact the functionality of WordPress by hooking in and over-riding functions) so I guess I just have to work my way through them one at a time to find out which one is causing the issue. Thanks for your attention and I will back away bowing, acknowledging that the problem is mine to solve.

• This reply was modified 5 years, 9 months ago by FixItDik.

Sorry, just spotted the URL I provided got a little mangled in my haste, here is the link again:
https://healthypractice.co.uk/bad-contact-form/

Hi, sorry for the delay in answering: nope, this is the “built in” contact form, (hence the “[contact-form]” short code I guess) – I have had to download a plugin and use that in the mean time but the “bad login form” still has the original shortcode which is appearing on the page – do you need me to post any screen shots of the editor etc? It just feels like support for the built in contact form has been removed completely in this version as I could not find it anywhere in the editor either (blocks or classic).

Ah – don’t worry, I found it: I am using the Tiny theme and in there are functions which set maximum content width depending on which template you are using – even when you don’t use a sidebar it limits the image width to 640 if you are using any other template than the “full width” one. Sorry for that, solution was to set front page to use “Full page” template and it behaved fine.