Cybersecurity experts have uncovered yet another significant security weakness in the LiteSpeed Cache plugin for WordPress that might enable unauthenticated users to take control of random accounts.
The vulnerability, identified as CVE-2024-44000 (CVSS score: 7.5), effects versions before and including 6.4.1. It has been addressed in version 6.5.0.1.
"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.
The finding follows an exhaustive security investigation of the plugin, which previously led to the revelation of a significant privilege escalation problem (CVE-2024-28000, CVSS score: 9.8). LiteSpeed Cache is a prominent caching plugin for the WordPress environment with over 5 million active installs.
The new vulnerability derives from the fact that a debug log file titled "/wp-content/debug.log" is publicly accessible, which makes it easy for unauthenticated attackers to see potentially sensitive information contained in the file.
This might also include user cookie information stored inside HTTP response headers, essentially enabling users to log in to a vulnerable site with any session that is currently valid.
The reduced severity of the problem is attributable to the need that the debug functionality must be enabled on a WordPress site for it to be successful. Alternatively, it might potentially impact sites that have engaged the debug log functionality at some time in the past, but have neglected to erase the debug file.
It's vital to remember that this functionality is deactivated by default. The patch fixes the issue by relocating the log file to a dedicated folder inside the LiteSpeed plugin folder ("/wp-content/litespeed/debug/"), randomizing filenames, and eliminating the option to log cookies in the file.
Users are recommended to verify their installations for the existence of the "/wp-content/debug.log" and take measures to remove them if the debugging functionality has (or has) been activated.
It's also advisable to establish a .htaccess rule to restrict direct access to the log files since bad actors may still directly access the new log file if they know the new filename by way of a trial-and-error technique.
"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 added.