Description

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".

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-20T22:18:05.253Z",
  "pubdate": "2026-08-20T22:18:05.253Z",
  "executiveSummary": "An unauthenticated account takeover vulnerability exists in EverShop within the customer update API route located at packages/evershop/src/modules/customer/api/updateCustomer/route.json.\nThe vulnerability arises due to improper access control configuration where the route is incorrectly declared with \"access\": \"public\", causing the admin authentication middleware to bypass checks and lacking any customer-session middleware protection.\nConsequently, unauthenticated remote attackers can supply a known customer uuid via the URL path and arbitrary data in the JSON body to updateCustomer.js.\nThis allows malicious actors to overwrite a victim's email address and password without verifying ownership of the target record.\nSuccessful exploitation results in immediate account takeover, credential resetting that locks out the legitimate owner, and exposure of updated customer data returned in the HTTP 200 response.\nTarget customer UUIDs are considered predictable or discoverable as they are exposed through order confirmation email links and administrative URLs.\nThe issue affects EverShop versions prior to 2.2.1 and presents a critical risk to user data integrity and authentication mechanisms.",
  "technicalDetails": "The root cause of the vulnerability stems from a misconfiguration in the route declaration file packages/evershop/src/modules/customer/api/updateCustomer/route.json, where the access control level is explicitly set to \"access\": \"public\".\nBecause of this setting, the internal administrative authentication middleware evaluates the request and immediately invokes next() without validating the identity or permissions of the caller.\nAdditionally, no customer-session middleware guards the route to ensure that the session context matches the targeted resource, and the only active middleware in the execution chain is responsible solely for parsing the incoming JSON body.\nThe vulnerable handler function within updateCustomer.js extracts the customer identifier directly from the uuid parameter provided in the URL path.\nIt then takes the supplied fields from the parsed JSON body and writes them directly back to the corresponding database record, automatically hashing any provided password string, without performing any authorization checks to verify whether the unauthenticated caller owns the target record.\nThe attack flow proceeds as follows: First, an attacker obtains a target customer uuid, which is typically exposed via order confirmation email links or administrative URLs.\nSecond, the attacker crafts an unauthenticated HTTP request directed at the updateCustomer API route, inserting the victim's uuid into the URL path and providing malicious payload data containing a new email address and a new password.\nThird, the EverShop application processes the request, bypasses access checks due to the public route declaration, and executes the updateCustomer.js handler.\nFourth, the database record is updated, overwriting the victim's credentials and email address.\nFinally, the application returns a 200 response containing the updated customer record, confirming the successful takeover.\nPost-exploitation impact includes full account compromise, unauthorized data access returned in the response body, and denial of access for the legitimate owner due to password modification."
}