brucewayne25
Forum Replies Created
-
The issue seems to be related to the WooCommerce Order Limit plugin. Please double check that with the plugin’s author.
You can switch to the Local app in the settings, or you can find a Failover button in the Login Firewall tab and you’ll find there the local rules. You can then apply them to the cloud in the Login Firewall interface or at my.limitlogintattemts.com.
This has been fixed in the latest deployment. Thank you for discovering the issue.
Thank your for your observations. Our dev team will check this out and let you know.
Thank you for your feedback. Our plugin is fully customizable using the settings which will help you control any rates.
Hi, thanks for your feedback. Could you provide more information about false lockouts? We’d like to investigate these more.
Even larger shared hosting plans limit their processes to make sure other users on the same server don’t get impacted. We are working on expanding the log, so that we could catch such cases better. We plan on releasing this in the upcoming version of the plugin.
Hi everyone,
First, I want to sincerely apologize for this. We know how serious it is to be locked out of your own site, and that’s not an acceptable experience.
We recently rolled out 2FA across Limit Login Attempts Reloaded to a very large user base. While it’s working well for most users, situations like this are exactly the kind of edge cases we’re actively identifying and fixing. With millions of sites using the plugin across all kinds of hosting environments, there are unfortunately scenarios that didn’t show up until broader usage.
That said, we take full responsibility here. You should never be in a position where recovery options fail.
What we’re seeing so far
Our dev team is currently investigating an issue where recovery links may fail (including 403 errors) on certain hosting environments. One leading suspicion is that on very low-resource or highly restricted hosting accounts, the decryption process used in the recovery links may not complete properly. This could explain why:- Backup/recovery links return errors
- 2FA emails work in some cases but not consistently for login
- Everything else on the site appears normal
We’re working on adding safeguards to detect and prevent this scenario entirely.
For now, here’s how to regain access immediately:
- Access your site via FTP/sFTP or your hosting file manager
- Go to /wp-content/plugins/
- Rename the limit-login-attempts-reloaded folder (for example: limit-login-attempts-reloaded-disabled)
This will disable the plugin and allow you to log back in right away.
What we’re doing next
- Adding detection for low-resource environments where this could occur
- Improving fallback behavior so recovery never fails silently
- Making it easier to disable 2FA without risking lockout
- Continuing to monitor and respond to reports like yours closely
If you’re open to it, it would really help our investigation if you could share what hosting provider and plan you’re using. That will help us confirm whether this is tied to resource limits or something else.
Again, we’re very sorry for the disruption here. We appreciate you flagging it, and we’re treating this with high priority.
Auf der Grundlage unserer Überprüfung scheint dies nicht zu bedeuten, dass die Website erfolgreich gehackt wurde.
Bei Hide My WP / WP Ghost Lite scheint die Angabe unter „passed threats“ (durchgelassene Bedrohungen) darauf hinzuweisen, dass das Plugin verdächtige oder potenziell bösartige Anfragen erkannt hat, diese jedoch durch die eigene Firewall-Logik nicht als blockiert markiert wurden. In der Praxis deutet dies meist auf Scan-Versuche, Bot-Traffic oder Sondierungsanfragen hin – und nicht auf den Beweis einer erfolgreichen Kompromittierung.
Es ist zudem möglich, dass einige dieser Anfragen durch andere Sicherheitsebenen abgefangen wurden – etwa durch den Server, ein anderes Sicherheits-Plugin oder eine Anmeldeschutzfunktion. In unserem Fall konzentriert sich LLAR auf die Begrenzung und Blockierung wiederholter Anmeldeversuche; daher gibt es hier keinen direkten Hinweis darauf, dass LLAR versagt hätte oder dass die Website kompromittiert wurde.
Dennoch ist die genaue Bedeutung von „passed threats“ letztlich spezifisch für die interne Logik und Terminologie von Hide My WP. Dies ist somit eine Frage, die idealerweise direkt mit den Entwicklern von Hide My WP geklärt werden sollte, da diese festlegen, wie dieser Zähler berechnet wird und was genau sie als eine „durchgelassene“ Bedrohung einstufen.
Kurz zusammengefasst:
es bedeutet nicht automatisch, dass die Website gehackt wurde;
es deutet vielmehr darauf hin, dass verdächtige Anfragen erkannt wurden;
für eine präzise Interpretation dieses Zählers ist das Team von Hide My WP die beste Anlaufstelle.Können Sie einen Screenshot teilen?
Können Sie uns einen Screenshot schicken? Das würde uns helfen zu verstehen, welches Plugin dies anzeigt und was genau wo dargestellt wird.
The plugin uses recommended settings by default. Can you tell us what part you consider strict?
Hello, yes, you just watch the log and compare it to the rules you have set up. That’s very simple to do in the plugin settings.
Hi, can you email us your account information so that we could take a closer look?
Hello, the first thing you should do is to make sure your web site can send messages. There’s a plugin to test it with.
What are you seeing when using the rescue links?
Did you check the spam folder? It is likely that the email with the code is there (if your server is working properly).Can you try logging in using a username instead of email?
If you’ve been logging in with your email before, make sure to update the plugin as we implemented some changes for that in the new version of the plugin.
If that doesn’t work, see if you can rename the plugin’s directory through FTP (add old_ in the beginning). Then log in normally, rename the plugin back and try to update.