[ad_1]
Cybersecurity researchers have discovered yet another critical security flaw in the LiteSpeed Cache plugin for WordPress that could allow unauthenticated users to take control of arbitrary accounts.
The vulnerability, tracked as CVE-2024-44000 (CVSS score: 7.5), impacts 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 discovery follows an extensive security analysis of the plugin, which previously led to the identification of a critical privilege escalation flaw (CVE-2024-28000, CVSS score: 9.8). LiteSpeed Cache is a popular caching plugin for the WordPress ecosystem with over 5 million active installations.
The new vulnerability stems from the fact that a debug log file named “/wp-content/debug.log” is publicly exposed, which makes it possible for unauthenticated attackers to view potentially sensitive information contained in the file.
This could also include user cookie information present within HTTP response headers, effectively allowing users to log in to a vulnerable site with any session that is actively valid.
The lower severity of the flaw is owing to the prerequisite that the debug feature must be enabled on a WordPress site for it to be successful. Alternatively, it could also affect sites that had activated the debug log feature at some point in the past, but have failed to remove the debug file.
It’s important to note that this feature is disabled by default. The patch addresses the problem 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.
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,” Muhammad said.
[ad_2]