Is LiteSpeed Cache vulnerable?

@krashlab we are sorry for the decision you made.
Are you available to tell us more details about your findings? you can catch up with us:

• by creating a ticket sending details on email: support at litespeedtech.com
• joining our slack workspace and contact any Litespeed personal OR write in #wpcache
  
  Thank you and we would gladly talk about the issue with you!

• This reply was modified 4 weeks ago by litetim.

I found for myselft perfect solution.

So, I settled on an incredibly efficient configuration:

1. Installed WP-CLI
2. Installed Redis Server
3. Installed the PHP Redis module
4. Set up rules for LiteSpeed caching in the web server configuration file.

And now everything works like clockwork, everything is laid out on the shelves and I know everything that happens to my cache.

• Redis Server performs the function of an object cache – it caches dynamic requests, database queries, etc.
• LiteSpeed Cache (in-build server, without plugin) performs the function of a static cache – it caches html/css and other content.

Plus, I have Cloudflare connected, which provides network-level caching (Edge Caching) and additional security.

I can see everything and control everything myself. Nothing api, no server load, no malicious queries, no broken layout, no problems.

Thank you for your work.I think your plugin is great, but just not for all configurations. It needs to be tested and improved.

• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.
• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.
• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.
• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.
• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.
• This reply was modified 3 weeks, 6 days ago by KR. Laboratories.

I see your solution.
But did you had a specific example/setup that created cache poisoning. What caused the cache polution? What system you limited?
Is there a setting that you disable and is important to be done?

We have already discussed my settings in previous threads. I can only say that there were no non-standard settings in the plugin. And if there were, I changed them on the advice of qtwrk. And after that, the same thing happened again. One day I went to the site and saw a broken layout. I went to the Chrome Developer console and saw MIME-type errors (this was also described in detail in previous threads). I cleared the LS cache, cleared the CF cache, and then everything returned to normal. But this is not solution.

At first, I thought the problem was with Server Cron, the scheduler was not running, or there was no access to it. But everything is fine here. Then, I checked the cache configuration on the server itself – everything is fine there too. Then I checked Cloudflare, whitelisted access to all the necessary IP addresses. Then everything seemed to suddenly go quiet. And then it happened again.

It’s as if someone who knows about this “hole” is periodically accessing the site and exploiting it. I just assumed that it could be a cache attack. If I had been sure, I would have written a CVE report a long time ago. But this is an assumption. Considering that your plugin already had serious vulnerabilities. There may be a risk of cache manipulation. Also, before that, I noticed a surge in website traffic. Perhaps someone caught up with traffic and overflowed the cache.

The plugin LiteSpeed Cache contains a lot of functionality that hackers can try to exploit. For example, in 2024, at least 10 vulnerabilities of varying degrees were discovered in LS Cache: https://wpscan.com/plugin/litespeed-cache/. And no one knew about it, users only observed various anomalies with the cache. Therefore, I do not dismiss the security problem of your plugin. And I don’t understand how your team of experienced professionals could have allowed such a huge number of vulnerabilities. So where is the guarantee that there is no other hole, no Zero Day?

Unfortunately, I don’t have time to test it now. It’s easier to just remove the WordPress plugin and develop your own solution. No plugin – no problem.

@krashlab Thank you for the details you were able to share about this.

We don’t believe this is a hack. We think the answer to this issue is found somewhere in your Cloudflare and LSCWP settings. Working with multiple caches can easily open you up for conflicts that are not easy to see right away, especially if you are using CF to cache dynamic pages.

And if the issue is indeed due to CF dynamic cache settings, then you haven’t actually solved the problem by uninstalling the plugin. You’re still probably serving from an outdated cache. You just aren’t seeing the symptom anymore because you are no longer generating optimized CSS and JS files (an outdated HTML page that was still referencing the old CSS/JS file names caused the errors, as @qtwrk mentioned in reply to the original thread).

We realize you have decided to stop using the plugin. If you change your mind in the future, we’d be happy to work with you to diagnose the issue.

I don’t have any extraordinary settings in CF… The only thing is that Cloudflare used in High Security mode with access granted to the respective WordPress and LiteSpeed services. The solution I mentioned, Own Redis Server + Own WebServer LS Cache – this is the best solution I’ve come up, because it does not depend on third parties. It is an autonomous system that takes care of the cache, adhering to the Zero Trust Security principle.

I would add that, when hackers hacked LiteSpeed through the CVE-2024-50550 vulnerability, users also thought that it was a problem on their side… Therefore, discussing this is like looking for a needle in a haystack. In my opinion, the LiteSpeed Team just needs to publish comprehensive documentation on their blog about which LiteSpeed WordPress + Cloudflare settings are ideal in terms of avoiding errors.

Best regards, K.R.

It’s not a matter of extraordinary settings. Cloudflare’s dynamic cache is not cleared when LiteSpeed’s cache is cleared (@litetim just verified that this was still true). There is always the risk of the CF cache becoming outdated, whether you use the plugin or not.

Our compatibility doc already states that LSCWP is compatible with CF, only if you’re not using CF APO. I will look into whether there are other places that we should add this warning.

I dont use CF APO.

We can close this discussion. I deleted LiteSpeed Cache WordPress plugin and fix problem.