Food Store CVE-2026-96669

No authentication and no non-default configuration are required to SEED the payload: an unauthenticated attacker submits the ?type= query parameter on the plugin's public checkout page, and the plugin copies it directly into the service_type cookie, then persists it to order meta. The limiting factor for TRIGGERING is that the stored payload renders unescaped in the admin panel, so execution occurs only when a store administrator (or back-office user) subsequently views the affected order in wp-admin; an order carrying the payload must therefore be created and later reviewed. Applies to all installations of Food Store - Online Food Delivery & Pickup at version 1.5.5 or earlier.

This is a CVSS 7.2 (High) unauthenticated stored XSS. The provided vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N indicates a network-reachable, low-complexity flaw needing no privileges, with a scope change (S:C) because the payload seeded on the public storefront ultimately executes in the separate wp-admin security context. The vuln.today decision label is 'this_week', which aligns with a real-but-not-emergency priority. Several key exploitation signals are MISSING from the input: no EPSS probability is provided, so likelihood of widespread exploitation cannot be quantified; the CVE is NOT listed in CISA KEV; and no public exploit/PoC reference is supplied (the references are the Wordfence advisory and WordPress source-code trac lines, not working exploit code). Thus exploitation status is 'no public exploit identified at time of analysis.' The realistic risk is moderate: unauthenticated seeding is attractive, but impact is capped at C:L/I:L (no availability impact), execution depends on an administrator later viewing the poisoned order in the admin panel, and the affected product is a niche WordPress plugin with limited deployment. Net: worth patching on a near-term (this week) cadence rather than as an active-exploitation fire drill, but note the absence of EPSS/KEV data means widespread automated exploitation is unconfirmed either way.

An unauthenticated attacker opens the plugin's public checkout page and supplies a crafted script payload via the ?type= query parameter; the plugin writes that value verbatim into the browser's service_type cookie, which is then persisted into the resulting order's metadata. When a store administrator later opens that order in the wp-admin panel, the unescaped payload renders and executes JavaScript in the admin's authenticated session. No public exploit code is identified at time of analysis, and because PR:N/UI:N the attack requires no authentication and no special victim action beyond normal admin order review.