CVE-2026-101127 in Forms Extension
Summary
by MITRE • 09/29/2026
Joomla Extension - balbooa.com - Unauthenticated upload filename stored XSS in Balbooa Forms < 2.4.3.4 - 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`.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in Balbooa Forms versions prior to 2.4.3.4 represents a critical security flaw rooted in improper validation of user-supplied input during file upload operations, specifically leading to stored cross-site scripting. This issue arises from the application's handling of multipart form data where the system performs adequate checks on the uploaded file's extension and detected MIME type but fails to sanitize or encode the original filename provided by the attacker. The core technical failure lies in the storage mechanism, which preserves the unmodified, attacker-controlled filename within the database field designated as #__baforms_submissions_attachments.name without applying any necessary encoding transformations such as HTML entity encoding or context-aware escaping before persistence.
From an operational perspective, this flaw allows for a persistent attack vector that does not require authentication to initiate but requires administrative interaction to trigger. An unauthenticated attacker can upload a file with a malicious payload embedded in its filename, effectively bypassing the initial extension and MIME type checks by leveraging legitimate-looking extensions while injecting executable JavaScript code within the name string itself. The vulnerability is chained through the application's workflow where this tainted data remains dormant until an administrator accesses the submission records associated with that specific form entry. This delay between injection and execution characterizes it as a stored XSS, significantly increasing its potential impact compared to reflected variants because the malicious script resides on the server side within the database.
The exploitation phase occurs when an authorized user, typically an administrator or moderator, opens the details of a submission containing the compromised attachment record. The component's JavaScript logic retrieves this raw filename from the backend and concatenates it directly into an HTML string structure without any sanitization steps. This concatenated string is then assigned to the innerHTML property of a DOM element. Because modern browsers interpret content assigned via innerHTML as executable code, the malicious script embedded in the filename executes within the context of the administrator's session. This execution grants the attacker the ability to perform actions on behalf of the victim, such as stealing session cookies, capturing sensitive form data submitted by other users, or performing state-changing requests that the authenticated user is privileged to execute.
This vulnerability aligns with CWE-79, which classifies improper neutralization of input during web page generation known as Cross-site Scripting, and specifically highlights the failure to encode special characters in HTML contexts before storage or display. In terms of attack taxonomy under MITRE ATT&CK, this scenario maps to T1059.007, JavaScript Execution via browser-based scripting, and falls within the broader category of Client-Side Injection. The lack of input validation on the filename field represents a classic case of CWE-20 Improper Input Validation, where the application trusts user-supplied data without verifying its safety for subsequent processing in different security contexts.
To mitigate this vulnerability, immediate patching to version 2.4.3.4 or later is required as it addresses these input handling deficiencies. In environments where upgrading is not immediately feasible, defensive coding practices must be implemented by ensuring that all user-supplied data stored in the database and subsequently rendered in HTML contexts undergoes rigorous output encoding. Specifically, developers should apply context-specific escaping rules to filename strings before they are inserted into DOM elements via innerHTML or similar methods. Additionally, implementing Content Security Policy headers can help mitigate the impact of successful XSS attacks by restricting the sources from which scripts can be loaded and executed, thereby reducing the effectiveness of injected payloads even if the initial validation flaw persists.