Jeepay EUVD-2026-103029

Requires an authenticated Jeepay merchant-portal account holding the default ENT_MCH_PAY_CONFIG_ADD permission, and the attacker must know or enumerate the victim merchant application's infoId to target it via the POST pay-config API (MchPayInterfaceConfigController.saveOrUpdate). Exploitation is limited to parties who can obtain a merchant account on the platform, making it primarily a multi-tenant isolation / malicious-insider threat; it is most impactful on shared Jeepay deployments serving multiple independent merchants and largely irrelevant on single-tenant installations. No user interaction and no non-default configuration are required - the enabling permission is granted by default.

This is a genuine but bounded risk - a CWE-639 insecure direct object reference (IDOR) in the Jeepay merchant portal. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L) is internally consistent with the description: network-reachable API, low complexity, and crucially PR:L, meaning exploitation requires an authenticated merchant account - so this is NOT an unauthenticated internet-wide threat. The primary impact is integrity (VI:H): an attacker overwrites another merchant's signing keys, certificates, and fee rates, with a secondary availability impact (VA:L) from broken payment processing. No EPSS score, KEV listing, or explicit POC flag was supplied in the input; however, the referenced hackmd writeup and the exact source-code line range (MchPayInterfaceConfigController.saveOrUpdate L146-L186) provide a detailed technical blueprint that substantially lowers the bar to weaponization even though no packaged exploit is confirmed. The signals do not conflict, but note the tension between a 7.1 'High' score and the real-world precondition that an attacker must already be a provisioned, authenticated merchant holding the default ENT_MCH_PAY_CONFIG_ADD permission - this makes it a strong insider/tenant-isolation (multi-tenancy) threat rather than a mass-exploitation candidate. Treat as a real priority for any multi-merchant Jeepay deployment, but lower urgency for single-tenant or internal-only instances.

A legitimate but malicious merchant registers (or compromises an existing low-privilege merchant account) on a shared Jeepay platform and, holding the default ENT_MCH_PAY_CONFIG_ADD permission, sends a crafted POST to the pay-config API supplying a victim merchant's infoId instead of their own. Because the server does not verify the infoId belongs to the caller, the attacker overwrites the victim's payment channel signing keys, certificates, and fee rates - breaking or redirecting the victim's payment flow. No public packaged exploit is confirmed, but a detailed technical writeup pinpointing the vulnerable method exists in the references.