Shopper EUVD-2026-33410

Requires an authenticated Shopper admin-panel account holding the low-privilege read_orders or browse_orders permission (or any role lacking edit_orders/edit_products but with panel login), and network reachability to the Shopper Filament admin routes. capturePayment additionally requires that the target Shopper instance has a Payment Service Provider configured and an order in a captureable state for real funds movement to occur; the order-lifecycle mutations (cancel, mark paid, mark complete, archive, start processing, mark delivered, edit tracking) require only the low-privilege account with no further configuration. Limiting factors: the attacker must already have valid panel credentials (PR:L), so deployments that restrict admin access to a small group of trusted operators face reduced risk, and panels gated behind VPN/IP allowlists shrink the network reachability needed by AV:N. No user interaction is required from a victim (UI:N).

The CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) reflects network-reachable, low-complexity exploitation by an authenticated low-privilege user with high confidentiality and integrity impact and no availability impact - consistent with an authorization bypass rather than crash or DoS. Real-world risk is meaningful for any Shopper deployment that grants broad read-only roles (support staff, analysts, junior operators), because such users gain de facto control over order lifecycle, product catalog, RBAC roles, and - critically - can invoke capturePayment to move real funds through the connected PSP. EPSS and CISA KEV data were not provided in the input, so exploitation probability and active-exploitation status are unknown; no public exploit identified at time of analysis, but the GHSA description and PR diff publicly enumerate the vulnerable components and missing authorize() calls, lowering the effort to craft a working exploit. The financial-impact angle (PSP capture) and ease of weaponization once an account exists make this a high-priority patch for any production Shopper instance with more than one admin user.

An authenticated user holding only the read_orders or browse_orders role - for example a customer-support agent or a compromised low-tier staff account - opens the Shopper admin Order detail page and invokes the Filament capturePayment action on a pending order, causing the connected Payment Service Provider to capture real funds; the same session then marks unrelated orders cancelled, paid, complete, or delivered, and pivots to Settings/Team to create a new admin role and delete legitimate users. No public exploit identified at time of analysis, but the GHSA advisory and PR #511 diff publicly identify the exact unauthenticated action handlers and missing authorize('edit_orders') calls, so reproduction requires only standard browser/Livewire request crafting against the documented endpoints.