ANALYSIS · 05684e90· FINISHED 2026-08-31 · PATCHDIFF

wp-slimstatcache/wp-slimstat_5.3.2 → cache/wp-slimstat_5.3.3✓ COMPLETED

Files5

Vulnerable5

True positives4

CVE matched3

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

CVE-2025-69323

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 5 CVE 3 Vuln 5

SORT

3 files · page 1/1

admin/view/index.php

AI: 1 vulnerabilities

CVE-2025-69323 1 TP

#%!d(float64=001)

admin/view/right-now.php

AI: 1 vulnerabilities

CVE-2025-69323 1 TP

#%!d(float64=002)

admin/view/wp-slimstat-reports.php

AI: 3 vulnerabilities

CVE-2025-69323 1 TP 2 FP

#%!d(float64=004)

1–3 of 3

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-69323

Security writeup for CVE-2025-69323

✓ 3 FILES

## The Exploit

An unauthenticated attacker can inject arbitrary JavaScript into the WordPress admin dashboard by crafting a malicious URL to the plugin's reports page. No authentication or user interaction beyond clicking a link is required.

```http
GET /wp-admin/admin.php?page="><script>alert('XSS via page parameter')</script> HTTP/1.1
Host: target.wordpress.local
User-Agent: Mozilla/5.0
Cookie: wordpress_logged_in=... (admin session)
```

When an authenticated admin visits this link, the injected script executes in their browser within the admin context. The page renders a heading with the unescaped `page` parameter value reflected in the DOM. An attacker observes the JavaScript alert fire, confirming arbitrary code execution. By replacing the alert with a credential-stealing payload or nonce-hijacking code, the attacker can compromise the admin account outright.

---

## What the Patch Did

**Before:**
```php
<h2><?php echo wp_slimstat_admin::$screens_info[$_GET['page']]['title'] ?></h2>
```

**After:**
```php
<h2><?php echo isset($_GET['page']) && isset(wp_slimstat_admin::$screens_info[sanitize_key($_GET['page'])]) ? esc_html(wp_slimstat_admin::$screens_info[sanitize_key($_GET['page'])]['title']) : '' ?></h2>
```

The patch applies three defense layers. First, `isset()` checks guard array access to prevent undefined index warnings. Second, `sanitize_key()` normalizes the `$_GET['page']` parameter to lowercase alphanumeric characters, removing or neutralizing special characters. Third, `esc_html()` escapes the title string before output, converting `<`, `>`, `&`, and quotes to HTML entities so the browser renders them as text, not markup. The load-bearing control is `esc_html()` — without it, `sanitize_key()` alone cannot prevent XSS because the sanitized value is only the array key; the title *value* still flows unescaped to output.

---

## Root Cause

**CWE-79 (Improper Neutralization of Input During Web Page Generation — 'Cross-site Scripting').**

The `$_GET['page']` parameter is user-controlled and unsanitized. The plugin uses this value to index into `wp_slimstat_admin::$screens_info`, retrieves the `title` field, and echoes it directly to the page without escaping. An attacker can inject characters that break out of the HTML context—such as `"><script>alert(1)</script><span x="` —and the browser parser will execute the script. The trust boundary is crossed at the echo statement: attacker input transitions from the request into the response body without neutralization.

---

## Why It Works

The critical line is `esc_html($wp_slimstat_admin::$screens_info[sanitize_key($_GET['page'])]['title'])`. Without `esc_html()`, an attacker's crafted `page` value could still reach the title via legitimate array keys in the plugin's configuration—for example, if the config contains a key like `search" onclick="alert(1)`, the title might already be tainted. `esc_html()` is load-bearing because it guarantees that whatever string emerges from the array is neutralized before rendering. The `sanitize_key()` wrapper serves a secondary purpose: it prevents attackers from probing the plugin's internal structure by injecting exotic characters into the array key lookup. Removing `sanitize_key()` leaves the array access vulnerable to enumeration or bypass tricks. Removing `isset()` checks causes PHP notices that, while not directly exploitable, mask the vulnerability and complicate monitoring. Together, they form defense-in-depth, but only `esc_html()` stops XSS.

---

## Hardening Checklist

- **Use `esc_html()` or context-specific escape functions (`esc_attr()`, `esc_url()`, `wp_json_encode()`) at every output point**, not just one layer. Identify the rendering context—HTML text, attribute value, URL, or JSON—and apply the matching escape.

- **Apply `sanitize_text_field()` or `wp_kses_post()` to user-supplied content at input time**, in addition to output escaping. `sanitize_text_field()` strips tags and harmful entities; `wp_kses_post()` allows safe HTML. Use neither as a substitute for output escaping, but as a complementary check.

- **Validate `$_GET` and `$_POST` parameters against a whitelist of expected values** using `in_array()` or enums when the input is meant to select from a fixed set (e.g., page slugs, report types). This reduces the attack surface before escaping.

- **Audit all array accesses and function calls that receive `$_GET`, `$_POST`, or `$_REQUEST` values**. Use a grep or static analyzer to find patterns like `echo $_GET`, `[$_POST['key']]`, or `function($_GET['param'])`. Each requires validation and escaping.

- **Enforce a Content Security Policy (CSP) header** in the plugin's admin pages (`script-src 'self'`) to mitigate stored and reflected XSS even if escaping is missed. This is a backstop, not a primary control.

---

## References

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

CVE CVE-2025-69323

PRODUCT wp-slimstat

AFFECTED ≤ cache/wp-slimstat_5.3.2

FIXED IN cache/wp-slimstat_5.3.3

STATUS Generated

Security writeup · CVE-2025-69323

Source files · 3

admin/view/index.php Linked

admin/view/right-now.php Linked

admin/view/wp-slimstat-reports.php Linked

↗ NVD