Apache Fineract CVE-2025-58137

Exploitation requires an authenticated, low-privileged Fineract account (CVSS PR:L) with network access to the application's APIs; no user interaction or elevated privileges are needed. The core prerequisite is the ability to supply a user-controlled key/identifier (CWE-639) that the application uses to locate a resource without verifying the caller is authorized for that specific object - allowing horizontal access to other users', clients', or tenants' data. Limiting factors: the attacker must already hold valid credentials and needs to reference valid object identifiers; this is not an unauthenticated or default-anonymous attack, which materially narrows the realistic attacker set to insiders, compromised accounts, or legitimate tenants in multi-tenant deployments. Affected versions are Apache Fineract through 1.11.0 (fixed in 1.12.1; upgrade to 1.13.0).

This is a genuine but moderate-priority issue rather than a top-tier emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N) describes a network-reachable, low-complexity flaw requiring only low-privileged authentication - meaning any legitimate but limited Fineract account holder can exploit it, with high confidentiality and integrity impact (C:H/I:H) but no availability loss (A:N), consistent with the CWE-639 IDOR pattern of reading/modifying other tenants' or users' records via a user-controlled identifier. The signals are internally consistent and point to lower urgency: EPSS is only 0.39% (31st percentile), the CVE is NOT on CISA KEV, and no public exploit code is referenced in the provided data. There is no conflict between CVSS and EPSS here - a high base score with low exploitation probability is expected for an authenticated IDOR in a specialized banking platform, since it requires valid credentials and is not mass-scannable like an unauthenticated RCE. SSVC-style reasoning: exploitation status is 'none' observed, automatable is likely 'no' (requires authenticated session and knowledge of valid object keys), technical impact is 'total' for the affected data. The net result is a real security issue that institutions running Fineract should patch, but not evidence of active, widespread exploitation.

A low-privileged but authenticated Fineract user (e.g. a limited staff account or a tenant in a multi-tenant deployment) sends API requests substituting another user's or client's resource identifier in a user-controlled key parameter. Because authorization is not properly enforced against that key, the attacker reads or modifies financial records belonging to other principals. No public exploit code is referenced in the provided data, and no user interaction is required.