CVE-2026-110119: Yshopmall Auth Bypass Vulnerability

CVE-2026-110119 Overview

CVE-2026-110119 is an Insecure Direct Object Reference (IDOR) vulnerability affecting Yshopmall through version 2.0.0. The flaw resides in the member address API exposed by UserAddressController, which fails to verify that the authenticated member owns the requested address record. Authenticated attackers can enumerate sequential address identifiers through /address/detail/{id}, /address/del, and /address/edit endpoints. This exposes recipient names, phone numbers, and physical shipping addresses, and permits attackers to overwrite or delete records belonging to other members. The weakness is tracked under CWE-639: Authorization Bypass Through User-Controlled Key.

Critical Impact

Any authenticated member can read, modify, or delete the shipping addresses of every other member, resulting in bulk personally identifiable information (PII) disclosure and integrity loss across the e-commerce platform.

Affected Products

• Yshopmall through 2.0.0
• yshop-app module (UserAddressController.java)
• yshop-mall module (YxUserAddressServiceImpl.java)

Discovery Timeline

• 2026-10-13 - CVE-2026-110119 published to NVD
• 2026-10-14 - Last updated in NVD database

Technical Details for CVE-2026-110119

Vulnerability Analysis

Yshopmall is a Java and Spring Boot based open-source mall platform. The member address API within UserAddressController accepts an address identifier directly from client input and operates on the corresponding record without verifying ownership. According to the VulnCheck advisory, the detail, edit, and delete handlers forward the supplied identifier straight to the service layer. The service in YxUserAddressServiceImpl queries the address by primary key alone and never checks the association between the record's owner uid and the authenticated session's user identifier. Because address identifiers are sequential integers, an attacker can iterate across the identifier space to harvest every stored address.

Root Cause

The root cause is missing object-level authorization in the address service methods. The code path reads the identifier from the URL or request body, loads the record, and executes the requested action without comparing the stored uid against the caller's authenticated user id. This matches the pattern described in [CWE-639].

Attack Vector

Exploitation requires only a valid, low-privileged member account. The attacker authenticates to the application, obtains a session token, and issues sequential requests against /address/detail/{id} to read other members' records. The same token can be reused against /address/edit to overwrite recipient data and against /address/del to remove entries. See the HackMD IDOR analysis for the full request sequence and the GitHub source file for the vulnerable handlers. No exploitation code is reproduced here because no verified public proof-of-concept artifact is available.

Detection Methods for CVE-2026-110119

Indicators of Compromise

• Authenticated sessions issuing high-volume sequential GET /address/detail/{id} requests across non-contiguous uid values.
• POST /address/edit or POST /address/del requests referencing address identifiers that were not previously created or viewed by the same session.
• Application logs showing a single uid interacting with address records whose owning uid differs.

Detection Strategies

• Instrument the address endpoints to log the authenticated uid, the requested address id, and the owning uid of the loaded record, and alert when they diverge.
• Deploy web application firewall (WAF) rules that flag enumeration patterns against /address/detail/, /address/edit, and /address/del.
• Review database audit logs for yx_user_address queries that return rows whose uid column does not match the session user.

Monitoring Recommendations

• Forward Yshopmall application and reverse proxy logs to a centralized SIEM for correlation of per-session request volume and identifier ranges.
• Baseline normal address-API request rates per account and alert on deviations greater than three standard deviations.
• Monitor for unexpected deletions in the yx_user_address table and reconcile against customer-initiated change events.

How to Mitigate CVE-2026-110119

Immediate Actions Required

• Restrict external exposure of the Yshopmall /address/* endpoints until a patched build is deployed.
• Revoke active member session tokens and require re-authentication to invalidate any tokens already used for enumeration.
• Audit the yx_user_address table for records whose update_time or missing rows cannot be attributed to legitimate member activity.

Patch Information

No vendor-released fixed version is listed in the NVD entry or the VulnCheck advisory at the time of publication. Operators maintaining their own fork should modify YxUserAddressServiceImpl so that the detail, edit, and del methods include an owner check (for example, an additional WHERE uid = :currentUid predicate) before returning or mutating any address record. Review the GitHub service implementation for the exact lines requiring hardening.

Workarounds

• Add a Spring interceptor or AOP aspect that resolves the authenticated uid from the security context and rejects requests whose target address uid does not match.
• Replace sequential primary keys with unguessable UUIDs for address records to raise the cost of enumeration while the authorization fix is prepared.
• Rate-limit the address API at the gateway to constrain mass enumeration by a single account.

# Example nginx rate-limit snippet for the address API
limit_req_zone $binary_remote_addr zone=addr_api:10m rate=5r/s;

location ~ ^/address/(detail|edit|del) {
    limit_req zone=addr_api burst=10 nodelay;
    proxy_pass http://yshopmall_backend;
}