Stored cross-site scripting in Bludit site logo uploads

A stored cross-site scripting (XSS) vulnerability in Bludit 4.0.0-beta allows a low-privileged authenticated user (Author role) to inject arbitrary JavaScript by uploading a crafted SVG file as the site logo. A stored script tag in the SVG executes in the browser of any user who loads the logo.

• Affected product: Bludit from vendor Bludit.
• Affected release: 4.0.0-beta with semver versioning and affected status.
• The record marks the default status of other deployments as unknown.
• No additional branch is confirmed affected or unaffected, and the record does not provide a fixed release.

The flaw is in the site logo upload flow, in the referenced component bl-kernel/ajax/logo-upload.php. An authenticated user with the Author role can provide a controlled SVG as the site logo, and the SVG content is stored instead of being removed. When the logo is loaded in a browser, the stored script tag executes in that user's browser context. Exploitation requires network access, a low-privileged account, and another user to load the logo, consistent with stored XSS behavior. The referenced source checks the file extension and MIME type before moving the upload into the uploads directory, but the available evidence does not confirm content sanitization in the affected release. The exact browser context and any restrictions imposed by CSP remain unknown.

The vulnerability is remotely reachable through the web interface and requires an authenticated attacker who can upload or change the site logo. The record describes low attack complexity, but another user must load the logo for the JavaScript to execute. No public exploit is identified in the supplied record, and observed exploitation is not established. The absence of public exploitation information does not demonstrate that exploitation is impossible.

Successful exploitation results in JavaScript execution in the browser context where the logo is loaded, not direct server-side code execution. The stored payload can affect each user who loads the logo until the malicious content is replaced or removed. A victim's permissions may limit the data and actions available to the script; the record supports low confidentiality and integrity impact and does not identify an availability impact. The available evidence does not establish administrative takeover, server compromise, or a specific data-theft result.

The flaw can cause attacker-controlled JavaScript to execute in the browsers of users who visit a page displaying the manipulated logo. Depending on the victim's permissions and other browser protections, the script may read data accessible to the victim's session or perform actions on the victim's behalf. Because the payload is stored, the same content can affect multiple users until the logo is replaced or removed. The available evidence does not establish server compromise, service unavailability, or a specific data-breach outcome.

1. Prioritize an upgrade: apply a vendor-confirmed fixed release when one becomes available. The record does not name a fixed version, so later or parallel branches must not be assumed safe.
2. Use a temporary control: restrict Author accounts from changing the site logo or disable the logo upload flow if the deployment permits it. This is a compensating measure, not a confirmed vendor fix.
3. Review and replace existing logos with trusted content, especially logos uploaded by low-privileged accounts.
4. If SVG support must remain enabled, add content validation and SVG sanitization before storing or serving the file. Do not rely only on the filename extension or MIME type to prevent JavaScript in SVG content.

1. Inventory Bludit deployments and identify systems where Author accounts can access the site logo upload function.
2. Inspect the current logo and recently uploaded logos for SVG content, especially embedded script tags or JavaScript.
3. Review logo-change history and upload events associated with bl-kernel/ajax/logo-upload.php, where such events are logged.
4. Review unusual logo retrieval requests or administrative activity involving the logo. This is precautionary monitoring, not a confirmed indicator of compromise.
5. Do not treat the absence of matching log evidence as proof that a system is safe.