CVE-2026-72843: EverShop Missing Authorization on PATCH /api/customers/:id Allows Unauthenticated Account Takeover
The customer update route in EverShop is declared with "access": "public" in packages/evershop/src/modules/customer/api/updateCustomer/route.json, which causes the admin authentication middleware to call next() without checking the caller, and no customer-session middleware guards the route; the only middleware in the chain parses the JSON body. The handler in updateCustomer.js then loads the customer by the uuid taken from the URL path and writes the supplied fields back to that record, hashing a password if one is provided, without verifying that the caller owns the record. An unauthenticated request carrying a known customer uuid can therefore overwrite that customer's email address and password and read back the updated record from the 200 response, taking over the account and locking out its owner. Customer uuids are exposed through order confirmation email links and administrative URLs. Version 2.2.1 changes the route to "access": "private".
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
EverShopto a version that resolves this vulnerability.Fixed in 2.2.1 - Configuration
Change the customer update route declaration from "access": "public" to "access": "private" so the admin authentication middleware enforces caller authentication instead of calling next() unconditionally.
EverShop customer update route (packages/evershop/src/modules/customer/api/updateCustomer/route.json) access = private
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
An attacker needs only a known customer UUID and the ability to send an unauthenticated PATCH request to the customer update endpoint. Customer UUIDs may be available in order-confirmation email links and administrative URLs.
Are default deployments affected?
Deployments using the affected route configuration are exposed because the route is declared public and has no customer-session authorization check. No authenticated account, administrative access, or user interaction is required.
What can an attacker change or obtain?
An attacker can overwrite the targeted customer's email address and password, enabling account takeover and potentially locking out the legitimate owner. The endpoint also returns the updated customer record in its successful response.
What should be done if upgrading is not immediately possible?
Restrict or block unauthenticated access to the customer update endpoint at a reverse proxy, firewall, or other request-filtering layer until the route can be changed to require private access. Version 2.2.1 changes the route access setting to private.
How can defenders look for exploitation?
Review requests to the customer update endpoint for unauthenticated PATCH operations and correlate them with unexpected customer email or password changes. Pay particular attention to updates involving customer UUIDs that may have been exposed through order-confirmation links or administrative URLs.