ANALYSIS · 18b771be· FINISHED 2026-06-13 · PATCHDIFF

tutor3.9.6 → 3.9.7✓ COMPLETED

Files9

Vulnerable7

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-13673

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 9 CVE 2 Vuln 7

SORT

2 files · page 1/1

helpers/QueryHelper.php

AI: 4 vulnerabilities

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

#%!d(float64=003)

models/CouponModel.php

AI: 1 vulnerabilities

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

#%!d(float64=007)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-13673

Security writeup for CVE-2025-13673

✓ 2 FILES

## The Exploit

An unauthenticated attacker can inject arbitrary SQL into coupon lookups by appending SQL metacharacters to the `coupon_code` parameter.

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

The attacker observes a JSON response containing password hashes from the `wp_users` table. If no error suppression is in place, they see `UNION` query results merged into the coupon details response; if errors are suppressed, they can use time-based blind injection (`SLEEP()`) to infer data byte-by-byte.

## What the Patch Did

**Before**

```php
'coupon_code'   => esc_sql( $coupon_code ),
```

**After**

```php
'coupon_code'   => $coupon_code,
```

Wait — this looks backwards. The patch *removes* `esc_sql()`. Let's look at the real fix in `QueryHelper.php`:

**Before**

```php
default: // =, !=, <, >, <=, >=, LIKE, NOT LIKE, <>
    $val    = is_numeric( $val ) ? $val : "'" . $val . "'";
    $clause = array( $field, $operator, $val );
    break;
```

**After**

```php
else {
    $value = self::prepare_value( $val );
}

return "{$field} {$upper_operator} {$value}";
```

The patch introduces a new `prepare_value()` method that wraps all scalar values in `wpdb->prepare('%s', $value)` or `wpdb->prepare('%d', $value)` depending on type. This shifts the escaping responsibility from `esc_sql()` (string-only, insufficient) to parameterized queries using WordPress's `$wpdb->prepare()`. The removal of `esc_sql()` from `CouponModel.php` is intentional — it signals that the value will be processed through the query builder, not directly concatenated.

## Root Cause

**CWE-89: Improper Neutralization of Special Elements used in an SQL Command.**

The `coupon_code` parameter arrives via HTTP request (typically `$_GET['coupon_code']` or REST API input) and flows into `CouponModel::get_coupon()`. Before the patch, this method passed the coupon code to `QueryHelper::build_where_clause()`, which constructed SQL fragments by string concatenation. For operators other than `IN` and `NOT IN`, the code checked `is_numeric()` and then wrapped the value in single quotes without escaping, leaving SQL metacharacters like `'`, `--`, `/*`, and `UNION` unescaped. A malicious value like `VALID' UNION SELECT ...` would break out of the intended query and execute arbitrary SQL.

## Why It Works

The load-bearing line is `$value = self::prepare_value( $val )`. This call routes the value through `wpdb->prepare()`, which uses parameterized queries (prepared statements in MySQL parlance) to separate code from data. The old code tried to "fix" the problem with `is_numeric()` and manual quoting — these additions are security theater. `is_numeric('1e5')` returns true, but `'1e5'` as a number can trigger scientific notation in some contexts. There is no safe way to concatenate user input into SQL by hand. The patch removes that impossible task entirely, delegating it to the database driver.

The additional cases for `BETWEEN` and `NULL` operators are load-bearing too: they ensure that *all* code paths through `build_where_clause()` use `prepare_value()`, closing loopholes where an attacker could choose an unusual operator to bypass escaping.

## Hardening Checklist

- **Use `wpdb->prepare()` for all variable interpolation** — never concatenate user input into SQL, even if you think you've "escaped" it with `esc_sql()`. Pass a format string (`'%s'`, `'%d'`, `'%i'`) and let the driver parameterize.

- **Audit all QueryBuilder-like classes for string concatenation** — grep your codebase for `return "{$field}" ` or `array( $field, ... )` patterns that construct SQL. Each must pass through `$wpdb->prepare()` before database execution.

- **Validate operator whitelist in switch statements** — if your code accepts an operator parameter, use a strict whitelist (`IN`, `=`, `LIKE`, etc.) and reject unrecognized values. The patch implicitly does this by handling `BETWEEN` in its own case; unhandled operators fall through to the `else` block.

- **Test with time-based blind SQL injection payloads** — include `' OR SLEEP(5)--` and `' AND SLEEP(5)--` in your unit test suite for any parameter that flows to the database. If response time increases, your escaping is bypassed.

- **Never rely on `is_numeric()` for SQL type detection** — it is a type check, not a sanitizer. Use explicit integer casting (`(int)$val`) or `intval()` only if you *know* the field is numeric, then validate the result is within expected range.

## References

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

CVE CVE-2025-13673

PRODUCT tutor

AFFECTED ≤ 3.9.6

FIXED IN 3.9.7

STATUS Generated

Security writeup · CVE-2025-13673

Source files · 2

helpers/QueryHelper.php Linked

models/CouponModel.php Linked

↗ NVD