EverShop CVE-2026-115323

Exploitable only against the EverShop customer address API routes /api/customers/:customer_id/addresses using POST, PATCH, or DELETE, with no authentication required (PR:N). The concrete, mandatory prerequisite stated in the description is that the attacker must already know a valid customer_id and the target address UUID(s); because these are random UUIDs rather than sequential IDs, they cannot be feasibly guessed, which sharply limits mass/opportunistic exploitation and makes this a targeted attack requiring prior knowledge or leakage of those identifiers. Impact is confined to shipping-address records (add/modify/delete); no confidentiality read path is described in the available sources. Affected versions are 1.2.2 up to but not including 2.2.1.

The signals point to a moderate, access-control (IDOR-style) flaw rather than a top-tier emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L) scores 6.9 (medium) and reflects unauthenticated network reach with low confidentiality, integrity, and availability impact - consistent with CWE-862 missing authorization on the customer address API. The vuln.today priority is 'this_month,' not act_now/emergency, which aligns with the medium score. There is no CISA KEV listing and no EPSS score supplied, so there is no evidence of active or probable near-term exploitation; exploitation status is best described as no public exploit identified at time of analysis (the references are a GitHub issue, the patch commit, the release tag, and source-code files - not verified working exploit code). The single most important risk-limiting factor is NOT captured in the vendor's AC:L rating: the description states attackers must already 'know customer and address UUIDs.' EverShop address identifiers are UUIDs (effectively unguessable 122-bit values), so blind mass exploitation is impractical - this reads as a targeted-only issue requiring prior knowledge or leakage of victim UUIDs. That barrier is why my independent assessment raises attack complexity. Net: a legitimate access-control defect worth patching this cycle, but not a drop-everything priority given no exploitation evidence, limited impact scope (shipping addresses), and the UUID prerequisite.

An attacker who has obtained a victim's customer_id and address UUIDs (for example via a data leak, enumeration of another endpoint, or shared/exposed order data) sends an unauthenticated PATCH or DELETE request to /api/customers/:customer_id/addresses. With no authorization check enforced, the server adds, alters, or deletes the victim's saved shipping address - enabling order-fraud scenarios such as silently redirecting a shipment or corrupting checkout data. No verified working public exploit was identified at the time of analysis.