How severe is CVE-2026-56828?

CVE-2026-56828 has a CVSS score of 8.8/10, rated HIGH. Immediate patching is strongly recommended.

Which packages are affected by CVE-2026-56828?

CVE-2026-56828 affects the following packages: shopper/framework (Packagist). Ecosystems affected: Packagist.

How do I fix CVE-2026-56828?

Update shopper/framework to 2.9.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-56828 is resolved across your whole dependency graph.

How do I detect CVE-2026-56828 in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopper/framework. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate CVE-2026-56828 if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against CVE-2026-56828?

O3 pinpoints whether CVE-2026-56828 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is CVE-2026-56828 actively exploited in the wild?

No public exploit code has been indexed for CVE-2026-56828 yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was CVE-2026-56828 published, and has it been updated?

CVE-2026-56828 was published on September 11, 2026 and was last updated on September 11, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘

🐘 Packagist

Not in CISA KEV

HIGH severity

CVE-2026-56828

HIGH

CVE-2026-56828 is a high-severity (CVSS 8.8) vulnerability in shopper/framework. O3 Security confirms whether CVE-2026-56828 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Shopper: privilege escalation via improper Livewire admin component authorization

Published

Sep 11, 2026

Updated

Sep 11, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Exploitation data as of Sep 11, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected

🐘shopper/framework

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

Description

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') in:

Permissions::togglePermission
Permissions::removePermission
Permissions::mount (defence in depth, matches Team\Index)
CreateTeamMember::mount
CreateTeamMember::store

Add ->authorize('access_setting') to RolePermission::deleteAction (matches the pattern already applied to generatePermissionsAction, createPermissionAction, and Team\Index::DeleteAction).

Update the two regression tests to use access_setting instead of view_users so they accurately reflect the privilege boundary.

Resources

Prior advisory of the same class: https://github.com/shopperlabs/shopper/security/advisories/GHSA-f946-9qp6-vgch
Fix commit that introduced these residual gaps: https://github.com/shopperlabs/shopper/commit/fcd0c5920588702df5b874f432b1042abd77a50b
CWE-285 Improper Authorization
CWE-862 Missing Authorization

Credits

Reported by Vishal Shukla(@shukla304) using sechub.dev AI Agent

Support

If this disclosure was useful and if users would like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shoppers thanks those who keeping open source safe.

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`shopper/framework`	≥ 2.8.0&&< 2.9.2	2.9.2

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopper/framework. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update shopper/framework to 2.9.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-56828 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-56828 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to CVE-2026-56828. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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](https://github.com/shopperlabs/shopper/security/advisories/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 rea

O3 Security · Impact-Aware SCA

Is CVE-2026-56828 in your dependencies?

O3 detects CVE-2026-56828 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works