WFMattR
Forum Replies Created
-
Forum: Plugins
In reply to: [LiteSpeed Cache] reCaptcha not working during LoginYes, that is expected — the captcha test mode is intended to log the captcha scores received without blocking, but it is not meant to handle issues with a cache or other unusual plugin conflicts. Unfortunately, we haven’t been able to reproduce the issue on several sites, and we have only heard of this problem from a few people, so there may be something unusual about the setup on your site, that not many users have. If you are able to post any details about the hosting plan you are using, that might narrow down the cause — or if you’re running a VPS, then it may help to know the Redis or Memcached versions you’re using or any non-default configuration.
Forum: Plugins
In reply to: [LiteSpeed Cache] reCaptcha not working during LoginOk, sent — hopefully this helps address vygon’s issue and the others. I will be reachable by email if there are any questions. Thanks!
-Matt R
Forum: Plugins
In reply to: [LiteSpeed Cache] reCaptcha not working during Login@litetim: I have been looking into this issue reported by a few Wordfence users (the captcha message above is ours), and disabling LiteSpeed Cache’s object cache has worked for 3 of them who responded so far. Our implementation uses transients, and I saw a few other posts related to transients in your forum, so this probably has the same cause.
I’m not sure yet if the object cache is returning transients that should have already expired, or if it is not returning transients that should still be valid.
-Matt R, Wordfence QA Lead
Thanks!
-Matt R
Thank you!
Wordfence 8.1.4 was released to address this issue. Thank you everyone for reaching out!
-Matt R
@mrsdizzie — can you also tell us when you see these errors? Are they occurring on every hit, or are they only seen sometimes in logs, while most hits are working correctly? There are several uses of the
inet_pton()function, so it will be helpful to know when it occurs, since we don’t have a stack trace, and have not reproduced the issue in normal plugin usage on these new PHP versions yet.-Matt R
Note that this change was not included in today’s plugin release, as it was already in development at the time. We’ll be scheduling this soon, but I’m not sure if it will be in the next small release or not yet.
-Matt R, Wordfence QA Lead
Hi @karlemilnikka,
This dialog box has an “X” in the corner that allows you to close the window. Due to a font issue, this “X” was missing in that release, and we fixed that, so we didn’t find it necessary to also add a redundant button with the word “Close” on it.
But later, you called it an accessibility issue — do you mean that the “X” in the corner is not visible or can’t be reached by the keyboard for some users? If so, we can add the “Close” button back.
-Matt R, Wordfence QA Lead
Hi Jose,
Wordfence’s firewall runs in PHP. A few Wordfence features use .htaccess to block specific files, like an exposed log or configuration file, if any are found. Javascript is used to support a few features, but not to block attacks.
Caching is generally not a problem because attacks require PHP to run, in order to modify anything on the server — if a hit comes in that can be served from cache via .htaccess rewrite rules or an external cache like Varnish, then no PHP code is running on your server in order to serve that hit. Some cache plugins do have an option to serve content using PHP, but Wordfence will normally run during those hits as well.
If there isn’t a cached page available for a visitor’s request, then PHP runs including the Wordfence firewall, so firewall rules can be applied to block malicious hits, if necessary.
-Matt R, Wordfence QA Lead
Hi @giuse,
I work for Wordfence — if you are using a plugin that disables entire plugins selectively, I would not recommend disabling Wordfence on any pages. The firewall can block various kinds of attacks that can occur on regular pageloads, including viewing posts/pages, the home page, and so on, and if it is disabled, it cannot provide protection. Some plugins may also expose login functionality on pages other than the login page, so login-related features may be necessary on regular pageloads as well.
If you are talking about only CSS or Javascript, Wordfence only loads these files on pages where they may be necessary. Some Javascript and CSS loads only for admins, which you might see on the front end of the site while logged in as an admin, but they should not load for regular visitors. Depending on which features you are using, there may be some Wordfence CSS and Javascript on the login page for all users, which is necessary for those features to work.
@generosus : The suggestions you made may work for you, but this can prevent some necessary styles or scripts from loading, for example, if there is an admin notice because of a configuration problem, or if a false positive block occurs and the admin needs to add it to the allowlist. Please don’t suggest changes that may break functionality for other users.
-Matt R, Wordfence QA Lead
Thanks for the additional details. The point where it stopped could be caused by a plugin that hooks into WordPress’s updater incorrectly, so when Wordfence tries to check the status of other plugins (using a WP core function), that plugin’s code can cause a failure — we’ve seen that sometimes for plugins that are not from ww.wp.xz.cn, when they try to provide an update mechanism of their own.
I don’t know of any that currently have this problem, but there are a couple ways to narrow it down:
1. Try temporarily disabling the option “Scan for out of date, abandoned, and vulnerable plugins, themes, and WordPress versions” on the Scan Options page, and then run another scan.
2. If the scan runs successfully, try temporarily disabling other plugins (if you can do so safely, or if you have a test site on the same platform) and turn the option back on, and try a scan again — then if it’s still successful, enable the other plugins one-by-one to see which one causes the failure. If you know that you have plugins that aren’t from ww.wp.xz.cn, I’d recommend testing those first.
I would normally also recommend checking PHP’s error logs, but if there was no other error message in Wordfence’s scan log aside from the one in your first message, there may not be anything in the error log either. It may be worth checking, if you can though.
There is also a small chance that your host has different configuration in php.ini for different PHP versions — sometimes this can cause the site to run out of memory on one PHP version, while it doesn’t on another version. This also could show up in the PHP error logs.
Let me know if this helps, and if you can tell which plugin causes it, if that’s the case.
-Matt R
Hi @imc67,
I work at Wordfence and can confirm that the “Requests_Cookie_Jar” message you’re seeing is from WordPress core, and it’s triggered during Wordfence scans because we use the affected part of WP core. WP core has a trac ticket open to fix it, since it is a PHP 8.0 compatibility issue on their side. It’s not an issue we can fix in another release like generosus thought.
WordPress core itself still doesn’t fully support PHP 8.0 or greater. They describe it as “beta support” here: https://make.ww.wp.xz.cn/core/handbook/references/php-compatibility-and-wordpress-versions/
Though, we’ve found that WordPress itself generally does work fine on PHP 8.0, but there can be issues in core triggered by plugins or themes. Some of those are things that WP core will need to fix, though some could also be fixed in the plugins/themes that trigger them. We do run WordPress and Wordfence on test sites with PHP 8.1 and 8.2 (which is officially due to be released soon).
So back the scan issue you’re having — there is probably another cause, unrelated to the deprecation message shown in the log. If you’re able to switch to an earlier PHP version temporarily, that would confirm if it’s a PHP version issue or not.
Also, just to clarify — when you said “at the end of a scan”, do you mean the scan does complete, but just shows that message afterward? If the scan doesn’t actually complete, can you copy the last 20 lines or so from the log on the Scan page once a scan stops and paste them in the post? (Click the “Show Log” link on the right of the page, if you don’t see the log above the results section.)
-Matt R
Wordfence QA LeadHi Andis,
The
wordfence_security_eventhook is not a documented API. Internally, we don’t treat that IP address as an attacking IP. You can still use this hook of course, but may have to select which events your mu-plugin processes. Keep in mind that this hook is intended to be used internally within the plugin, and parameters or types of events may change in future versions of the plugin.The
@operator is still not deprecated in modern PHP versions, though we do generally avoid it in newer code, and we do refactor older code when working on changes or new features, or when compatibility issues occur in new PHP beta versions. WordPress itself still uses it in several files like wp-includes/functions.php, wp-includes/formatting.php, wp-includes/rest-api/endpoints/class-wp-rest-attachments-controller.php, and others.Note that Wordfence still supports rather old versions of PHP still because multiple vendors still “backport” security fixes to old PHP versions, and quite a few sites are still using them. Refactoring old code that still works as intended isn’t necessarily helpful to users, and requires significant additional testing on many old PHP and WordPress versions that are still supported, but over time the bulk of it will be refactored, especially as we drop support for some older PHP versions.
-Matt R
Forum: Plugins
In reply to: [a3 Lazy Load] Security Vulnerablity@a3rev: Sorry for the trouble — we got your message overnight for most of our team. We’ll be back in touch via email.
-Matt R