CVE-2026-22850: When Your Own Export File Comes Back As A Bomb

Koko Analytics, a WordPress analytics plugin, lets unauthenticated visitors plant SQL fragments into the analytics tables, then politely re-serves them as a .sql admin export, then runs whatever the admin re-uploads with $wpdb->query() — no allowlist, no statement filter, no escaping along the way. Three layers of "this is fine," each one trusting the layer before it.

The advisory in plain English

A page tracker writes the visitor's path string into a paths table. The plugin offers an admin "Export" button that dumps that table into an INSERT … VALUES (…) script, and an "Import" button that feeds the upload back into the database. Each step considered itself the safe one: the tracker said "we only store strings," the exporter said "we only serialize stored data," the importer said "we only run our own export files." None of them actually verified those assumptions, and the joints between them are where the SQL injection lives.

In the worst case, an attacker only needs to get one HTTP request through the public tracking endpoint and wait for an admin to click Export → Import. Or — for an authenticated user with manage_koko_analytics — skip the laundering and upload an arbitrary .sql directly. Either way, the import sink is $wpdb->query() on attacker-controlled statements, against the live WordPress database.

The flawed function — input

In src/Resources/functions/collect.php, extract_pageview_data accepts the pa (path) and r (referrer) parameters from any request:

$path = substr(trim($raw['pa']), 0, 2000);
$post_id = \filter_var($raw['po'], FILTER_VALIDATE_INT);
$referrer_url = !empty($raw['r']) ? \filter_var(\trim($raw['r']), FILTER_VALIDATE_URL) : '';
if ($post_id === false || $referrer_url === false) {
    return [];
}

The referrer goes through FILTER_VALIDATE_URL, which is reasonable. The path goes through trim() and substr(). That's the entire input filter for pa — 2000 bytes of anything. Quote characters, backslashes, parentheses, semicolons, newlines: all welcome.

The path is then aggregated into wp_koko_analytics_paths via Upserter::upsert(), which uses $wpdb->prepare() correctly — so at this stage, storage is safe. The string sits inertly in the database. That is exactly why nobody noticed.

The flawed function — export

src/Admin/Data_Export.php reads those rows back and writes them to a downloadable .sql file:

fwrite($stream, "INSERT INTO {$this->db->prefix}koko_analytics_paths (id, path) VALUES ");
$prefix = '';
foreach ($rows as $s) {
    fwrite($stream, "{$prefix}({$s->id},\"{$s->path}\")");
    $prefix = ',';
}
fwrite($stream, ";\n");

Naive interpolation. No esc_sql, no addslashes, no wpdb->prepare. Whatever was stored is what gets written, wrapped in unescaped double quotes. The same code repeats for koko_analytics_referrer_urls. The author's mental model was almost certainly: "these strings came from our database, so they're safe." They came from our database, sure, but they originated from a public unauthenticated endpoint.

The flawed function — import

src/Admin/Data_Import.php reads an uploaded .sql and tries to look responsible about it:

$sql = file_get_contents($_FILES['import-file']['tmp_name']);

if (!preg_match('/^(--|DELETE|SELECT|INSERT|TRUNCATE|CREATE|DROP)/', $sql)) {
    wp_safe_redirect(/* … "does not look like a Koko Analytics export file" … */);
    exit;
}

That is the entire authenticity check. A regex anchored to the start of the file. Every export this plugin produces begins with the comment -- Koko Analytics database export from …, so any file whose first two characters are -- sails through. There is no signature, no checksum, no per-table verification — just "starts with -- or one of these SQL keywords."

Then:

$statements = explode(';', $sql);
foreach ($statements as $statement) {
    $statement = trim($statement);
    if (!$statement) {
        continue;
    }
    $result = $wpdb->query($statement);
    /* … */
}

Split on ;, run each chunk. No allowlist of target tables. No restriction on statement verbs. DROP TABLE wp_users is just as valid here as INSERT INTO wp_koko_analytics_paths.

