Today, we had a hacker try to exploit a vulnerability recently fixed in the WordPress plugin WP Compress on our website. In looking into that, we found another instance where it looks like hackers are relying on information coming from WordPress security providers to determine what vulnerabilities to target.

In the logging for our own firewall plugin, it showed an attack blocked for this URL, /wp-content/plugins/wp-compress-image-optimizer/fixCss.php?css=wp-content/../wp-config.php:

That would appear to be an attempt to exploit a vulnerability that would allow an attacker to view the contents of an arbitrary file. In this attempt, to view the contents of the WordPress configuration file.

Pulling up our data on this plugin, we saw that the changelog for a version released on December 13, was supposed to have fixed a security issue, as it reads “Security Patch Release,” As none of our customer of our main service are using the plugin, we hadn’t reviewed that claim so far. Looking at the changes made in that version, we found that it added code to the file being targeted by the hacker, fixCss.php, and that the code restricts this type of vulnerability from being possible.

The code restricts the type of files that can be viewed to those with the .css extension:

32
33
34
35
36
37
38
39
40
41
42
43
44
45

// Info about file
$path = parse_url($cssUrl, PHP_URL_PATH);
 
// Get the filename and extension using pathinfo
$fileInfo = pathinfo($path);
 
// Extract filename and extension
$extension = $fileInfo['extension'];
 
// File extension is not css or not found
if (!$extension || $extension !== 'css') {
  header('Location: ' . $cssUrl, 302);
  die();
}

That fix addresses what the hacker was trying to exploit.

It’s a good reminder to keep your plugins up to date.

What makes this situation more notable is the timing of the attack. It comes 23 days after the vulnerability was fixed, which would be a long time for a hacker to get around to exploiting this if they learned about the vulnerability from the changelog and looking at the changes made. It is even longer since the vulnerability was introduced, as it was introduced in a version released in November 2022.

So what looks to explain the interest now? Two of our competitors in providing data on vulnerabilities in WordPress plugins, Wordfence and WPScan, listed this vulnerability in their data two days ago. It’s unclear what the original source for that is, since a CVE ID, CVE-2023-6699, record is being cited, but that doesn’t contain any details. Instead, it says, “This record will be updated by the assigning CNA once details are available.” This week we suggested to CVE that they provide a feature to report when CVE records are not being populated like this. Hopefully, they quickly introduce that to better address situations like this.

Which Other Firewall Plugins Protected Like Ours?

Looking back at the screenshot of the logging of the attack, the attack was blocked by our firewall plugin because the name of the WordPress configuration file, wp-config.php, was included in the URL of the request. We checked with our automated testing system for firewall plugins to see which other firewall plugins would also stop this attack in the same way. It turned out only four did. Those are BBQ Firewall, NinjaFirewall, SecuPress, and Web Application Firewall.

This attack could be stopped by detecting directory traversal, so other plugins may also provide protection through that.

Plugin Security Scorecard Grade for WPScan

See issues causing the plugin to get less than A+ grade