ANALYSIS · 8d5e0b13· FINISHED 2026-06-13 · PATCHDIFF

learnpress4.2.7 → 4.2.7.1✓ COMPLETED

Files33

Vulnerable16

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-2024-8522

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 33 CVE 2 Vuln 16

SORT

2 files · page 1/1

inc/Models/Courses.php

AI: 2 vulnerabilities

CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')CWE-20: Improper Input Validation CVE-2024-8522

#%!d(float64=006)

inc/jwt/rest-api/version1/class-lp-rest-courses-v1-controller.php

AI: 2 vulnerabilities

CWE-20: Improper Input ValidationCWE-476: NULL Pointer Dereference CVE-2024-8522

#%!d(float64=027)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2024-8522

Security writeup for CVE-2024-8522

✓ 2 FILES

## The Exploit

An unauthenticated attacker can inject SQL into the LearnPress courses REST API by crafting a malicious `c_only_fields` parameter that breaks out of a comma-separated list context and appends arbitrary SQL.

```bash
curl -X GET 'http://vulnerable-site.local/wp-json/learnpress/v1/courses?c_only_fields=ID,post_title/**/UNION/**/SELECT/**/user_login,user_pass/**/FROM/**/wp_users--' \
  -H 'Content-Type: application/json'
```

The attacker observes the response includes user login credentials and password hashes in fields that should only contain course metadata. No authentication or capability check is required; the endpoint accepts requests from any origin.

## What the Patch Did

**Before**

```php
$fields         = explode( ',', $fields_str );
$filter->fields = $fields;
```

and

```php
// c_only_fields parameter was not being processed at all
```

**After**

```php
$fields         = explode( ',', $fields_str );
foreach ( $fields as $key => $field ) {
    $fields[ $key ] = LP_Database::getInstance()->wpdb->prepare( '%i', $field );
}
$filter->fields = $fields;
```

and

```php
$fields_only_str = LP_Helper::sanitize_params_submitted( urldecode( $param['c_only_fields'] ?? '' ) );
if ( ! empty( $fields_only_str ) ) {
    $fields_only         = explode( ',', $fields_only_str );
    foreach ( $fields_only as $key => $field ) {
        $fields_only[ $key ] = LP_Database::getInstance()->wpdb->prepare( '%i', $field );
    }
    $filter->only_fields = $fields_only;
}
```

The patch introduced two security controls: first, it applies `wpdb->prepare()` with the `%i` placeholder (integer identifier) to every field name in both the `c_fields` and `c_only_fields` parameters. Second, it wraps the untrusted parameter value in `LP_Helper::sanitize_params_submitted()` before parsing, providing defence in depth. The `%i` placeholder tells WordPress to treat the string as a column identifier, not a literal SQL fragment, escaping special characters and preventing breakout.

## Root Cause

This is a **CWE-89 SQL Injection** vulnerability. The attack path is: an unauthenticated HTTP request carries a `c_only_fields` query parameter → the REST controller at `/wp-json/learnpress/v1/courses` accepts it with minimal validation → the parameter value is split by commas but never escaped or parameterized → the field names are interpolated directly into a SQL query string built in `inc/Models/Courses.php` → an attacker injects SQL operators and SELECT clauses that the database interprets as valid SQL commands. The `c_only_fields` parameter explicitly landed in the codebase without sanitization logic, creating an unguarded entry point to the database layer.

## Why It Works

The load-bearing line is `LP_Database::getInstance()->wpdb->prepare( '%i', $field )`. Without it, field names remain raw user input; with it, WordPress's prepared statement mechanism escapes SQL metacharacters and enforces identifier context. If you removed only this line but kept `LP_Helper::sanitize_params_submitted()`, the exploit would still work because basic HTML sanitization (likely `htmlspecialchars()` or `strip_tags()`) does not prevent SQL syntax. The engineer added the helper function call for defense in depth—to catch obvious attack signatures early—but the real blocker is `prepare()`. The `foreach` loop is necessary because `prepare()` operates on individual strings, not arrays; without the loop, the unsanitized array would pass through unchanged.

## Hardening Checklist

- **Whitelist field names before query construction.** Before splitting user input into field names, validate each against a hardcoded array of allowed columns using `in_array( $field, $allowed_columns, true )`. Do not rely on sanitization alone to prevent injection.

- **Use parameterized queries for all dynamic SQL.** Always call `$wpdb->prepare()` with appropriate placeholders (`%i` for identifiers, `%d` for integers, `%s` for strings) instead of string concatenation, even for column names that seem "safe."

- **Apply nonce verification on REST endpoints.** Add `check_ajax_referer()` or a custom nonce check in the REST controller callback to prevent CSRF and establish an authenticated context, even if the endpoint is public.

- **Escape and validate at REST controller entry.** Use `sanitize_text_field()` or `sanitize_key()` on all query parameters in the REST controller *before* passing them to model/database layers. Do not rely on downstream sanitization as a security boundary.

- **Audit field-name handling across all REST endpoints.** Search the codebase for `explode()` calls on user input, especially in REST callbacks. Any parameter that controls column selection, table names, or field lists must be whitelisted or parameterized.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2024-8522

CVE CVE-2024-8522

PRODUCT learnpress

AFFECTED ≤ 4.2.7

FIXED IN 4.2.7.1

STATUS Generated

Security writeup · CVE-2024-8522

Source files · 2

inc/Models/Courses.php Linked

inc/jwt/rest-api/version1/class-lp-rest-courses-v1-controller.php Linked

↗ NVD