Roncoo-pay EUVD-2026-103011

Exploitation requires that the Roncoo-pay web gateway F2FPayController.orderQuery endpoint be network-reachable and that the attacker supply a valid trxNo parameter; no authentication, privileges, or user interaction are needed (PR:N/UI:N), so default deployments exposing the gateway are directly affected. The key LIMITING factor is that the attacker must know or successfully guess a valid transaction number - a '7' prefix plus a snowflake ID - which, being time-ordered and partially predictable, is enumerable but non-trivial and accounts for the AC:H/AT:P rating. Impact is confined to disclosure of serialized payment records; there is no write, modification, or availability effect.

This is a genuine but complexity-limited information-disclosure flaw (CWE-306, missing authorization) in the Roncoo-pay F2FPayController.orderQuery endpoint. The provided CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H) tells a consistent story: it is network-reachable and requires no privileges or user interaction (PR:N/UI:N), but carries both high attack complexity (AC:H) and a present attack requirement (AT:P), reflecting that an attacker cannot simply call the endpoint - they must supply a valid trxNo. The headline 8.2 score is driven almost entirely by the confidentiality impact (VC:H) against unauthenticated access; integrity and availability are untouched (VI:N/VA:N), so this is purely a data-exposure issue, not RCE or tampering. No EPSS score and no KEV status were provided in the input, and there is no explicit POC flag, though a detailed third-party technical writeup is referenced. The practical risk is moderated by the AC:H/AT:P requirement to guess transaction numbers: because trxNo is a '7' prefix plus a snowflake ID (time-ordered, partially predictable), enumeration is feasible but not trivial, pointing to targeted/low-noise harvesting rather than mass automated exploitation. Net assessment: a real priority for anyone actually running Roncoo-pay in production given the direct exposure of merchant payment records, but tempered by niche deployment and non-trivial enumeration. No EPSS or KEV data was supplied - exploitation probability cannot be quantified from the input.

An unauthenticated attacker repeatedly calls the public orderQuery endpoint, supplying guessed trxNo values built from a '7' prefix plus a snowflake ID whose time-ordered structure narrows the search space. On a valid hit the server returns the full serialized payment record of any merchant, exposing transaction and payment details. A detailed technical writeup describing this methodology is referenced, though no explicit weaponized exploit flag is present in the input.