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

popup-builder-block2.2.0 → 2.2.1✓ COMPLETED

Files30

Vulnerable7

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 30 CVE 1 Vuln 7

SORT

1 files · page 1/1

includes/Helpers/DataBase.php

AI: 4 vulnerabilities

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

#%!d(float64=017)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-13192

Security writeup for CVE-2025-13192

✓ 1 FILE

## The Exploit

Unauthenticated attacker sends a REST API request to the Popup builder plugin with a malicious `campaign_id` parameter containing SQL syntax.

```http
GET /wp-json/popupbuilder/v1/analytics/device-stats?start_date=2025-01-01&end_date=2025-01-31&campaign_id=1%20OR%201=1 HTTP/1.1
Host: vulnerable-site.local
Accept: application/json
```

The server concatenates the unsanitized `campaign_id` directly into the SQL query string before calling `wpdb->prepare()`, allowing the injected SQL condition to execute. The attacker observes a response containing aggregated device statistics that should have been filtered to a single campaign — instead, data from all campaigns leaks because `1=1` makes the WHERE clause always true. By chaining UNION SELECT statements, the attacker can extract user tables, password hashes, or any other database content.

## What the Patch Did

**Before:**
```php
$campaign = $campaign_id ? " AND campaign_id = $campaign_id" : '';

return $wpdb->get_results(
    $wpdb->prepare("SELECT SUM(device_desktop) as desktop, 
        SUM(device_tablet) as tablet, 
        SUM(device_mobile) as mobile 
        FROM %i WHERE date BETWEEN %s AND %s $campaign",
        $table_name,
        $start_date,
        $end_date,
    )
);
```

**After:**
```php
if ( $campaign_id ) {
    return $wpdb->get_results(
        $wpdb->prepare(
            "SELECT SUM(device_desktop) as desktop, 
            SUM(device_tablet) as tablet, 
            SUM(device_mobile) as mobile 
            FROM %i WHERE date BETWEEN %s AND %s AND campaign_id = %d",
            $table_name,
            $start_date,
            $end_date,
            $campaign_id
        )
    );
} else {
    return $wpdb->get_results(
        $wpdb->prepare(
            "SELECT SUM(device_desktop) as desktop, 
            SUM(device_tablet) as tablet, 
            SUM(device_mobile) as mobile 
            FROM %i WHERE date BETWEEN %s AND %s",
            $table_name,
            $start_date,
            $end_date
        )
    );
}
```

The patch moved `$campaign_id` from string interpolation *outside* the `wpdb->prepare()` call into a parameterized placeholder `%d` *inside* the query template. The `%d` placeholder tells WordPress's database abstraction layer to treat `$campaign_id` as an integer literal, escaping any SQL metacharacters. By splitting conditional logic into separate prepared statements, the fix ensures no user-controlled value is ever concatenated into the SQL string before preparation.

## Root Cause

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

The `campaign_id` parameter enters the REST API endpoint unauthenticated. The application assigns it to the `$campaign` variable by direct string interpolation (`" AND campaign_id = $campaign_id"`), then passes this pre-built string to `wpdb->prepare()`. The prepared statement implementation expects the query template to be static; when dynamic SQL fragments are spliced in before preparation, the placeholder substitution logic cannot distinguish attacker input from legitimate SQL syntax. The trust boundary violation occurs because the attacker-controlled integer value is treated as executable code rather than data.

## Why It Works

The load-bearing security control is the `%d` placeholder in the prepared statement template: `"... AND campaign_id = %d"`. If that placeholder were absent and the code returned to direct concatenation, the injection would remain exploitable. The engineer added the conditional split (`if ( $campaign_id ) { ... } else { ... }`) to avoid a logical anomaly — if `$campaign_id` is omitted, the query must not include the `AND campaign_id = %d` clause at all, otherwise a NULL or zero value would corrupt the query logic. The separate prepared statement blocks ensure the template is never malformed. The `%d` type hint is the actual defence: it forces `wpdb->prepare()` to cast and escape the value as an integer, making `1 OR 1=1` render as the literal string `"1"` in the final query, not as a logical condition.

## Hardening Checklist

- **Use `wpdb->prepare()` with type placeholders (`%d`, `%s`, `%i`) for every user-supplied variable**, even integers that look harmless. Never concatenate variables into the query string before calling `prepare()`.
- **Audit all REST API endpoints for parameter sources** using `$_GET`, `$_POST`, `$_REQUEST`, or `sanitize_*()` callbacks; map each to its sink in a database query and verify it passes through a type-checked placeholder.
- **Enable WordPress security logging and monitor for SQL errors in production logs** — injected SQL often fails on first attempt, generating database errors that reveal the vulnerability before data exfiltration succeeds.
- **Run static analysis on custom SQL** using plugins like WP Code Inspector or grep patterns for `wpdb->query()` / `wpdb->get_results()` calls; flag any line where a variable name appears in the query string outside a placeholder.
- **Enforce capability checks on admin-facing analytics endpoints** using `current_user_can( 'manage_options' )` even if unauthenticated SQL injection is patched, to add a second control layer for defense in depth.

## References

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

CVE CVE-2025-13192

PRODUCT popup-builder-block

AFFECTED ≤ 2.2.0

FIXED IN 2.2.1

STATUS Generated

Security writeup · CVE-2025-13192

Source files · 1

includes/Helpers/DataBase.php Linked

↗ NVD