Scan Failed – The current scan looks like it has failed

Thanks for pointing me in the right direction. I’d never have considered this as the source of the problem, since all of the sites in question already had Wordfence no-abort instructions in their .htaccess files, but apparently either you or the hosts (this occurred on at least two different hosts) changed something recently, because this no longer works:

# Wordfence WAF
<IfModule LiteSpeed>
php_value auto_prepend_file '/home/xxx/public_html/wordfence-waf.php'
</IfModule>
<IfModule lsapi_module>
php_value auto_prepend_file '/home/xxx/public_html/wordfence-waf.php'
</IfModule>
<Files ".user.ini">
<IfModule mod_authz_core.c>
	Require all denied
</IfModule>
<IfModule !mod_authz_core.c>
	Order deny,allow
	Deny from all
</IfModule>
</Files>

# END Wordfence WAF

I replaced it with this, which resolved the issue in every case:

# BEGIN LiteSpeed noabort
<IfModule rewrite_module>
RewriteEngine On
RewriteRule .* - [E=noabort:1]
</IfModule>
# END liteSpeed noabort

But I have to wonder how many other sites now have scans not completing (or site admins pulling their hair out) due to this change. If it was on your end, maybe you should let people know they need to update .htaccess on older sites that may have this older code.

Also, I wonder if you can explain the relationship (if any) between the .htaccess mods and the “Bypass the LiteSpeed “noabort” check” setting in the Wordfence options? Most (though not all) of these sites did have that option enabled, but obviously the host was checking anyway, or it wouldn’t matter what was in .htaccess, right? Or am I missing something? Both hosts have previously confirmed that the that the “External Application Abort” function is set to “No Abort,” though I haven’t re-checked that recently.

Ah, OK, the “Bypass the LiteSpeed “noabort” check” setting only pertains to whether or not it auto updates, and not to scans, is that right?

And the entries I deleted ONLY pertained to .htaccess entries for firewall optimization and to hide the .user.ini file, and not to scans, is that also right? So the problem was not the presence of those entries, but the absence of the no-abort entries I added? Which is puzzling, as I manage many sites on one of the hosts, all of which were completing scans just fine until about two months ago, and this issue has only affected some of them. Even where there is a root domain site and a subdomain or add-on domain site, one has been affected and the other has not.

You were right, I did need to re-optimize the firewalls. I compared the .htaccess backup before I did that with the file after optimization and see it put back exactly what I removed. I’ll check with the hosts and see if they changed the no-abort settings.

They said they have not changed anything (even sent me a screenshot of the settings). It’s a reputable host I’ve worked with for years, and this came straight from the owner. Puzzling.