Ajax Search Lite CVE-2026-110360

Exploitation requires only that the target WordPress site has the Ajax Search Lite plugin installed and active at a version from n/a through 4.14.5; per the CVSS vector (AV:N/AC:L/PR:N/UI:N) no authentication, privileges, or user interaction are needed, so default configurations are reachable by remote unauthenticated attackers. The practical limiting factor is the narrow impact - only LOW confidentiality exposure (unauthorized read of access-controlled data) with no integrity or availability effect - and the requirement that the plugin be present and the vulnerable endpoint reachable; the input does not specify a non-default feature or setting as a precondition.

This is a moderate-severity Missing Authorization flaw (CWE-862) with a Patchstack-assigned CVSS of 5.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N). The vector signals favor exploitation ease - network-reachable, low complexity, no privileges, and no user interaction - but the impact is deliberately narrow: only a LOW confidentiality effect with no integrity or availability impact and an unchanged scope. There is no EPSS score, no SSVC decision data, and no POC provided in the input, so exploitation probability cannot be quantified from this data. This CVE is NOT in CISA KEV and no public exploit is identified, so despite the attacker-friendly vector this reads as a high-reachability but low-consequence information-exposure issue rather than a critical priority. The single limiting factor is the constrained impact (C:L only), which caps real-world damage to unauthorized read access to data that should be access-controlled. No conflicting signals are present, but note the thin single-source intelligence (Patchstack only) limits confidence in the exact affected-version boundary beyond 'n/a through 4.14.5'.

An unauthenticated remote attacker sends a crafted request directly to an Ajax Search Lite endpoint that fails to enforce an authorization check, retrieving data or invoking functionality that should be restricted. Because no authentication, privileges, or user interaction are required and complexity is low, the request can be issued directly against any reachable WordPress site running the vulnerable plugin. No public exploit code was identified at time of analysis.