CVE-2026-72843

CVE-2026-72843 in EverShop's customer-update endpoint earns its CVSS 9.8, but the deeper story is what the vulnerability reveals about the access control architecture — and that story matters more than the patch. The technical reality: the route handler at updateCustomer.js accepts any authenticated request, but the authentication layer consists only of JSON body parsing. No customer-session validation exists in the middleware chain. The route.json file declares 'access': 'public', which should gate the endpoint — except nothing actually enforces this field. The security declaration lives in one file, disconnected from any enforcement logic. That's the core architectural failure. When the fix is 'public' → 'private', you've proven the entire security posture hinged on a config string, not on actual authorization code. What's worse: you don't need to guess the customer UUID. It leaks through order confirmation emails sent to the targeted customer and through admin-panel URLs visible in any browser's address bar. An attacker with a customer's email address — which is trivially obtainable — receives the UUID directly in their inbox. Then they call the update endpoint with that UUID, receive a 200 OK with the modified customer record in the response body, and the attack is complete. This is not a brute-force scenario. It's a direct path. The pattern is old. Django, Rails, Express — all have suffered the same structural failure: a declarative annotation that lives apart from enforcement, giving developers false confidence that authorization exists when it doesn't. The difference in EverShop is the UUID bleed-through compounding the authorization gap. What you should do: First, grep your entire codebase for routes declaring 'access': 'public' or 'access': 'private' and audit each one's middleware chain for actual authorization checks. The mismatch is the vulnerability signature. Second, audit where customer UUIDs appear outside authenticated contexts — order emails, admin URLs, API responses, logs. Any channel exposing the identifier is an enumeration vector. Third, treat the 'public'/'private' declaration system as a warning sign: if security depends on a config field matching reality, your architecture is one refactor away from a bypass. The right fix isn't toggling the string — it's ensuring every protected route has explicit middleware that validates the session, independent of any declaration file.

Reviewed through automated stages and approved by a human before publication.