CVE-2026-111607 in Jeepay
Summary
by MITRE • 10/16/2026
Jeepay through 3.2.9 contains an insecure direct object reference vulnerability that allows authenticated merchant users to overwrite another merchant application's payment channel configuration by supplying a victim infoId to MchPayInterfaceConfigController.saveOrUpdate. Attackers holding the default ENT_MCH_PAY_CONFIG_ADD permission can replace signing keys, certificates, and fee rates to break or redirect the victim merchant's payment processing.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in Jeepay versions up to 3.2.9 represents a critical insecure direct object reference (IDOR) flaw within the application’s merchant management interface. This security defect specifically affects the MchPayInterfaceConfigController.saveOrUpdate endpoint, which is responsible for managing payment channel configurations for merchants. The core issue lies in the server-side logic failing to validate whether the authenticated user requesting the update has ownership or administrative rights over the specific resource identified by the infoId parameter provided in the request payload. Instead of binding the operation strictly to the context of the currently logged-in merchant, the application blindly trusts the identifier supplied by the client side, allowing an attacker to manipulate configuration data belonging to other entities within the system.
From a technical perspective, this vulnerability exploits the lack of proper authorization checks on sensitive business logic operations. An authenticated user possessing the default ENT_MCH_PAY_CONFIG_ADD permission can craft HTTP requests that target arbitrary infoId values corresponding to victim merchants. By doing so, the attacker gains the ability to overwrite critical payment channel settings associated with those victims. This includes modifying signing keys and certificates used for transaction authentication as well as altering fee rate configurations. The absence of object-level access control means that the application does not verify if the requesting user’s merchant ID matches the merchant ID associated with the target configuration, thereby bypassing intended isolation boundaries between different merchants in a multi-tenant environment.
The operational impact of this vulnerability is severe and potentially catastrophic for affected payment processing operations. By replacing signing keys or certificates, an attacker can effectively break the cryptographic integrity required to process legitimate transactions, leading to service denial for the victim merchant as their payments fail validation checks by acquiring banks or payment gateways. Alternatively, if the attacker modifies configurations in a way that retains functional validity but redirects funds, they could intercept and divert financial transactions intended for the victim. Furthermore, altering fee rates can cause significant financial discrepancies, either charging customers incorrectly or causing revenue loss to the merchant due to misconfigured commission structures. This capability undermines trust in the platform’s ability to isolate tenant data and secure sensitive financial configurations.
This vulnerability aligns with CWE-639, which describes Insecure Direct Object References, where a web application exposes internal implementation objects such as database keys or file names directly to users without sufficient access control checks. Additionally, from an offensive security perspective, this behavior is consistent with MITRE ATT&CK technique T1078, specifically the Valid Accounts sub-technique, where attackers leverage legitimate credentials to perform unauthorized actions within a system. The exploitation path relies on authenticated access rather than unauthenticated intrusion, highlighting that identity verification alone is insufficient without robust authorization mechanisms enforcing resource-level permissions.
To mitigate this vulnerability, immediate remediation efforts should focus on implementing strict object-level authorization checks within the MchPayInterfaceConfigController.saveOrUpdate method. Developers must ensure that every update operation verifies that the authenticated user’s merchant ID matches the merchant ID associated with the target configuration identified by infoId before allowing any modifications to signing keys, certificates, or fee rates. Input validation should also be enforced to prevent injection attacks through these parameters. Beyond code fixes, it is advisable to conduct a comprehensive audit of other endpoints handling sensitive business data to identify similar patterns where direct object references are used without proper ownership verification. Regular security testing and adherence to secure coding standards such as OWASP Top Ten guidelines will help prevent recurrence of such authorization flaws in future releases.