Cybersecurity experts have identified a severe security vulnerability in the LiteSpeed Cache plugin for WordPress, potentially enabling unauthenticated users to seize control of any user account.
Tracked as CVE-2024-44000 (CVSS score: 7.5), this issue affects versions up to and including 6.4.1 and has been resolved in version 6.5.0.1.
“The plugin is vulnerable to unauthenticated account takeover, allowing any unregistered visitor to gain access to any logged-in user’s account. In the worst-case scenario, this could escalate to an Administrator level role, enabling the upload and installation of malicious plugins,” explained Rafie Muhammad, a researcher at Patchstack.
This discovery follows a comprehensive security review of the plugin, which earlier revealed a critical privilege escalation flaw (CVE-2024-28000, CVSS score: 9.8). LiteSpeed Cache is a widely used caching plugin in the WordPress community, boasting over 5 million active installations.
The new vulnerability arises because a debug log file located at “/wp-content/debug.log” is publicly accessible. This exposure allows unauthenticated attackers to view sensitive information within the file, which may include user cookie data from HTTP response headers. Consequently, this could permit attackers to log in to a compromised site using any valid session.
The flaw’s lower severity is attributed to the fact that the debug feature must be enabled on a WordPress site for the exploit to be effective. Alternatively, it could affect sites that had previously activated the debug log feature but neglected to remove the debug file.
By default, the debug feature is disabled. The patch resolves the issue by relocating the log file to a new directory within the LiteSpeed plugin folder (“/wp-content/litespeed/debug/”), randomizing filenames, and eliminating the option to log cookies.
Users are urged to inspect their installations for the presence of the “/wp-content/debug.log” file and remove it if debugging was (or is) enabled.
Additionally, setting an .htaccess rule to block direct access to log files is recommended, as attackers could still access the new log file if they discover the filename through trial and error.
“This vulnerability underscores the critical need for securing the debug logging process, ensuring that sensitive data is not logged, and managing the debug log file effectively,” Muhammad emphasized.