Why the checks were insufficient

Three trust mistakes, each individually fixable, jointly catastrophic:

1. The tracker treated pa as a path because it was named pa. A 2000-character string with no character-class restriction isn't a path; it's a payload buffer. The FILTER_VALIDATE_URL applied to the referrer was actually doing real work — that's why the advisory's r vector requires more contortion. The path field had no equivalent guard.

2. The exporter trusted "data from our own table." That phrase is doing a lot of unwarranted lifting. Storage is trustworthy because of prepare(). The bytes themselves are still attacker-controlled. Once you stop running them through prepare() and start string-concatenating, you've reopened the wound.

3. The importer trusted "files that look like our exports." A two-character magic prefix is not a provenance check. And even if it were — even if the file were definitely produced by this plugin's exporter — that doesn't mean its contents are trustworthy, because (1) and (2) above have already poisoned the well. The importer's "this file came from us" assumption was structurally invalid.

There is also the secondary path the advisory flags: anyone with manage_koko_analytics can simply upload a hand-crafted .sql. With the import handler running raw $wpdb->query() per semicolon-delimited chunk, that capability turns into "execute arbitrary SQL on the WordPress database," which trivially escalates to "create new admin user" or "drop wp_users." manage_koko_analytics is not supposed to be that powerful.

What the fix changed

Commit 7b7d58f is small — three meaningful hunks plus an unrelated WP-CLI guard. Each addresses one of the three trust mistakes:

Tracker, in collect.php:

if ($post_id === false || $referrer_url === false ||
    filter_var("https://localhost$path", FILTER_VALIDATE_URL, FILTER_FLAG_PATH_REQUIRED) === false) {
    return [];
}

The path is now glued onto a synthetic origin and validated as a URL with a required path component. Quotes, semicolons, backslashes, control characters — all rejected.

Exporter, in Data_Export.php:

fprintf($stream, "{$prefix}({$s->id},\"%s\")", esc_sql($s->path));

Switches from string interpolation to fprintf with esc_sql() on the variable. The same change is applied to referrer_urls. The export is now actual SQL-safe SQL.

Importer, in Data_Import.php:

if (! preg_match("/{$wpdb->options}|{$wpdb->prefix}koko_analytics/", $statement)) {
    continue;
}
$result = $wpdb->query($statement);

Each statement is now required to mention either wp_options (for the version row) or a wp_koko_analytics_* table. A statement targeting wp_users is silently skipped. This is still not a strong allowlist — a crafted statement could embed those names in a comment to slip past — but combined with the export-side escaping, the attacker no longer controls the bytes that reach this regex in the first place.

The lesson

Trust boundaries don't disappear when data crosses them; they get inverted. Bytes that were untrusted on the way in are still untrusted on the way out, no matter how many of your tables they passed through. $wpdb->prepare() makes storage safe — it does not launder the contents.

The other lesson is the one every plugin-import feature eventually learns: a file format you produced is not authenticated just because you produced it. If you're going to run uploaded SQL through $wpdb->query(), the file needs to be either signed or parsed — header-sniffing is theatre. Koko's patch chose "parsed," gating each statement on a target-table regex. That's a defense-in-depth move that should have been there since v1.

It's worth noticing what wasn't broken: the storage path. The Upserter class uses prepare() correctly. The bug isn't a mistake about prepared statements — it's a mistake about where prepared statements need to live. The author thought one prepare() at write time covered the data forever. It didn't. It covered exactly one query.

References

• Advisory: https://github.com/ibericode/koko-analytics/security/advisories/GHSA-jgfh-264m-xh3q
• Fix commit: https://github.com/ibericode/koko-analytics/commit/7b7d58f4a1838c8203cf4e7bb59847c982432119
• Researcher writeup: https://drive.google.com/file/d/1HdQKf42prwrBUUG2CwbIkccTp2i6HR6d/view?usp=sharing