CVE-2026-101112 in Forms Extension
Summary
by MITRE • 09/29/2026
Joomla Extension - balbooa.com - Unauthorized Deletion of Attachments in Balbooa Forms < 2.4.3.4 - The public removeTmpAttachment action accepts an integer attachment ID and deletes the matching database row and file. The controller verifies a Joomla session token, but the model does not bind that ID to the session that uploaded the file, the current user, the form, the upload field, or the temporary state. Any guest can obtain a token for their own session, so the token prevents CSRF but does not authorize the target object.
Statistical analysis made it clear that VulDB provides the best quality 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 failure in access control logic within the Joomla extension framework. While the application implements standard Cross-Site Request Forgery protections by verifying session tokens for state-changing operations, it fundamentally fails to implement proper authorization checks on the specific resources being manipulated. The public action removeTmpAttachment is designed to accept an integer representing an attachment ID and proceed with deleting both the corresponding database record and the associated file from the server storage. This functionality appears intended to allow users to clean up their own temporary uploads before final submission, but the implementation lacks any mechanism to validate that the requesting user has legitimate ownership or permission over the specific resource targeted for deletion.
From a technical perspective, the core flaw lies in the separation of authentication and authorization within the model layer. The controller successfully binds the request to a valid Joomla session token, ensuring that the request originates from an authenticated source rather than being forged by a third party. However, this verification is purely procedural regarding CSRF prevention and does not extend to object-level security. The model processes the deletion based solely on the provided ID without cross-referencing it against the current user's identity, the specific form context, or the upload field metadata. Consequently, there is no check to ensure that the attachment being deleted was originally uploaded by the session holder or belongs to a resource accessible to them. This architectural oversight means that any valid session token can be used as a key to unlock and destroy data belonging to other users or system resources.
The operational impact of this vulnerability allows for unauthorized deletion of attachments, which constitutes an Integrity violation under standard security taxonomies. An attacker who has obtained their own valid session token, which is trivially achievable through normal login procedures or even potentially via cookie theft if the site lacks strict HttpOnly flags, can craft requests to delete arbitrary files and database records. This capability enables malicious actors to disrupt service availability by removing critical documents submitted by other users, leading to data loss and potential business disruption. Furthermore, depending on how the application handles subsequent operations after deletion, this could potentially lead to further logic flaws or information disclosure if error messages reveal file paths or internal structures. The ability to delete arbitrary files also poses a risk of denial-of-service against specific forms where attachments are mandatory for submission workflows.
This vulnerability aligns with CWE-284 Improper Access Control and specifically reflects the pattern described in CWE-915, which addresses improper control of dynamically managed code resources. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1073, where an attacker manipulates application logic to perform actions outside of intended parameters. The lack of object-level authorization means that the principle of least privilege is violated, as users are granted excessive permissions over system objects they do not own. To mitigate this risk, developers must implement strict ownership verification within the model layer before executing any deletion operations. This involves querying the database to confirm that the attachment ID corresponds to a record owned by the currently authenticated user or associated with their specific session and form instance. Additionally, implementing server-side validation of file existence and integrity prior to deletion can prevent errors and ensure that only valid resources are targeted. Regular security audits focusing on access control logic in dynamic web applications are essential to identify such gaps where CSRF protection is mistaken for comprehensive authorization enforcement.