BizSpring Shop CVE-2026-110607

Requires an authenticated buyer-level account on a BizSpring Shop or BizSpring Java Mall instance (PR:L) and network reachability to the member payment endpoints. The attacker must be able to (1) call /member/payment/load to generate a payment log and obtain a paymentLogSn, then (2) invoke the /member/payment/test_post_pay_{paymentLogSn} handler (PaymentController.testPostPay), which is a test/debug payment path that bypasses real payment verification. The IDOR variant additionally requires knowing or enumerating another member's paymentLogSn to settle their orders. Limiting factors: exploitation needs a valid logged-in account (not fully unauthenticated), the store must be deployed at or near commit cf22d39daaf1 with the test_post_pay handler exposed to member-facing requests, and no evidence of a patched release is provided to confirm which versions remain affected.

This is a credible but bounded business-logic risk rather than a wormable emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N) scores 7.1 (High) and is internally consistent with the description: a network-reachable endpoint, low attack complexity, and low privileges (PR:L - an ordinary authenticated buyer account), with the entire impact concentrated in integrity (VI:H) - forging payment/order state - and no confidentiality or availability impact. That integrity-only, authenticated profile matches CWE-345 (insufficient verification of data authenticity) precisely: the PaymentController.testPostPay handler trusts a client-reachable 'test pay' path to settle orders. No EPSS score, CISA KEV listing, SSVC decision, or formal POC flag is present in the provided data, so there is no evidence of active exploitation; per the rules this is 'no public exploit identified at time of analysis.' However, the referenced public hackmd write-ups and the exact GitHub source lines (PaymentController.java#L76-L84, PaymentLogServiceImpl.java#L143-L169) make the vulnerable code path fully disclosed and trivially reproducible, so practical exploitability is high even without a packaged exploit. Net: a real priority for anyone actually running BizSpring Shop / BizSpring Java Mall because it directly enables financial fraud (obtaining goods without paying, settling others' orders) at low skill, but overall fleet-wide risk is tempered by the product's limited deployment footprint and the requirement for an authenticated account.

An attacker registers or uses an existing buyer account on a BizSpring Shop / Java Mall store, places an order, and calls /member/payment/load to generate a payment log. They then request /member/payment/test_post_pay_{paymentLogSn}, which marks the order as paid without any real payment, obtaining goods for free; by substituting another member's paymentLogSn (IDOR) they can also settle other users' orders. No packaged exploit is flagged in the data, but the vulnerable endpoints and source lines are publicly documented, making reproduction straightforward (AV:N/AC:L, authenticated buyer).