Summary
Jeepay contains an insecure direct object reference in the merchant payment configuration update flow. An authenticated merchant user with the relevant default permission may supply another merchant's identifier and modify payment channels, signing material, certificates, or fee rates.
Jeepay contains an insecure direct object reference in the merchant payment configuration update flow. An authenticated merchant user with the relevant default permission may supply another merchant's identifier and modify payment channels, signing material, certificates, or fee rates.
Affected context
The issue occurs in Jeepay's merchant payment configuration management, specifically the MchPayInterfaceConfigController.saveOrUpdate operation. It becomes risky when authorization checks rely on a caller-controlled infoId without confirming that the referenced payment configuration belongs to the authenticated merchant. Deployments that grant the default ENT_MCH_PAY_CONFIG_ADD permission to merchant users may expose this cross-merchant modification path.
The issue occurs in Jeepay's merchant payment configuration management, specifically the MchPayInterfaceConfigController.saveOrUpdate operation. It becomes risky when authorization checks rely on a caller-controlled infoId without confirming that the referenced payment configuration belongs to the authenticated merchant. Deployments that grant the default ENT_MCH_PAY_CONFIG_ADD permission to merchant users may expose this cross-merchant modification path.
Exploit preconditions
- Attack surface: Authenticated merchant payment configuration endpoint
- Required access: A valid merchant account with the applicable payment-configuration permission
- Trigger point: A configuration save or update request handled by
MchPayInterfaceConfigController.saveOrUpdate - Why exploitation is possible: The referenced merchant object may be selected through a caller-supplied identifier without adequate ownership or tenant-bound authorization checks
- Attack surface: Authenticated merchant payment configuration endpoint
- Required access: A valid merchant account with the applicable payment-configuration permission
- Trigger point: A configuration save or update request handled by
MchPayInterfaceConfigController.saveOrUpdate - Why exploitation is possible: The referenced merchant object may be selected through a caller-supplied identifier without adequate ownership or tenant-bound authorization checks
Why this happens
The vulnerability is caused by treating a client-provided object identifier as sufficient authority to access or modify a payment configuration. This is an insecure direct object reference, mapped to CWE-639, because authorization is not reliably enforced for the relationship between the authenticated merchant and the referenced resource. The insecure pattern allows object lookup and update decisions to be separated from tenant ownership validation.
The vulnerability is caused by treating a client-provided object identifier as sufficient authority to access or modify a payment configuration. This is an insecure direct object reference, mapped to CWE-639, because authorization is not reliably enforced for the relationship between the authenticated merchant and the referenced resource. The insecure pattern allows object lookup and update decisions to be separated from tenant ownership validation.
Potential impact
- An attacker may overwrite another merchant's payment channel configuration
- Payment processing could be disrupted or redirected
- Signing keys or certificates could be replaced, potentially affecting transaction authentication
- Fee rates could be altered, causing financial or reconciliation issues
- Cross-merchant data integrity and tenant isolation could be weakened
- An attacker may overwrite another merchant's payment channel configuration
- Payment processing could be disrupted or redirected
- Signing keys or certificates could be replaced, potentially affecting transaction authentication
- Fee rates could be altered, causing financial or reconciliation issues
- Cross-merchant data integrity and tenant isolation could be weakened
General mitigation guidance
Mitigation generally focuses on enforcing object-level authorization at every read and write boundary.
Common defensive patterns include:
- Deriving the target merchant or tenant from the authenticated session rather than trusting a client-supplied identifier
- Verifying resource ownership and tenant scope before loading or updating configuration
- Applying deny-by-default authorization policies to sensitive payment configuration operations
- Separating administrative and merchant permissions using least privilege
- Validating signing material, certificates, and fee settings with controlled workflows and audit trails
- Requiring explicit reauthorization or approval for high-impact configuration changes
Mitigation generally focuses on enforcing object-level authorization at every read and write boundary.
Common defensive patterns include:
- Deriving the target merchant or tenant from the authenticated session rather than trusting a client-supplied identifier
- Verifying resource ownership and tenant scope before loading or updating configuration
- Applying deny-by-default authorization policies to sensitive payment configuration operations
- Separating administrative and merchant permissions using least privilege
- Validating signing material, certificates, and fee settings with controlled workflows and audit trails
- Requiring explicit reauthorization or approval for high-impact configuration changes
How teams detect issues like this
Organizations can detect similar weaknesses through:
- Static analysis and code review checks for update operations that use request identifiers without ownership predicates
- Review of controller and service methods for missing tenant, merchant, or subject-level authorization
- Tests that attempt cross-merchant access using valid accounts from different tenants
- API policy enforcement requiring resource scope to match authenticated identity
- Audit monitoring for payment configuration changes involving unexpected merchant identifiers, certificates, keys, or fee rates
- Automated application security testing focused on authorization and object-level access control
Organizations can detect similar weaknesses through:
- Static analysis and code review checks for update operations that use request identifiers without ownership predicates
- Review of controller and service methods for missing tenant, merchant, or subject-level authorization
- Tests that attempt cross-merchant access using valid accounts from different tenants
- API policy enforcement requiring resource scope to match authenticated identity
- Audit monitoring for payment configuration changes involving unexpected merchant identifiers, certificates, keys, or fee rates
- Automated application security testing focused on authorization and object-level access control
