Wordfence for WordPress expands LiteSpeed's noabort exception site-wide because its own architecture cannot isolate the requests that need it

[serpent_driver]

This post is based on an discussion on Reddit: You should read the comments to better understand what this post is about:

https://www.reddit.com/r/Wordpress/comments/1vv46qb
I recently raised an issue concerning Wordfence for WordPress and the way it handles LiteSpeed's noabort directive. The original issue is fairly simple. Wordfence recommends adding the following rule to the site's .htaccess file on LiteSpeed servers:

RewriteRule .* - [E=noabort:1]

or alternatively:

SetEnv noabort 1

The important part is not that Wordfence needs noabort. There are perfectly legitimate reasons why a long-running PHP process may need to survive after the client connection that started it has disappeared. The important part is the scope.

.* // does not make an exception for Wordfence.

It makes the exception applicable site-wide. Every matching PHP request can inherit noabort, regardless of whether that PHP execution has anything whatsoever to do with Wordfence.

What LiteSpeed says noabort is for

According to LiteSpeed's own documentation, when a client closes a connection, LSWS normally aborts the associated PHP process. LiteSpeed explains why it does this: to avoid wasting server resources and to help prevent certain types of denial-of-service attacks.noabort provides an exception to that normal behavior for scripts that genuinely must continue running. The current LiteSpeed documentation could hardly be clearer about the intended scope:

A specific script URL should be used instead of .*.

LiteSpeed explicitly warns against enabling noabort for all requests and recommends using it selectively and only when absolutely necessary. The documentation even gives a concrete shared-hosting-related example: if a CloudLinux LVE reaches its resource limits while all external application requests are protected by noabort, the account can become completely tied up because LSWS is no longer able to abort those requests.

Where Wordfence enters the picture

I initially assumed that Wordfence could simply restrict noabort to the identifiable request used by its scanner. That assumption turned out to be incomplete. Mark Maunder, founder and CEO of Wordfence, responded publicly to the issue and explained that Wordfence needs noabort not only for scans, but also for WAF maintenance, attack-data processing, scheduled jobs, automatic updates and other tasks. Some of this work may happen before WordPress itself is loaded and may be triggered during different requests.

His most important statement, in my opinion, was this:

“Narrowing Wordfence’s rule would require architectural changes to move all pre-WordPress WAF maintenance to a dedicated execution path.”

That clarification changes the discussion significantly. It means that Wordfence does not recommend a global noabort rule because LiteSpeed technically requires Wordfence to apply it globally. Wordfence recommends it globally because Wordfence's current architecture cannot sufficiently isolate all execution paths that may perform Wordfence background work.

That distinction matters.

Is this really a LiteSpeed problem?

Wordfence's documentation presents the issue primarily as a LiteSpeed compatibility problem. It states that LiteSpeed has been known to kill or stop processes that take more than a few seconds to run and describes the noabort rule as the necessary fix. The Wordfence CEO also characterized Wordfence as not being unusual in requiring LiteSpeed-specific handling and referenced several other applications that use noabort.

But this framing deserves closer examination. LiteSpeed is not arbitrarily killing Wordfence because LiteSpeed has some unusual problem with long-running PHP applications. The server is managing the lifetime of external application processes and client connections.

Every hosting environment has to manage finite resources somehow: PHP workers, processes, CPU, memory, execution time and connections cannot be unlimited, particularly on shared hosting. LiteSpeed's ability to stop work associated with a disconnected client is part of that resource-management model. noabort exists to make an exception where the application genuinely requires one. The existence of an exception does not make LiteSpeed responsible when an application cannot determine narrowly enough where it needs that exception.

“Other applications do it too” does not resolve the issue

Wordfence also referred to UpdraftPlus and WP STAGING, which recommend broad noabort rules, while pointing out that BackupBuddy/Solid Backups and Duplicator Pro use scoped approaches. I find this comparison particularly interesting. If other applications also apply noabort globally because their execution architecture cannot isolate their long-running work, that does not demonstrate that global noabort is correct. It demonstrates that the same question may apply to those applications as well. And some of the examples provided by Wordfence actually prove that scoping such exceptions is possible.

The question therefore is not: “Does any other WordPress plugin also do this?”

The question is: Is this what LiteSpeed designed noabort to be used for?

Shared hosting makes this more important, not less

Wordfence has to support an enormous variety of WordPress installations, including inexpensive shared hosting. I understand why Wordfence cannot require every customer to have shell access, a persistent worker, system cron or complete server control. But shared hosting is precisely where global resource exceptions should be treated most carefully. Shared-hosting environments deliberately impose process, CPU, memory and concurrency limits because one application must not be allowed to consume resources indefinitely. If Wordfence needs a process-lifecycle exception for its own work, that exception should ideally belong to Wordfence.

It should not automatically become an exception for:

• another plugin,
• a theme,
• an unrelated PHP endpoint,
• a bot-triggered request,
• buggy PHP code,
• or PHP execution that becomes exploitable after a vulnerability is discovered.

