CVE-2026-56828

Shopper is a Headless e-commerce Admin Panel. From 2.8.0 until 2.8.1, three Shopper Livewire admin components retain authorization gaps after the earlier team-settings authorization fix. A staff member with only view_users and access_dashboard can mutate permissions, create an administrator, or delete roles. In packages/admin/src/Livewire/Components/Settings/Team/Permissions.php, togglePermission and removePermission authorize view_users rather than the stronger access_setting permission; packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php exposes permission IDs in wire:click handlers. The attacker can grant arbitrary permissions to the bound role, including access_setting on the attacker's own role, or delete permission definitions. In packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php, mount() and store() also accept view_users, and the client-selected role_id can identify the admin role, allowing creation of a pre-verified administrator with an attacker-chosen password. In packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php, deleteAction has no action authorization and is only conditioned on can_be_removed, while page access requires view_users. Deleting a removable role removes access for assigned users, enabling RBAC denial of service as well as privilege escalation. This issue is fixed in version 2.8.1.

Shopper is a Headless e-commerce Admin Panel. From 2.8.0 until 2.8.1, three Shopper Livewire admin components retain authorization gaps after the earlier team-settings authorization fix. A staff member with only view_users and access_dashboard can mutate permissions, create an administrator, or delete roles. In packages/admin/src/Livewire/Components/Settings/Team/Permissions.php, togglePermission and removePermission authorize view_users rather than the stronger access_setting permission; packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php exposes permission IDs in wire:click handlers. The attacker can grant arbitrary permissions to the bound role, including access_setting on the attacker's own role, or delete permission definitions. In packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php, mount() and store() also accept view_users, and the client-selected role_id can identify the admin role, allowing creation of a pre-verified administrator with an attacker-chosen password. In packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php, deleteAction has no action authorization and is only conditioned on can_be_removed, while page access requires view_users. Deleting a removable role removes access for assigned users, enabling RBAC denial of service as well as privilege escalation. This issue is fixed in version 2.8.1.

Summary

Three Livewire admin components in shopper/framework (latest master at commit fcd0c59, released as v2.8.0) gate state-mutating actions on the read-only view_users permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / GHSA-f946-9qp6-vgch — the PR moved most write actions from view_users to access_setting, but three were missed (one of them is a brand-new file added by the security commit itself).

A staff user holding only view_users + access_dashboard (a realistic "support" or "viewer" role per Shopper's own PermissionsTableSeeder) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the admin role and then log in as that user; (3) delete arbitrary permissions rows (RBAC DoS) or — when can_be_removed=true — delete entire roles.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization).

Vulnerable components (paths relative to repo root)

1) packages/admin/src/Livewire/Components/Settings/Team/Permissions.php

• togglePermission(int $id) at line 28 calls $this->authorize('view_users');
• removePermission(int $id) at line 55 calls $this->authorize('view_users');

The Permissions blade at packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php line 34 emits every permission's id directly in wire:click handlers, so the attacker does not even need to guess IDs — the page itself enumerates them.

Net effect: any user who can mount the Permissions component (gated on view_users) can grant any permission row to the bound $role. Granting access_setting to the attacker's own role unlocks every action that PR #511 supposedly hardened with ->authorize('access_setting'). Granting delete_customers, edit_orders, edit_products, add_brands, etc. is direct data-modification escalation.

2) packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php

• mount() at line 53 calls $this->authorize('view_users');
• store() at line 122 calls $this->authorize('view_users');

This file is new file mode 100755 in commit fcd0c59 — it was created as part of the security fix and inherited the same misclassified gate.

store() creates a User with email_verified_at = now(), the attacker's chosen password, and any selected role_id. The Radio::make('role_id') options filter only excludes config('shopper.admin.roles.user'), so the admin role is selectable. Log out, log in as the new account → full admin.

3) packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php

• deleteAction at lines 81-90: only gated by ->visible($this->role->can_be_removed), with no ->authorize() chain.

Page-level mount (line 52) requires only view_users. For any role with can_be_removed = true, a view_users-only user can call the action and delete the role (cascading the loss of permissions for every assigned user).

Self-confirmation in the project's own test suite

The following tests are green on master @ fcd0c59 — they ARE the PoC:

tests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php
  line 14-16: `givePermissionTo('view_users')` only
  line 36-45: "can toggle permission to role" — passes
  line 74-85: "can remove permission" — passes

tests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php
  line 16-18: `givePermissionTo('view_users')` only
  line 29-56: "can create new team member" — passes, asserts the new user `hasRole('manager')`

A view_users-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user — verified by Shopper's own regression tests.

Suggested fix

Change $this->authorize('view_users') to $this->authorize('access_setting')…

