ANALYSIS · fbfd9f7d· FINISHED 2026-06-13 · PATCHDIFF

tenweb-speed-optimizer2.32.7 → 2.32.11✓ COMPLETED

Files8

Vulnerable2

True positives0

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2025-13377

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 8 CVE 2 Vuln 2

SORT

2 files · page 1/1

includes/WebPageCache/OptimizerWebPageCache.php

AI: 2 vulnerabilities

CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')CWE-20: Improper Input Validation CVE-2025-13377

#%!d(float64=002)

includes/WebPageCache/OptimizerWebPageCacheWP.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2025-13377

#%!d(float64=003)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2025-13377

Security writeup for CVE-2025-13377

✓ 2 FILES

## The Exploit

An authenticated WordPress user with Subscriber role or higher can delete arbitrary directories on the server by calling the cache-clearing endpoint with a crafted `permalink` parameter containing directory traversal sequences.

```http
GET /wp-admin/admin-ajax.php?action=two_clear_page_cache&permalink=../../&_wpnonce=<valid_nonce> HTTP/1.1
Host: target.example.com
Cookie: wordpress_logged_in=<subscriber_session>
```

The attacker observes a successful cache deletion response (HTTP 200) or silence. Within seconds, the server's non-cache directories begin vanishing — WordPress configuration files, plugin directories, or application data outside `wp-content/cache` cease to exist. A recursive deletion operation consumes the filesystem traversal, and by the time logs surface anomalies, critical application state is gone.

## What the Patch Did

**Before:**

```php
public static function delete_page_cache($dir, $is_home_url)
{
    if (is_dir($dir)) {
        foreach (scandir($dir) as $file) {
            if ($file === '.' || $file === '..') {
                continue;
            }

$path = $dir . $file;

if (is_file($path)) {
                unlink($path); // phpcs:ignore
            } else {
```

**After:**

```php
public static function delete_page_cache($dir, $is_home_url)
{
    // Validate directory path before deletion
    if (empty($dir)) {
        return;
    }

// Ensure the directory is within the allowed cache directory
    $real_dir = realpath($dir);
    $real_allowed_dir = realpath(TENWEB_SO_PAGE_CACHE_DIR);

if ($real_dir === false || $real_allowed_dir === false) {
        return;
    }

// Prevent directory traversal - ensure path is within cache directory
    if (strpos($real_dir, $real_allowed_dir) !== 0) {
        return;
    }

if (is_dir($dir)) {
        foreach (scandir($dir) as $file) {
            if ($file === '.' || $file === '..') {
                continue;
            }

$path = $dir . $file;

// Additional safety check for each path
            $real_path = realpath($path);

if ($real_path === false || strpos($real_path, $real_allowed_dir) !== 0) {
                continue;
            }

if (is_file($path)) {
                unlink($path); // phpcs:ignore
```

The patch introduces `realpath()` normalization and prefix validation using `strpos()`. The load-bearing security control is the comparison `strpos($real_dir, $real_allowed_dir) !== 0` — this enforces that the resolved canonical path begins with the allowed cache directory constant `TENWEB_SO_PAGE_CACHE_DIR`. Without this check, `../../sensitive_directory` resolves to an absolute path outside the cache root, and deletion proceeds unrestricted.

The patch also hardens the AJAX handler in `OptimizerWebPageCacheWP.php` by adding explicit capability checks (`current_user_can('manage_options')`), correct nonce verification with proper parameter passing to `wp_verify_nonce()`, and a new `validate_cache_path()` function that re-enforces the prefix check before any deletion is triggered.

## Root Cause

**CWE-22 (Path Traversal)** and **CWE-20 (Improper Input Validation)** converge here. The attacker controls the `permalink` GET parameter in the AJAX request. This value flows into `OptimizerWebPageCache::delete_cache_by_url($permalink)`, which calls `get_cache_dir_for_page_from_url($url)` without validating that the returned `$dir` stays within the cache directory. The function `wp_parse_url()` extracts the host and path from the URL, but hostile paths like `../../wp-config.php` are never checked for directory traversal patterns. The `$dir` value lands directly in `delete_page_cache($dir, ...)`, where `scandir()` and `unlink()` operate on it recursively without boundary enforcement.

The missing trust boundary is between user input (`$_GET['permalink']`) and the filesystem operation (`unlink($path)`). Early versions of the code assumed that URL parsing would implicitly constrain the output, but URL parsing only extracts components — it does not reject `../` sequences.

## Why It Works

The line `if (strpos($real_dir, $real_allowed_dir) !== 0) { return; }` is load-bearing. If removed, an attacker's `../../` path still resolves via `realpath()` to an absolute path (e.g., `/var/www/html`), and without the prefix check, that path is accepted and deleted. The surrounding lines exist for defense-in-depth: `realpath()` resolves symlinks and normalizes `.` and `..` sequences into their true targets, preventing obfuscation tricks. The `=== false` guards on `realpath()` catch non-existent or inaccessible paths early, reducing the surface for edge cases. The per-file validation `strpos($real_path, $real_allowed_dir) !== 0` inside the loop catches any files an attacker might have created outside the cache directory via symlinks or race conditions. Together, these layers ensure that no deletion escapes the intended root.

## Hardening Checklist

- **Use `realpath()` + prefix matching for all path-based operations.** Normalize any user-influenced filesystem path with `realpath()`, then enforce that it begins with an allowed root directory using `strpos()` or `str_starts_with()` (PHP 8+). Apply this rule at every recursion level or function boundary that touches the filesystem.

- **Verify capabilities before AJAX actions that modify state.** Call `current_user_can('manage_options')` or a custom capability early in any AJAX handler that deletes, creates, or modifies files. Do not rely on role names; use `current_user_can()` with explicit capability checks.

- **Validate nonce parameters correctly.** Extract the nonce from `$_GET`, `$_POST`, or `$_REQUEST` with `sanitize_text_field()`, then pass it to `wp_verify_nonce($nonce, 'action_name')` and check the return value strictly (`if (!wp_verify_nonce(...)) { wp_die(...); }`). The old pattern `!== null` is insufficient and masks failures.

- **Reject dangerous URL patterns before passing to filesystem logic.** Before a user-supplied URL reaches `get_cache_dir_for_page_from_url()`, validate that it does not contain encoded traversal sequences (`%2e%2e`, `%252f`) or literal ones (`..`, `..\\`). Implement a dedicated allowlist or denylist function like `is_url_safe_for_cache_clear()` that rejects these patterns outright.

- **Validate component extraction results.** After `wp_parse_url()` or similar parsing functions, check that expected keys exist (e.g., `isset($parsed_url['host'], $parsed_url['path'])`) before using them. An empty or missing component can lead to unexpected paths or default fallbacks.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-13377

CVE CVE-2025-13377

PRODUCT tenweb-speed-optimizer

AFFECTED ≤ 2.32.7

FIXED IN 2.32.11

STATUS Generated

Security writeup · CVE-2025-13377

Source files · 2

includes/WebPageCache/OptimizerWebPageCache.php Linked

includes/WebPageCache/OptimizerWebPageCacheWP.php Linked

↗ NVD