Bludit version 3.16.2 contains a stored cross-site scripting (XSS) vulnerability in the post content functionality. The application performs client-side sanitation of content input but does not enforce equivalent sanitation on the server side. An authenticated user can inject arbitrary JavaScript into the content field of a post, which is stored and later rendered to other users without proper output encoding. When viewed, the injected script executes in the context of the victim’s browser, allowing session hijacking, credential theft, content manipulation, or other actions within the user’s privileges.
Bludit versions before 3.13.1 contain an authenticated file download vulnerability in the Backup Plugin that allows logged-in users to access arbitrary files. Attackers can exploit the plugin's download functionality by manipulating file path parameters to read sensitive system files through directory traversal.
A security vulnerability has been identified in Bludit, allowing authenticated attackers to execute arbitrary code through the Image API. This vulnerability arises from improper handling of file uploads, enabling malicious actors to upload and execute PHP files.
Bludit prior to 3.9.1 allows a non-privileged user to change the password of any account, including admin. This occurs because of bl-kernel/admin/controllers/user-password.php Insecure Direct Object Reference (a modified username POST parameter).
Bludit before 3.9.0 allows remote code execution for an authenticated user by uploading a php file while changing the logo through /admin/ajax/upload-logo.
In Bludit v1.5.2 and v2.0.1, an XSS vulnerability is located in the new page, new category, and edit post function body message context. Remote attackers are able to bypass the basic editor validation to trigger cross site scripting. The XSS is persistent and the request method to inject via editor is GET. To save the editor context, the followup POST method request must be processed to perform the attack via the application side. The basic validation of the editor does not allow injecting script codes and blocks the context. Attackers can inject the code by using an editor tag that is not recognized by the basic validation. Thus allows a restricted user account to inject malicious script code to perform a persistent attack against higher privilege web-application user accounts.