A critical flaw in the LiteSpeed Cache plugin for WordPress could allow unauthenticated users to take control of arbitrary accounts.
The LiteSpeed Cache plugin is a popular caching plugin for WordPress that accounts for over 5 million active installations. The plugin offers site acceleration through server-level caching and various optimization features.
The LiteSpeed Cache plugin is affected by an unauthenticated account takeover vulnerability, tracked as CVE-2024-44000 (CVSS score: 7.5), that can allow any visitor to gain access to logged-in users and potentially escalate privileges to the Administrator level. An attacker can exploit this vulnerability to upload malicious plugins.
Patchstack researchers explained that the flaw stems from an HTTP response header leak that exposed “Set-Cookie” headers in a debug log file (/wp-content/debug.log) after login attempts.
An unauthenticated attacker can view sensitive information, including user cookie data from HTTP response headers. This could enable attackers to log in using any valid session. The flaw can be exploited only if the WordPress site’s debug feature is enabled and this feature is disabled by default.
“The vulnerability exploits an HTTP response headers leak on the debug log file which also leaks the “Set-Cookie” header after the users perform a login request.” reads the report published by Patchstack. “The main vulnerable code exists on the function ended“
The vulnerability CVE-2024-44000 impacts versions before and including 6.4.1. The issue has been addressed in version 6.5.0.1.
The developers behind the plugin fixed the issue by moving the log file to a dedicated folder within the LiteSpeed plugin folder (“/wp-content/litespeed/debug/”), randomizing filenames, and dropping the option to log cookies in the file.
To improve the security of the debug log feature, the researchers also recommend implementing a proper .htaccess rule that prevents direct access to the log file. Although the LiteSpeed team has already made efforts to address this issue by applying such a rule in a patch, it remains insufficient. Users with knowledge of the log file name can still gain access to it, indicating that the current rule needs further refinement.
Experts also recommend to regularly purge or remove content from the old debug.log file to avoid unauthorized access to previously leaked cookie data contained within the file.
Users are advised to check their installations for the presence of the “/wp-content/debug.log” and take steps to purge them if the debugging feature has (or had) been enabled.
It’s also recommended to set an .htaccess rule to deny direct access to the log files as malicious actors can still directly access the new log file if they know the new filename by means of a trial-and-error method.
“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. In general, we highly do not recommend a plugin or theme to log sensitive data related to authentication into the debug log file.” concludes the report. “We also highly recommend the plugin and theme developer to properly store their debug log data inside of a secure debug log file with a decently random log filename and additional .htaccess rule to block direct access.”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
Pierluigi Paganini
(SecurityAffairs – hacking, LiteSpeed Cache plugin)