Critical Security Flaw Found in LiteSpeed Cache Plugin for WordPress

Researchers studying cybersecurity have uncovered yet another serious security hole in the WordPress plugin LiteSpeed Cache that might let unauthorized users take over any account.

The issue affects versions prior to and including 6.4.1 and is listed as CVE-2024-44000 (CVSS score: 7.5). Version 6.5.0.1 has been updated to resolve this.

“The plugin suffers from an unauthenticated account takeover vulnerability which allows any unauthenticated visitor to gain authentication access to any logged-in users and at worst can gain access to an Administrator level role after which malicious plugins could be uploaded and installed,” Patchstack researcher Rafie Muhammad said.

This finding comes after a thorough security investigation of the plugin that earlier revealed a serious vulnerability allowing for the escalation of privileges (CVE-2024-28000, CVSS score: 9.8). A well-liked caching plugin for the WordPress environment, LiteSpeed Cache has more than 5 million active installations.

A publicly accessible debug log file called “/wp-content/debug.log” is the source of the new vulnerability. This allows unauthenticated attackers to examine potentially sensitive data stored in the file.

This might also include user cookie data that is contained in HTTP response headers, which would essentially enable users to access a vulnerable website using any active session.

The requirement that the debug feature be enabled on a WordPress site in order for it to function properly accounts for the reduced severity of the problem. As an alternative, it might also impact websites that have previously enabled the debug log option but neglected to delete the debug file.

It is noteworthy that this option is by default turned off. In order to fix the issue, the log file is moved to a special folder (“/wp-content/litespeed/debug/”) inside the LiteSpeed plugin folder, filenames are randomly generated, and the option to log cookies in the file is removed.

It is recommended that users look for the “/wp-content/debug.log” file in their installations and remove it if the debugging feature is (or was) active.

Malicious actors can still access the new log file directly if they know the new filename through a trial-and-error technique, so it’s also advised to implement a.htaccess rule to prevent direct access to the log files.

“This vulnerability highlights the critical importance of ensuring the security of performing a debug log process, what data should not be logged, and how the debug log file is managed,” Muhammad said.