Balbooa Forms vulnerabilities

Joomla Extension - balbooa.com - Unauthenticated RCE via field shortcode injection in Balbooa Forms < 2.4.3.4 - Balbooa Forms supports administrator-defined PHP code which runs after a public form submission. The feature also supports form-field shortcodes inside that PHP. Before calling `eval()`, the component replaces each shortcode with the raw value submitted by the visitor, leading to an RCE vector. A public form must use the product's optional PHP-after-submission action and interpolate an attacker-controlled field shortcode inside a double-quoted PHP string to be vulnerable.

Joomla Extension Balbooa Forms before 2.4.3.4 has an unauthenticated upload filename stored XSS vulnerability. The public form upload endpoint validates the uploaded file's extension and detected MIME type, but stores the attacker-supplied original multipart filename verbatim in `#__baforms_submissions_attachments.name`. A later anonymous form submission associates that temporary attachment with the newly created submission. When an administrator opens the submission, the component's JavaScript retrieves the stored attachment record and concatenates `file.name` directly into an HTML string. The complete string is assigned to `innerHTML`.

Joomla Extension - balbooa.com - Pre-auth PHP Code Injection in Balbooa Forms < 2.4.3.2 - The form's optional custom-PHP post-submission handler is executed via eval(). The [URL parameter = X] shortcode is substituted with the raw, unescaped value of a query parameter, letting an unauthenticated attacker inject arbitrary PHP that executes server-side. The CSRF token needed to reach the endpoint is itself disclosed anonymously via a separate task, so it provides no real protection. Exploitability requires the form to have a custom-PHP handler configured (a documented builder feature) referencing that shortcode, and no reCAPTCHA on the submit button.

The Joomla extension Balbooa Forms versions below 2.4.3 are vulnerable to unauthenticated remote code execution. Insecure form processing logic allows code execution for forms that include the signature field type.

Joomla Extension Balbooa Forms before 2.4.3.4 has an unauthenticated path traversal vulnerability that exfiltrates local files through auto-reply attachments. During public form submission, upload-field state is accepted as Guest-controlled JSON. For every object whose 'id' merely looks numeric, the component trusts the supplied 'filename', concatenates it below the configured upload directory, and adds the result to an array of local attachment paths. It does not load the referenced attachment row, verify ownership/session/form/field, require that the ID exists, canonicalize the path, or enforce containment. If the form's normal 'auto reply' and 'attach uploaded files' options are enabled, the component sends those local paths as email attachments to the address submitted in an email field. A Guest can therefore submit a nonexistent numeric ID plus a traversal filename such as '../../../../configuration.php' and receive any file readable by the Joomla process.

Balbooa Forms < 2.4.3.4 contains a file metadata tampering vulnerability. The final form submission processes JSON arrays per upload field, checking only that IDs are numeric. Client-supplied filenames and display names are trusted directly, introducing potential cross-session claiming, metadata tampering, and path traversal risks (e.g., via getFilePath()).

In the Balbooa Forms extension for Joomla (versions below 2.4.3.4), the public removeTmpAttachment action accepts an attachment ID and deletes the matching database row and file. The controller verifies a Joomla session token, but the model does not bind the attachment ID to the session that uploaded the file, the current user, the form, or the temporary state, allowing any guest to perform unauthorized deletion of attachments.

Joomla Extension - balbooa.com - Pre-auth Payment Amount Tampering in Balbooa Forms < 2.4.3.2 - The stripeCharges and payAuthorize endpoints accept the charge total from a client-controlled request parameter and forward it to the payment gateway without recomputing it from the form's configured product prices. Neither endpoint enforces authentication or CSRF checks. An unauthenticated attacker can purchase any priced item for an arbitrary amount (e.g., $0.01), and can additionally forge line items, quantities, and shipping.