Shopper Admin Panel CVE-2026-62990

Requires an authenticated back-office staff account with a content-upload permission - in 2.x specifically edit_products or add_brands - and, critically, an administrator must subsequently open the uploaded HTML or SVG file, since direct account creation by the low-privileged uploader is blocked by the access_setting check. The enabling conditions are specific: packages/admin/config/media.php allows image/svg+xml across every media collection (so Filament's image/* wildcard does not block SVG), the product files collection in Files.php has no MIME restriction and accepts text/html, and media is served inline from the public disk at /storage/ with the file's own Content-Type and no Content-Disposition:attachment and no Content-Security-Policy. Limiting factors that reduce realistic risk: two distinct actors are needed (a malicious/compromised content editor plus an admin who opens the file), the staff account must already be authenticated, and the escalation depends on CreateTeamMember::store() trusting a client-supplied role_id. 3.x prereleases already exclude SVG but still allow executable product files until 3.0.0-beta.3.

This is a cross-privilege stored XSS (CWE-79) chained to privilege escalation (CWE-269) in the Shopper admin panel. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N, 8.7) correctly shows the main brakes on real-world risk: exploitation is NOT remote-unauthenticated - it requires an already-authenticated low-privileged staff account with a content-upload permission (PR:L), AND a separate administrator must subsequently open the malicious file (UI:R). The scope change (S:C) and C:H/I:H reflect the genuine payoff: the script runs in the admin's session and mints a standalone administrator account. No EPSS score is provided in the input, and the CVE is NOT listed in CISA KEV, so there is no signal of active or widespread exploitation; the vuln.today decision label is 'this_week' (not act_now/emergency), consistent with a serious but non-emergency insider/escalation issue. A detailed proof-of-concept is published in the vendor GHSA advisory and was verified end-to-end by the reporter (Testbench harness plus a headless Chromium browser), so working exploit logic is public even though active exploitation is not confirmed. Net: a real priority for any deployment that delegates content-editing to semi-trusted staff (it turns a content-editor into a persistent admin), but it is gated behind authentication and required admin interaction rather than a drive-by remote bug - treat as high-value insider/escalation risk, not an internet-facing worm.

A low-privileged staff member holding edit_products (or add_brands) uploads a .html or .svg file containing <script> through the normal product Files form; because media is served inline from the same-origin public disk at /storage/ with its own Content-Type and no Content-Disposition:attachment or CSP, the payload executes when an administrator later opens the file, running in the admin's session to drive CreateTeamMember and create a new attacker-controlled administrator account. A detailed proof-of-concept, verified end-to-end by the reporter (project Testbench harness and a headless Chromium browser confirming same-origin script execution and CSRF-token read), is published in the vendor's GHSA advisory.