Shopper CVE-2026-62991

Requires an authenticated admin-panel session holding both access_dashboard and read_customers; no view_users permission is needed, which is precisely the boundary being bypassed. No special product configuration is required - the flaw is present in Show.php's default code path because mount() calls findOrFail($user) without the customers() role scope that the listing page applies. Exploitation is limited by the need for valid low-privileged staff credentials (PR:L, so not remotely unauthenticated) and is confined to deployments of Shopper < 2.10.1 that have staff/customer accounts in the same user table. The destructive extension via anonymizeAction() is further gated: it additionally requires the attacker's role to hold delete_customers.

Signals point to a real but moderate, insider-driven risk rather than an internet-wide emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/C:H/I:N/A:N, 6.5) shows the flaw is network-reachable and trivial to trigger (just change a numeric ID in the URL) but requires an authenticated admin-panel session holding access_dashboard and read_customers - so the threat model is a low-privileged staff member or a compromised staff account, not an anonymous remote attacker. The vuln.today Decision label is this_month (not act_now/emergency), consistent with a privilege-requiring authorization bug. No EPSS score and no CISA KEV entry are present in the input, so there is no evidence of mass or active exploitation; the exploitation signal that does exist is a detailed step-by-step reproduction PoC embedded in the GHSA advisory (login, blocked /cpanel/setting/team, then successful /cpanel/customers/1/show against the admin). The one divergence worth verifying: NVD rates confidentiality C:H, but the exposed asset is per-record account profile data (name, email, addresses) retrievable one ID at a time with enumeration - closer to C:L in my independent read - so the 6.5 figure likely slightly overstates the single-request confidentiality loss while the enumeration and the conditional destructive anonymize path (needs delete_customers) justify treating it as a genuine authorization-boundary break. Net: prioritize for the next patch cycle, especially where multiple distinct staff roles exist, but it is not a drop-everything remote-unauth issue.

A staff user provisioned with only access_dashboard and read_customers (and correctly denied the /cpanel/setting/team interface because they lack view_users) logs into the admin panel and simply changes the {user} ID in /cpanel/customers/{user}/show to 1, retrieving the administrator's profile (e.g. admin@admin.com) and then enumerating every account by observing differing 200/403/404 responses. A full reproduction PoC exists in the GHSA advisory, though it is a manual walkthrough rather than a packaged standalone exploit. If that same role also holds delete_customers, the attacker can invoke anonymizeAction() against the loaded non-customer account for destructive follow-up.