Apache OFBiz EUVD-2026-117459

Exploitation requires access to the OFBiz accounting functionality as a user who has been granted the ACCOUNTING_VIEW permission; the bug is that this role can invoke PaymentApplication create and update operations because the ACCOUNTING_CREATE and ACCOUNTING_UPDATE permission checks are absent. Limiting factors: the actor must be a provisioned OFBiz user with at least the ACCOUNTING_VIEW grant (per the description), and the instance must be running a version before 24.09.08. Note the CVSS vector marks PR:N (no privileges), which conflicts with the description's requirement of an ACCOUNTING_VIEW user - confirm the actual privilege prerequisite with the vendor.

This is a broken-access-control flaw in Apache OFBiz accounting: a user holding only ACCOUNTING_VIEW can create or update PaymentApplication records because the ACCOUNTING_CREATE/ACCOUNTING_UPDATE permission checks are missing (CWE-425, Direct Request / forced browsing). The signals are moderate and partly conflicting. The supplied CVSS vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N (score 7.5), scoring it as network, low-complexity, UNAUTHENTICATED with high integrity impact and no confidentiality or availability impact - consistent with a write-only authorization bypass. However, the vector's PR:N directly contradicts the description, which states the actor is a 'user with only ACCOUNTING_VIEW permission'; that is an authenticated, logged-in user, which argues for PR:L. Verify authentication requirement with the vendor advisory - authentication requirements are not cleanly confirmed because CVSS and description disagree. EPSS is low (0.15%, 4th percentile), the CVE is NOT in CISA KEV, and no public exploit is identified, so there is no evidence of widespread or active exploitation. The vuln.today decision label is 'this_week', indicating it warrants timely patching but is not an emergency. Net: a legitimate integrity/privilege-boundary issue that matters in multi-user OFBiz deployments where ACCOUNTING_VIEW is granted broadly, but not a high-urgency internet-worm scenario - the real exposure depends on how many low-privilege accounting viewers exist and whether the app is reachable by them.

An authenticated OFBiz user who has been granted only read-level accounting access (ACCOUNTING_VIEW) issues the create/update request for a PaymentApplication directly; because the server never checks for ACCOUNTING_CREATE or ACCOUNTING_UPDATE, the operation succeeds and the user tampers with payment-application accounting data they should not be able to modify. No public exploit code is identified, and the trigger mechanism beyond the missing permission check is not detailed in the available sources.