crmeb_java CVE-2026-111354

Requires a valid authenticated crmeb_java member account (PR:L) - exploitation is not possible pre-authentication. The attacker then requests /api/front/order/express/{orderId} or /api/front/order/apply/refund/{orderId} supplying order identifiers belonging to other members, because neither endpoint checks that the order belongs to the requesting session. Practical limits: an account on the target storefront is mandatory, the attacker must supply or enumerate valid victim order IDs, and the exposure is confined to order metadata (tracking numbers, logistics traces, payment amounts, product lines) with no write, modification, or service-impact capability. Affects crmeb_java versions through 3.1.

This is a genuine but low-severity authorization flaw (IDOR / CWE-639), not a high-priority emergency. The vendor-supplied CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:L, base 2.3) agrees with the description on the key points: exploitation is network-reachable but requires an authenticated low-privileged member account (PR:L) and yields only a low-confidentiality read of another member's order metadata (VC:L) with no integrity or availability impact. There is no CISA KEV listing and no exploit code flagged in the input, so exploitation status is 'no public exploit identified at time of analysis'; EPSS was not provided. The one signal that pushes risk slightly above the vendor score is that a detailed public write-up (the hackmd advisory) names the exact vulnerable endpoints and the three OrderServiceImpl code locations, lowering the research barrier - this is why I assess AC:L rather than the vendor's AC:H. Net: a confirmed real bug worth patching on a normal cycle, but it exposes order PII to logged-in users only and does not warrant emergency escalation.

A registered customer of a crmeb_java-powered storefront logs into their own account, then changes the {orderId} path parameter on /api/front/order/express/{orderId} or /api/front/order/apply/refund/{orderId} to identifiers belonging to other customers. Because the endpoints do not verify order ownership against the session, the attacker reads victims' tracking numbers, logistics traces, payment amounts and purchased product lines. No exploit code is published, but a public technical write-up documents the exact endpoints and vulnerable service methods.