Shopper Admin: Chained Authorization Defects Enable RBAC Privilege Escalation
Two independent authorization flaws in Shopper admin panel team settings allow any authenticated user to escalate from read-only to full administrator, remove legitimate admins, and take over role-based access control entirely.
CVE References
Affected
Vulnerability Description
This disclosure identifies two distinct authorization defects in Shopper's team settings module that, when chained, enable complete RBAC compromise. The first flaw involves missing mount-level authorization on Settings/Team/Index, permitting any authenticated panel user to access team management functions without permission checks. The second flaw represents permission confusion: Settings/Team/RolePermission write operations incorrectly gate on the view_users read-only permission rather than the administrative manage_users permission. Together, these allow low-privilege users to create roles, grant themselves arbitrary permissions (including manage_users and edit_orders), and remove legitimate administrators. The root cause is insufficient authorization layering—relying on incomplete permission models without explicit capability-based access control at the action level.
Proof-of-Concept Significance
This vulnerability is reliably exploitable by any user with basic panel access. The attack requires no special conditions beyond initial authentication; no complex race conditions, encoding tricks, or timing dependencies exist. An attacker with view_users permission can immediately escalate to admin. The two-stage nature (missing mount check + permission confusion) creates a robust exploitation path: stage one grants access to the interface, stage two allows privilege escalation through the interface itself. This design flaw suggests the authorization model was not threat-modeled against authenticated insider threats or compromised low-privilege accounts.
Detection Guidance
Defenders should monitor for: (1) Unusual role creation events in audit logs from low-privilege accounts; (2) Permission changes on users from accounts lacking manage_users capability; (3) HTTP requests to /settings/team endpoints from accounts without administrative roles, especially followed by write operations to RolePermission endpoints; (4) Deletion or deactivation of admin accounts by non-admin users; (5) Rapid permission changes on a single account correlating with view_users assignments. Log indicators include successful POST/PUT requests to Settings/Team/RolePermission paired with low-privilege user identifiers. WAF rules should flag POST requests to team settings endpoints from authenticated sessions lacking the manage_users capability.
Mitigation Steps
Immediate: Upgrade to Shopper v2.8.0 or later via composer require shopper/admin:^2.8. During patching: Implement temporary authorization middleware that denies access to Settings/Team/* endpoints to users without explicit manage_users permission. Audit role assignments and administrator account status for unauthorized modifications. Review access logs for the past 90 days to identify potential exploitation. Post-patch: Verify all role definitions and user permissions are consistent with intended RBAC policy; regenerate admin credentials if compromise is suspected. Test authorization checks in team settings endpoints via unit and integration tests.
Risk Assessment
Likelihood of exploitation is very high due to simplicity of attack and absence of mitigation options prior to patching. Any attacker with initial access to an authenticated panel account (phishing, credential compromise, insider threat, supply chain) can immediately escalate to full administrator. The vulnerability is particularly dangerous in multi-tenant SaaS deployments where customer support staff or vendors may hold view_users access. Threat actors will prioritize this given its chained nature, reliability, and complete control outcome. Organizations running Shopper versions below 2.8.0 should treat this as an active threat requiring immediate patching, especially if any user accounts with view_users permission exist in production environments.
Sources