Earlier today someone posted on the support forum for the 200,000+ active install WordPress plugin Activity Log with the subject “Critical Exploit: Disable plugin Immediately!” and wrote this:

As reposted by CISA and NIST, NVD this plugin has a critical exploit, CVE-2022-3941, and we are removing from all of our servers pending revision and reporting from the makers.

See: https://nvd.nist.gov/vuln/detail/CVE-2022-3941

We do love this plugin and hope to be able to reinstall it soon on user sites.

The source of the information isn’t any of the mentioned entities, but VulDB. We wrote about VulDB’s false claim of a vulnerability in a WordPress plugin a couple of weeks ago, so they are not what we would call a reliable source of information.

In VulDB’s information they claim the vulnerability is classified as “critical”, but don’t explain by who, and claim it “leads to a privilege escalation vulnerability”:

A vulnerability has been found in Activity Log Plugin on WordPress (WordPress Plugin) (the affected version is unknown) and classified as critical. This vulnerability affects an unknown code of the component HTTP Header Handler. The manipulation of the argument X-Forwarded-For with an unknown input leads to a privilege escalation vulnerability. The CWE definition for the vulnerability is CWE-117. The software does not neutralize or incorrectly neutralizes output that is written to logs. As an impact it is known to affect integrity.

The only evidence for that are two screenshots hosted on Google Drive:

The weakness was presented 11/11/2022. The advisory is shared for download at drive.google.com. This vulnerability was named CVE-2022-3941. Technical details and also a public exploit are known.

It is declared as proof-of-concept. It is possible to download the exploit at drive.google.com.

What they seem to show is that someone could cause Activity Log to record the wrong IP address for a logged action. That alone wouldn’t allow privilege escalation and wouldn’t really be a vulnerability. If you could include malicious JavaScript code in the value recorded for the IP address, that would be a fairly serious issue here. But can you?

VulDB doesn’t provide basic details like the relevant code, even though it isn’t hard to find where that is. The relevant code is located in the function _get_ip_address(), which is in the file /classes/class-aal-api.php:

34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55

protected function _get_ip_address() {
	$server_ip_keys = array(
		'HTTP_CF_CONNECTING_IP', // CloudFlare
		'HTTP_TRUE_CLIENT_IP', // CloudFlare Enterprise header
		'HTTP_CLIENT_IP',
		'HTTP_X_FORWARDED_FOR',
		'HTTP_X_FORWARDED',
		'HTTP_X_CLUSTER_CLIENT_IP',
		'HTTP_FORWARDED_FOR',
		'HTTP_FORWARDED',
		'REMOTE_ADDR',
	);
 
	foreach ( $server_ip_keys as $key ) {
		if ( isset( $_SERVER[ $key ] ) && filter_var( $_SERVER[ $key ], FILTER_VALIDATE_IP ) ) {
			return $_SERVER[ $key ];
		}
	}
 
	// Fallback local ip.
	return '127.0.0.1';
}

That restricts the value being passed to a valid IP address.

What is at issue is that code allows a user to specify the IP address that request will be seen from by default. What would be better is to only rely instead on information from a header that has been specified by the plugin’s settings in a situation where that is relevant. If, say, someone is running the website through CloudFlare or some other intermediary.

We would have notified the developer of that, but they don’t provide a contact mechanism on their website.