Apache OFBiz EUVD-2026-117478

No special conditions beyond reachability - remote unauthenticated exploitation works against stock/default deployments of Apache OFBiz 24.09 (before 24.09.08), because the getFinAccountTransRunningTotalAndBalances request-map reaches ServiceMultiEventHandler with no authentication and no CSRF requirement. The attacker only needs HTTP access to the OFBiz endpoint and crafts multi-form parameter names using the 'o' suffix to set an arbitrarily large row count (up to the signed-integer maximum). Limiting factors: the vulnerable code path is specific to the multi-form row-count handling and this request-map, and only OFBiz 24.09 branches before 24.09.08 are affected; instances already on 24.09.08 or not exposing this endpoint to untrusted networks are not exploitable.

All signals point to a genuine, straightforward denial-of-service risk rather than a high-CVSS-but-low-real-risk issue, though it is not an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is self-consistent with the description: a remote attacker needs network access only, low complexity, no privileges (PR:N) and no user interaction, and the only impact is availability (A:H), matching the CWE-770 uncontrolled-resource-consumption classification. The vuln.today Decision label is 'this_week', consistent with a serious but non-critical availability flaw. No EPSS score and no CISA KEV status were provided in the input, and no verified proof-of-concept or exploit code is referenced - the only references are an oss-security advisory and the vendor/Apache mailing-list thread - so exploitation is not confirmed active. The pin-a-thread mechanic (one small request forcing up to signed-integer-maximum synchronous dispatches) is simple to weaponize once understood, which supports prioritized patching, but the absence of EPSS/KEV/PoC signals means there is no evidence of in-the-wild exploitation at time of analysis. Net: treat as a real, patch-this-week availability priority on exposed OFBiz 24.09 instances, not a drop-everything incident.

A remote, unauthenticated attacker sends a single small HTTP request to the stock getFinAccountTransRunningTotalAndBalances request-map, crafting multi-form parameter names whose 'o' suffix encodes an extremely large row count. Because UtilHttp.getMultiFormRowCount derives the count from the largest suffix with no upper bound, ServiceMultiEventHandler.invoke then loops that many times calling dispatcher.runSync, pinning a server request thread; repeating this exhausts the request-handling thread pool and denies service. No public exploit code is identified at time of analysis, but the trigger is fully described in the advisory and is trivial to reproduce.