CVE-2026-47744 - Shopper team RBAC privilege escalation

Shopper framework versions before 2.8.0 had two authorization defects in the admin panel team settings. One team settings component could be mounted by any authenticated panel user, exposing public actions such as creating roles and deleting users. Another role-permission component allowed write actions based on the read-only view_users permission, letting a low-privilege user grant themselves or another account powerful permissions such as manage_users and edit_orders.

For ecommerce and admin panels, this is a control-plane takeover issue. A correct remediation upgrades the framework, verifies authorization gates on team settings writes, reviews role state for unexpected escalation, and adds tests that prove read-only users cannot mutate RBAC.

When to use it

Use this recipe when a Laravel Shopper deployment exposes team, staff, role, or permission management to non-owner admins, delegated operators, or tenant-like commerce teams. It is designed for source-code remediation, RBAC boundary review, privilege-escalation regression testing, and evidence that lower roles cannot assign themselves or others broader team/admin powers.

Inputs

  • shopper/framework version, Composer lock state, team/role policies, Livewire team components, permission matrix, invitation flows, and generated dependency reports.
  • Source paths for team management, role assignment, policy checks, Livewire actions, invite/update/delete handlers, custom admin overrides, and tests.
  • Regression fixtures for low-privilege users, owners/admins, attempted role escalation, cross-team changes, direct wire calls, and expected 403/audit behavior.
  • Boundary evidence: admin/team role matrix, affected users, audit logs, session/API key rotation needs, rollout owner, and account-review owner.

Affected versions

  • Vulnerable package: shopper/framework <2.8.0
  • Fixed package: shopper/framework 2.8.0
  • Affected package manager: Composer
  • Affected surfaces: admin panel team settings, Settings/Team/Index, Settings/Team/RolePermission, role creation, user deletion, and role-permission writes
  • Required attacker capability: authenticated panel account, including a low-privilege account with read-only user visibility

Indicator-of-exposure

  • The repository depends on, vendors, forks, or deploys shopper/framework before 2.8.0.
  • The application exposes Shopper admin panel team settings to accounts that are not fully trusted administrators.
  • Roles such as view_users, support, merchandiser, operator, auditor, or read-only admin can access team-management views or Livewire actions.
  • Product code customizes Shopper team settings, policies, middleware, Livewire components, authorization gates, role permissions, or admin routes.
  • The admin panel can mutate users, roles, permissions, orders, products, carriers, currencies, payment methods, refunds, or customer data.

Quick checks:

rg -n "shopper/framework|shopper/admin|Settings/Team|RolePermission|view_users|manage_users|edit_orders|Livewire|Gate::|authorize\\(|can\\(|team settings|roles|permissions" .
composer show shopper/framework shopper/admin
composer why shopper/framework
rg -n "shopper/framework|shopper/admin|SHOPPER|view_users|manage_users|Settings/Team" composer.json composer.lock config routes app resources tests . 2>/dev/null

Windows:

rg -n "shopper/framework|shopper/admin|Settings/Team|RolePermission|view_users|manage_users|edit_orders|Livewire|Gate::|authorize\\(|can\\(|team settings|roles|permissions" .
composer show shopper/framework shopper/admin
composer why shopper/framework
rg -n "shopper/framework|shopper/admin|SHOPPER|view_users|manage_users|Settings/Team" composer.json composer.lock config routes app resources tests .

Do not attempt privilege escalation in production, create admin roles through low-privilege accounts, delete users, or export customer/admin data during triage.

Remediation strategy

  • Upgrade every controlled shopper/framework or Shopper admin package reference, Composer lockfile, deployment image, generated dependency report, and SBOM to 2.8.0+.
  • Preserve the existing Shopper/Laravel release line unless the application already has an approved broader framework upgrade.
  • Verify custom team settings code requires manage_users or the local administrator-equivalent permission for mount, create, update, delete, and role-permission write actions. Read-only permissions such as view_users must not authorize writes.
  • Add regression tests for low-privilege authenticated users, view_users users, non-admin panel users, and real admins. Tests should cover component mount and each team/RBAC mutation path.
  • Review roles, permissions, team audit logs, and admin user deletions during the exposure window if untrusted panel users had access to affected versions.

The prompt

You are remediating CVE-2026-47744 / GHSA-c3qp-2ggw-xjg7, a critical Shopper
framework team-settings authorization bypass and RBAC privilege escalation.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades Shopper, verifies
  authorization gates on team/RBAC writes, adds safe regression tests, refreshes
  generated artifacts, and documents operator review, or
- TRIAGE.md if this repository does not own an affected Shopper admin panel or
  cannot safely patch the deployment.

## Rules

