The CVSS 7.1 score for this vulnerability likely understates its actual risk profile in multi-company ERPNext deployments. The critical issue isn't whether authenticated users can read more data than intended — it's that this dynamic-link permission bypass sits at the intersection of two separate permission systems (Customer/Supplier user permissions and company-level data isolation) that are supposed to operate independently. When prepare_conditions fails to apply Customer and Supplier user permissions to the Payment Ledger Entry's party field, it bridges the gap between companies that should be hermetically sealed in a shared instance. For managed services providers or shared hosting environments running multiple tenants through the same ERPNext instance, the cross-company exposure is existential — not a 7.1 scenario but potentially a 9.x one.
The dynamic-link field type deserves specific attention. Frappe's dynamic-link mechanism allows a single field to reference multiple doctypes, which creates permission-checking complexity that developers consistently underestimate. The permission check was likely absent by design — developers assumed downstream row-level filters would catch this — or simply overlooked when Payment Ledger Entry was added as a data source. The question of whether this is a specific implementation flaw or evidence of a broader architectural gap determines whether similar bypasses exist in other reports consuming Payment Ledger Entry data.
For threat modeling, the 'any authenticated user' phrasing is doing significant work. In ERPNext with role-based access controls, very few users have zero assigned roles. The practical exploitability depends on whether a minimal-privilege user (someone with just 'Employee' permissions) can trigger the report, or whether you need baseline report access to reach the vulnerable code path. That distinction matters for prioritization.
The fix in 15.112.0 and 16.23.0 needs scrutiny: does it patch the specific prepare_conditions call, or add a framework-level handler for dynamic-link fields in permission contexts? If it's the former, you're playing whack-a-mole with every report author. If it's the latter, that's architecturally correct — and should be documented as a security-sensitive API change.
Be aware of forked and custom reports. Any customized ReceivablePayableReport or homegrown report that imported the original prepare_conditions function continues running the vulnerable pattern indefinitely. The patch closes the official door while forks remain wide open.
Historical patterns in other enterprise software (SAP, Oracle E-Business Suite, Microsoft Dynamics) show this vulnerability type — where report rendering paths fail to apply permission filters that business logic correctly enforces — recurs consistently. This suggests the failure is structural rather than a one-off coding oversight. The vulnerability likely existed undetected from the moment Payment Ledger Entry was first consumed by this report, meaning organizations with multi-tenant data under segregation assumptions have a compliance exposure predating the CVE by however many versions their deployment is behind.