Shopper is a Headless e-commerce Admin Panel. From 2.8.0 until 2.8.1, three Shopper Livewire admin components retain authorization gaps after the earlier team-settings authorization fix. A staff member with only view_users and access_dashboard can mutate permissions, create an administrator, or delete roles. In packages/admin/src/Livewire/Components/Settings/Team/Permissions.php, togglePermission and removePermission authorize view_users rather than the stronger access_setting permission; packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php exposes permission IDs in wire:click handlers. The attacker can grant arbitrary permissions to the bound role, including access_setting on the attacker's own role, or delete permission definitions. In packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php, mount() and store() also accept view_users, and the client-selected role_id can identify the admin role, allowing creation of a pre-verified administrator with an attacker-chosen password. In packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php, deleteAction has no action authorization and is only conditioned on can_be_removed, while page access requires view_users. Deleting a removable role removes access for assigned users, enabling RBAC denial of service as well as privilege escalation. This issue is fixed in version 2.8.1.

Shopper is a Headless e-commerce Admin Panel. From 2.8.0 until 2.8.1, three Shopper Livewire admin components retain authorization gaps after the earlier team-settings authorization fix. A staff member with only view_users and access_dashboard can mutate permissions, create an administrator, or delete roles. In packages/admin/src/Livewire/Components/Settings/Team/Permissions.php, togglePermission and removePermission authorize view_users rather than the stronger access_setting permission; packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php exposes permission IDs in wire:click handlers. The attacker can grant arbitrary permissions to the bound role, including access_setting on the attacker's own role, or delete permission definitions. In packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php, mount() and store() also accept view_users, and the client-selected role_id can identify the admin role, allowing creation of a pre-verified administrator with an attacker-chosen password. In packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php, deleteAction has no action authorization and is only conditioned on can_be_removed, while page access requires view_users. Deleting a removable role removes access for assigned users, enabling RBAC denial of service as well as privilege escalation. This issue is fixed in version 2.8.1.

Summary

Three Livewire admin components in shopper/framework (latest master at commit fcd0c59, released as v2.8.0) gate state-mutating actions on the read-only view_users permission. This is the same class as the issue Shopper fixed in v2.8.0 / PR #511 / GHSA-f946-9qp6-vgch — the PR moved most write actions from view_users to access_setting, but three were missed (one of them is a brand-new file added by the security commit itself).

A staff user holding only view_users + access_dashboard (a realistic "support" or "viewer" role per Shopper's own PermissionsTableSeeder) can: (1) self-escalate by granting any permission to their own role; (2) create a brand-new admin team member with a chosen password and the admin role and then log in as that user; (3) delete arbitrary permissions rows (RBAC DoS) or — when can_be_removed=true — delete entire roles.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H = 8.8 (High). CWE-285 (Improper Authorization) + CWE-862 (Missing Authorization).

Vulnerable components (paths relative to repo root)

1) packages/admin/src/Livewire/Components/Settings/Team/Permissions.php

• togglePermission(int $id) at line 28 calls $this->authorize('view_users');
• removePermission(int $id) at line 55 calls $this->authorize('view_users');

The Permissions blade at packages/admin/resources/views/livewire/components/settings/team/permissions.blade.php line 34 emits every permission's id directly in wire:click handlers, so the attacker does not even need to guess IDs — the page itself enumerates them.

Net effect: any user who can mount the Permissions component (gated on view_users) can grant any permission row to the bound $role. Granting access_setting to the attacker's own role unlocks every action that PR #511 supposedly hardened with ->authorize('access_setting'). Granting delete_customers, edit_orders, edit_products, add_brands, etc. is direct data-modification escalation.

2) packages/admin/src/Livewire/SlideOvers/CreateTeamMember.php

• mount() at line 53 calls $this->authorize('view_users');
• store() at line 122 calls $this->authorize('view_users');

This file is new file mode 100755 in commit fcd0c59 — it was created as part of the security fix and inherited the same misclassified gate.

store() creates a User with email_verified_at = now(), the attacker's chosen password, and any selected role_id. The Radio::make('role_id') options filter only excludes config('shopper.admin.roles.user'), so the admin role is selectable. Log out, log in as the new account → full admin.

3) packages/admin/src/Livewire/Pages/Settings/Team/RolePermission.php

• deleteAction at lines 81-90: only gated by ->visible($this->role->can_be_removed), with no ->authorize() chain.

Page-level mount (line 52) requires only view_users. For any role with can_be_removed = true, a view_users-only user can call the action and delete the role (cascading the loss of permissions for every assigned user).

Self-confirmation in the project's own test suite

The following tests are green on master @ fcd0c59 — they ARE the PoC:

tests/Admin/Livewire/Components/Settings/Team/PermissionsTest.php
  line 14-16: `givePermissionTo('view_users')` only
  line 36-45: "can toggle permission to role" — passes
  line 74-85: "can remove permission" — passes

tests/Admin/Livewire/SlideOvers/CreateTeamMemberTest.php
  line 16-18: `givePermissionTo('view_users')` only
  line 29-56: "can create new team member" — passes, asserts the new user `hasRole('manager')`

A view_users-only Livewire user actor successfully toggles permissions, removes permissions, and creates a new privileged user — verified by Shopper's own regression tests.

Suggested fix

Change $this->authorize('view_users') to $this->authorize('access_setting')…