- Scope only CVE-2026-47744 / GHSA-c3qp-2ggw-xjg7 and directly related
  Shopper team-settings authorization and RBAC controls.
- Treat admin sessions, role assignments, user records, order data, payment
  metadata, customer data, audit logs, application secrets, and database
  credentials as sensitive.
- Do not attempt production privilege escalation, create unauthorized admin
  roles, delete users, mutate customer/order/payment data, export sensitive
  data, or bypass audit logging during validation.
- Do not remove RBAC tests, admin policies, audit logs, or approval gates just
  to silence the advisory.
- Do not auto-merge.

## Steps

1. Inventory all Shopper references in `composer.json`, `composer.lock`,
   package constraints, Dockerfiles, deployment images, generated dependency
   reports, SBOMs, admin panel routes, Livewire components, policies, gates,
   middleware, and local forks or overrides.
2. Determine every resolved Shopper version. A target is vulnerable if
   `shopper/framework` resolves below `2.8.0`.
3. Search for customizations around team settings and RBAC:
   `Settings/Team/Index`, `Settings/Team/RolePermission`, `view_users`,
   `manage_users`, `edit_orders`, role writes, user deletion, Livewire actions,
   policies, gates, and admin panel middleware.
4. If the repository does not deploy Shopper admin panel code, stop with
   `TRIAGE.md` listing checked files, external owner if known, and required
   fixed version.
5. Upgrade affected Shopper packages to `2.8.0+`. Refresh `composer.lock`,
   container layers, generated dependency reports, SBOMs, deployment manifests,
   and docs that pin or install Shopper.
6. Verify or patch authorization:
   - team settings component mount requires `manage_users` or local
     administrator-equivalent authority;
   - role creation, role deletion, user deletion, role-permission updates, and
     permission grants require write authority, not `view_users`;
   - custom Livewire actions call explicit authorization before mutation;
   - route/middleware checks do not replace per-action authorization.
7. Add safe regression tests:
   - unauthenticated users cannot reach team settings;
   - low-privilege panel users cannot mount or call team mutation actions;
   - `view_users` users can read allowed user data but cannot create roles,
     delete users, or grant permissions;
   - real admins with `manage_users` can still perform intended team actions;
   - failed attempts are logged without leaking customer/admin data.
8. Add a PR body section named `CVE-2026-47744 operator actions` that states:
   - Shopper versions before and after;
   - whether local team/RBAC customizations exist;
   - which roles can manage users and permissions after the patch;
   - whether any unexpected role grants, admin deletions, or permission changes
     were found in the exposure window;
   - whether session revocation, password reset, or administrator credential
     rotation is needed;
   - which validation commands passed.
9. Run available validation: Composer install/check-platform-reqs, lockfile
   integrity, Laravel/PHP unit and feature tests, Livewire component tests,
   static analysis, lint, migration checks, dependency/security scans, SBOM
   refresh, and non-secret admin smoke checks.
10. Use PR title:
    `fix(sec): remediate CVE-2026-47744 in Shopper RBAC`.

## Stop conditions

- No affected Shopper package, admin panel, local fork, deployment image, or
  team/RBAC customization is controlled by this repository.
- Shopper is owned by another application or platform team; name the owner and
  required fixed version in `TRIAGE.md`.
- Upgrading to `2.8.0+` requires a broader Laravel/PHP migration or maintenance
  window the agent cannot schedule.
- Verification would require production privilege escalation, user deletion,
  sensitive data export, or live admin mutation outside a controlled test
  environment.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades Shopper, adds fail-closed team/RBAC authorization checks, adds privilege-escalation tests, and documents account/audit review.
  • Or a TRIAGE.md file that lists inspected components/policies, owner, observed version, team/RBAC boundary, required fix, and residual risk.
  • The output must include exact validation commands and must not promote real users, expose admin data, or weaken team permission checks.

Verification - what the reviewer looks for

  • No controlled Composer lockfile, image, SBOM, generated report, or package manifest resolves shopper/framework <2.8.0.
  • Team settings mount and write actions require manage_users or a local administrator-equivalent permission.
  • view_users grants read-only visibility only and cannot mutate roles, permissions, or users.
  • Regression tests cover both denied low-privilege paths and allowed admin paths.
  • Operator notes cover role review, unexpected admin deletion, permission changes, and session or credential cleanup when needed.

Watch for

  • Updating composer.json while composer.lock, image layers, or generated dependency evidence still install an affected Shopper version.
  • Trusting route-level admin middleware while Livewire public actions still lack per-action authorization.
  • Allowing view_users or similar read-only permissions to guard writes.
  • Testing only happy-path admin behavior and missing denied low-privilege cases.
  • Printing customer data, order data, role assignments, or admin sessions in validation logs.

References