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

depicter3.6.1 → 3.6.2✓ COMPLETED

Files85

Vulnerable17

True positives0

CVE matched1

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

CVE-2025-2011

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 85 CVE 1 Vuln 17

SORT

1 files · page 1/1

app/src/Controllers/Ajax/LeadsAjaxController.php

AI: 1 vulnerabilities

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') CVE-2025-2011

#%!d(float64=002)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-2011

Security writeup for CVE-2025-2011

✓ 1 FILE

## The Exploit

An unauthenticated attacker can inject arbitrary SQL via the `s` parameter in the LeadsAjaxController AJAX endpoints. The parameter is passed directly into database queries after being sanitized with `textfield()` instead of SQL-specific escaping, allowing an attacker to break out of the query context and extract data.

```http
GET /wp-admin/admin-ajax.php?action=depicter_leads_list&s=test' UNION SELECT 1,2,3,4,5,user_login,user_pass FROM wp_users WHERE '1'='1 HTTP/1.1
Host: target.wordpress.local
```

The attacker observes the injected SQL executes within the application's database query context. The response will contain database results from the UNION clause, leaking WordPress user credentials. Alternatively, time-based blind SQL injection (`SLEEP(5)`) confirms exploitability through response delay observation, bypassing any output filtering.

## What the Patch Did

**Before**
```php
's'         => Sanitize::textfield($request->query('s', '')),
```

**After**
```php
's'         => Sanitize::sql($request->query('s', '')),
```

The patch replaces the generic `textfield()` sanitizer with `sql()` across three methods in LeadsAjaxController: `index()`, `list()`, and `export()`. The `textfield()` method removes HTML tags and performs basic text sanitization but does not escape SQL metacharacters like single quotes, double dashes, or semicolons. The `sql()` method applies proper SQL parameterization or character escaping that prevents the injected string from being interpreted as SQL syntax. This is a **input filter change** — the request parameter value is now escaped at the trust boundary between user input and the database query layer.

## Root Cause

**CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')**

The `s` query parameter enters the request unvalidated and reaches the LeadsAjaxController via `$request->query('s', '')`. The value is then passed to `Sanitize::textfield()`, which is insufficient because it was designed for HTML context (stripping tags) rather than SQL context. The sanitized value flows directly into SQL query construction in the `index()`, `list()`, and `export()` methods without parameterized queries or SQL-specific escaping. An attacker crosses the trust boundary — from untrusted user input to trusted database command — without encountering SQL-aware sanitization, allowing arbitrary SQL injection.

## Why It Works

The load-bearing line is the replacement of `textfield()` with `sql()`. If the patch had only changed one of the three occurrences (line 13, 35, or 165), the vulnerability would remain exploitable through the remaining un-patched endpoints. The engineer correctly identified that the `s` parameter is used across all three query methods (`index()`, `list()`, `export()`) and applied the fix consistently. The specific choice of `sql()` over `textfield()` matters because SQL injection requires SQL-aware escaping: a string like `admin' OR '1'='1` is harmless in HTML context but breaks SQL logic. The patch's consistency — fixing the parameter at the point of entry across all three methods rather than attempting to escape it at multiple query sites — follows the principle of defence-in-depth: sanitize once at the trust boundary, rather than hoping every downstream sink is defended.

## Hardening Checklist

- **Use parameterized queries (prepared statements) instead of string concatenation.** Replace all instances of `"WHERE name = '" . $user_input . "'"` with prepared statements using placeholders (`?` or named parameters) and bind the user input separately. This eliminates the need to trust sanitizers.

- **Apply context-aware sanitizers at input boundaries.** Use `Sanitize::sql()` (or equivalent database-specific escaping) for values destined for SQL; use `esc_attr()`, `wp_kses_post()`, or `esc_html()` for output contexts. Never reuse `textfield()` for SQL contexts.

- **Audit all AJAX endpoints for direct database access.** Use `grep -r "admin-ajax.php"` and `grep -r "wp_db->prepare"` to enumerate handlers; verify that every database query is either parameterized or applies SQL-specific escaping at the entry point.

- **Introduce automated static analysis for SQL injection patterns.** Integrate a linter that flags instances of `->query()` or `->get_results()` preceded by string concatenation (e.g., no `$wpdb->prepare()`). Tools like PHPStan with security rules can catch this at CI time.

- **Require code review sign-off for changes touching query construction.** Establish a policy that any modification to SQL query building or parameter sanitization requires explicit review by a security-aware maintainer, not just a peer review.

## References

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

CVE CVE-2025-2011

PRODUCT depicter

AFFECTED ≤ 3.6.1

FIXED IN 3.6.2

STATUS Generated

Security writeup · CVE-2025-2011

Source files · 1

app/src/Controllers/Ajax/LeadsAjaxController.php Linked

↗ NVD