CVE-2026-47745: Missing Authorization in Shopper Admin Panel Settings

Shopper is an open-source, headless e-commerce administration panel constructed using Laravel, Livewire, and the Filament administration framework. Prior to version 2.8.0, the platform exposed an authorization vulnerability within its management interfaces for core e-commerce resources. Specifically, the configuration tables responsible for handling payment methods, store currencies, and logistics carriers did not enforce backend authorization check verification when executing actions or toggling resource statuses.

Because the underlying components rely on Livewire to bind frontend UI events to backend mutations, any authenticated panel user could invoke backend updates directly. The attack surface does not require full administrative privileges to exploit; any user with valid dashboard credentials can interact with the endpoints. This exposure allows unauthorized actions that directly manipulate active configuration states, bypass intended access controls, and compromise shop operation.

This vulnerability is tracked as CVE-2026-47745 and carries a CVSS base score of 6.5. The root weakness lies in missing authorization checks (CWE-862) across multiple Livewire administrative pages. The vulnerability has been resolved in the 2.8.0 release by integrating explicit permission validations before state transitions and action executions occur on the server.

The vulnerability stems from an architectural mismatch between frontend state visibility and backend lifecycle enforcement within the Filament and Livewire ecosystems. In standard Laravel applications, view-level restrictions (such as omitting a button from a blade template) are insufficient for securing underlying application state modifications. Filament tables use interactive components like ToggleColumn to enable rapid, inline modification of database fields via AJAX requests.

When a user interacts with a ToggleColumn or initiates an inline table action such as EditAction or DeleteAction, Filament issues a standardized POST request to the /livewire/update endpoint. This request targets the corresponding Livewire component class on the backend, passing parameter updates and payload states. If the PHP class defining the component lacks explicit authorization constraints on those dynamic interactions, the server processes the state update implicitly.

In the vulnerable versions of Shopper, components such as PaymentMethods, Currencies, and Carriers defined their toggle columns and actions without specifying permission boundaries. Although the user interface might restrict low-privileged users from seeing these administrative tables in standard navigation flows, the Livewire routing handlers remained registered and fully accessible. This allowed any authenticated user to transmit custom Livewire payloads directly to the backend components and bypass visual frontend blocks.

The vulnerability was resolved by appending explicit authorization controls directly onto the Filament component definitions. The primary patch ensures that state modifications initiated via toggle columns execute authorization checks prior to saving changes to the database. Additionally, standard action hooks are explicitly bound to the required permission policy.

In the vulnerable implementation, the ToggleColumn for enabling or disabling carriers did not define any hooks to intercept the update cycle:

// Vulnerable code in Carriers.php
ToggleColumn::make('is_enabled')
    ->label(__('shopper::forms.label.status')),

The patched version integrates the beforeStateUpdated method, forcing the component to authorize the access_setting capability before executing the database write. This prevents unprivileged Livewire requests from mutating the state:

// Patched code in Carriers.php
ToggleColumn::make('is_enabled')
    ->label(__('shopper::forms.label.status'))
    ->beforeStateUpdated(fn (): mixed => $this->authorize('access_setting')),

Furthermore, actions such as editing or deleting records are updated with explicit calls to the native authorize method. For instance, the DeleteAction wrapper now explicitly enforces permissions prior to modal invocation and execution:

// Patched action definition
DeleteAction::make('delete')
    ->label(__('shopper::forms.actions.delete'))
    ->icon(Untitledui::Trash03)
    ->authorize('access_setting')
    ->iconButton(),

This pattern is replicated across all affected administrative screens, including PaymentMethods.php and Currencies.php. This consistent enforcement guarantees that the backend application layer rejects unauthorized Livewire operations before they can affect database state.

Exploitation requires network access to the Shopper administration panel and valid authentication credentials for any low-privileged staff account. The attacker first establishes a session and captures a valid state signature or checksum from any accessible Livewire page. Since Livewire components use a signed checksum (serverMemo.checksum) to verify request integrity, the attacker must obtain a valid base context before crafting modified payloads.

Using an intercepting proxy or browser developer tools, the attacker intercepts or replays a POST request to the /livewire/update endpoint. The attacker structures the JSON body to target the vulnerable components, such as shopper.livewire.pages.settings.payment-methods. Within the payload, the attacker defines a callMethod action aiming to modify database records directly:

{
  "fingerprint": {
    "id": "target-component-id",
    "name": "shopper.livewire.pages.settings.payment-methods",
    "locale": "en",
    "path": "admin/settings/payments"
  },
  "serverMemo": {
    "data": {},
    "checksum": "valid-session-checksum"
  },
  "updates": [
    {
      "type": "callMethod",
      "payload": {
        "method": "updateTableColumnState",
        "params": ["is_enabled", "target-payment-method-uuid", false]
      }
    }
  ]
}

When the backend processes this payload in a vulnerable environment, it routes the request through the updateTableColumnState lifecycle method. Because no authorization callback or policy validation occurs on the server side, the backend executes the state change. The target payment method is disabled instantly, yielding a complete denial of checkout capability for standard customers of the online store.

The security impact of CVE-2026-47745 is concentrated on the integrity and availability of the e-commerce transaction workflow. By disabling active payment methods, carriers, or altering the default currency settings, an attacker can induce an operational denial of service across the entire shopping portal. If all payment gateways are disabled, checkout flows fail globally, preventing customers from placing orders and causing immediate financial damage.

Furthermore, manipulating active currency structures can lead to pricing discrepancies. If an attacker disables a specific currency or changes currency configuration parameters, active products might render with incorrect pricing ratios. This integrity compromise allows malicious low-privileged internal users to degrade customer trust, disrupt processing pipelines, or execute unauthorized business actions.

According to CVSS v3.1 metrics, the flaw carries a base score of 6.5, which represents medium severity. The impact is categorized as high for integrity because administrative configurations can be altered unauthorized, and none for confidentiality as the bug does not leak database records or user credentials directly. However, the operational impact on store availability remains a key risk vector for organizations employing Shopper in production environments.

The primary remediation path is upgrading the Shopper administrative panel installation to version 2.8.0 or higher. This update introduces comprehensive backend validation on all administrative tables. If an immediate upgrade is not feasible, administrators must apply manual code patches to secure the vulnerable components by adding authorization checks to all toggle and action definitions.

composer update shopperlabs/shopper

To detect potential exploitation attempts, security operations teams should monitor web server logs for suspicious traffic patterns targeting Livewire routes. Specifically, audit HTTP POST requests routed to /livewire/update where the payload contains calls to updateTableColumnState on setting components such as shopper.livewire.pages.settings.payment-methods, shopper.livewire.pages.settings.currencies, or shopper.livewire.pages.settings.carriers.

# Conceptual WAF Rule Target
HTTP POST /livewire/update
Body matches: "shopper.livewire.pages.settings.*"
Body matches: "updateTableColumnState"

Additionally, audit application logs for mismatch events where a low-privileged user session issues updates to configuration resources. Enforcing the principle of least privilege on administrative panels restricts the initial compromise surface and prevents unauthorized actors from accessing any portion of the Livewire administration structure.