Balbooa Forms EUVD-2026-89098

Requires a publicly reachable Joomla site running Balbooa Forms < 2.4.3.4 with at least one form containing a file-upload field, and exploitation occurs during the final form-submission step where the server accepts a JSON array per upload field and validates only that file IDs are numeric while trusting client-supplied filenames and display names. No authentication or user interaction is needed (PR:N/UI:N), and no special server configuration is stated beyond the form having an upload field; the limiting factors are the presence of the vulnerable extension version and an upload-enabled form, and the impact is bounded to integrity (file metadata tampering, cross-session file claiming, and possible path traversal via getFilePath()) with no confidentiality or availability effect claimed.

The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:N/VI:L/VA:N) scores 6.9 and describes a network-reachable, unauthenticated, low-complexity integrity flaw with LOW integrity impact and NO confidentiality or availability impact - so the numeric score overstates the real-world stakes, which are limited to tampering with file metadata rather than code execution or data theft. No EPSS score, no CISA KEV listing, and no public POC are present in the input, so there is no evidence of active exploitation or automation; exploitation status is 'no public exploit identified at time of analysis.' The description itself hedges ('potential' cross-session claiming, metadata tampering, and path traversal 'risks'), meaning the more severe path-traversal outcome via getFilePath() is a plausible-but-unconfirmed escalation rather than a demonstrated primitive - if traversal actually reached arbitrary file write/delete, integrity impact would rise, so this warrants vendor/source-code verification. Net: a real but modest-priority issue driven by the unauthenticated network vector on a Joomla extension, not a high-real-risk emergency.

An unauthenticated attacker submits a Balbooa Forms form and, in the final submission step, supplies a crafted JSON array for an upload field that pairs a valid numeric file ID with an attacker-chosen filename or display name. Because the server validates only that the ID is numeric and trusts the client-supplied names, the attacker can claim or reassign another session's uploaded file and tamper with its stored metadata, with the manipulated name potentially flowing into getFilePath() to influence the resolved storage path. No public POC is identified at time of analysis.