noabort does not create those vulnerabilities. But a global noabort rule can remove one layer of containment that would otherwise limit their consequences after the initiating connection has disappeared. That is relevant to security because security is not limited to preventing unauthorized access. Availability and damage containment are also part of security.

This is why the Wordfence CEO's explanation concerns me

The response from Wordfence explains why Wordfence currently needs the broad exception. But I do not think that explanation justifies transferring the consequences of that architectural requirement to every unrelated PHP request on the site. If a security product cannot identify all of its own long-running execution paths, there are several possible architectural responses:

Create dedicated execution paths. Use dedicated workers where the hosting environment permits them. Use WordPress cron or another identifiable mechanism where appropriate. Limit functionality where the required hosting capabilities do not exist. Or redesign the relevant background processing. What I find difficult to accept is the alternative currently used:

Because Wordfence cannot reliably isolate all requests that may perform Wordfence work, LiteSpeed is instructed not to abort unrelated PHP processes either.

That reverses the responsibility. The application's architectural limitation becomes a site-wide change in web-server behavior. And this is particularly difficult to reconcile with a security product, because a security product should normally follow the principle of granting exceptions as narrowly as possible.

My questions to LiteSpeed

I am therefore not asking LiteSpeed to judge Wordfence as a product. I am asking LiteSpeed to clarify the intended use of LiteSpeed's own server controls.

1. Is RewriteRule .* - [E=noabort:1] considered an appropriate configuration for a normal WordPress application?

Or should noabort normally remain restricted to the specific scripts, URLs or request conditions that genuinely require it?

2. Is Wordfence correct to frame this primarily as “LiteSpeed-specific handling”?

Or is LiteSpeed simply enforcing normal resource and process-lifecycle behavior, which Wordfence's architecture then needs to override?

3. If an application cannot identify which of its requests require noabort, is extending the exception to every request an intended use of the directive?

Or should the application architecture provide an execution path that can be scoped?

4. Does applying noabort site-wide reduce LiteSpeed's ability to contain unrelated PHP execution after client disconnects and therefore potentially affect availability under resource exhaustion or abusive request scenarios?

5. Would LiteSpeed recommend that application developers treat noabort and noconntimeout according to a least-scope principle: only for the requests that demonstrably require those exceptions?

I think an official clarification would be useful not only for Wordfence users. Wordfence's CEO specifically pointed out that other WordPress applications use similar configurations. If that is true, then this is no longer merely a Wordfence compatibility issue. It becomes a broader question of whether LiteSpeed's request-level exceptions are being used as intended, or whether application developers are increasingly using them site-wide to accommodate architectural requirements that should remain inside the application.

That is a distinction I believe LiteSpeed should make explicit.

 

[abk]

All I can respond to this is what our documentation already answers: noabort should normally be scoped to the specific script or URL that needs it, not applied with .*. That guidance hasn't changed: https://docs.litespeedtech.com/lsws/cp/cpanel/long-run-script/

Beyond that - what LiteSpeed can do is document how to make a long-running script run properly on LSWS, and we do that. What we can't do is decide, on someone else's server, whether that exception should be site-wide or scoped. That call belongs to the hosting provider or site admin depending on their specific use case - they know their limits, their tenants and their risk tolerance.

 

[serpent_driver]

Thanks, and I agree with your answer. I am not asking LiteSpeed to decide how another administrator should configure their server. Your documentation is already clear that noabort should normally be scoped to the script or URL that actually requires it.

There is just one point I think is important to add, because it is the reason I raised this issue in the first place.

Wordfence and some other application vendors frame this as a LiteSpeed-specific problem that requires special handling on LiteSpeed servers. In Wordfence's case, the recommended solution is then a site-wide noabort rule.

That framing shifts the responsibility in a way I believe is misleading.

LiteSpeed is not creating the underlying problem. LiteSpeed is doing what a web server and hosting environment is expected to do: manage finite resources, terminate work that no longer needs to continue, and protect availability.

noabort is the exception LiteSpeed provides for applications that genuinely need a process to continue.

If an application cannot identify the specific requests that require that exception and therefore applies it globally, that is an architectural limitation of the application — not a limitation of LiteSpeed.

This distinction became particularly clear in the Wordfence discussion, where the Wordfence CEO explained that narrowing the rule would require architectural changes because Wordfence maintenance can occur during different request paths.

In other words, the global rule is not required because LiteSpeed forces applications to use noabort globally. It is required because Wordfence currently cannot scope all of its own work narrowly enough.

I think that distinction is important for LiteSpeed users to understand, because otherwise they are left with the impression that LiteSpeed itself is responsible for the workaround.

Your documentation already makes the technical position clear: noabort should normally be scoped. My point is simply that application vendors should not turn their inability to scope the exception into a supposed LiteSpeed compatibility problem.

 

[abk]

Thanks for the follow-up. As noted above, our documentation covers the technical guidance on scoping noabort, and how it's applied on a given server is up to the host or site admin. We're not in a position to comment on the architecture or recommendations of third-party applications. Appreciate the discussion.