| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Bacularis 1.0.0 - 6.5.0 is vulnerable to Stored cross-site scripting (XSS) in the client address field. |
| BharatMLStack up to and including 1.3.0 is vulnerable to Cross Site Scripting (XSS) via the component Trufflebox UI (trufflebox-ui) in ExpressionViewModal.jsx. |
| A flaw was found in the Quarkus Qute template engine. When the {#eval} section helper processes a sub-template, it fails to pass the parent template's content type information. This bypasses standard escaping mechanisms, allowing untrusted data to be output as raw, unescaped text. This vulnerability can lead to Cross-Site Scripting (XSS) and JSON Injection, potentially allowing a remote attacker to execute arbitrary code in a user's browser or manipulate data. |
| Cross-Site Scripting (XSS) vulnerability due to inadequate input sanitisation in the client-side rendering engine of the 1millionbot AI Chat Platform. An unauthenticated remote user could cause external hyperlinks to be rendered in the web interface by sending messages containing Markdown syntax and certain unsanitised content blocks. The impact is limited to the user’s own interactive session; no compromise of internal infrastructure, access to third-party data or impact on administrative panels has been identified. |
| UVdesk core-framework before 1.1.7 contains a stored cross-site scripting vulnerability in the SwiftMailer configuration identifier parameter of the createMailerConfiguration action. Attackers with ROLE_AGENT can inject malicious script into the identifier field, which is persisted and executed when other members access the configuration update page. |
| Aureus ERP before 1.6.0 contains a stored cross-site scripting vulnerability in the Chatter field-change log where old_value and new_value entries are rendered without proper escaping. Any user permitted to edit tracked text fields can inject malicious markup that executes when other users, including administrators, view the record's Chatter panel. |
| The ZTE SmartLife application has a hardcoded key. The key used to decrypt account server information is stored in plaintext in the code. Once the key is obtained, the server information can be decrypted, thus exposing it. |
| Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. Prior to version 7.2.0, when `headers=plain`, table header text was emitted into `<th>` via a raw HTML path. User-controlled `mainlabel` content could therefore become executable HTML. Version 7.2.0 fixes the issue. |
| Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. Prior to version 7.2.0, `sep` was inserted verbatim into HTML cell joins. This made it possible to inject HTML through the separator value. Version 7.2.0 fixes the issue. |
| Semantic MediaWiki is a free, open-source extension to MediaWiki that lets users store and query data within the wiki's pages. In versions 7.0.0 through 7.1.0, `Special:Ask` accepts a `cursor` query parameter for keyset pagination (added in 7.0.0). The token is decoded by `CursorEncoder`, which is an **unsigned** base64url-encoded JSON blob, so its contents are fully attacker-controlled. When the cursor's sort anchor does not match the request's `sort=` / `order=`, `QueryCreator::applyCursorIfRequested()` builds an error message by interpolating the attacker-controlled `sort_prop` / `sort_order` values into a raw string via `Query::addErrors()`. Unlike SMW's message-key errors, this raw string bypasses the message layer's sanitization (`ProcessingErrorMsgHandler::normalizeAndDecodeMessages()` passes a non-key, non-encoded string through unchanged). `ErrorWidget::queryError()` then assembles the errors and passes them to `Html::errorBox()`, whose first argument is emitted as raw HTML. The result is a reflected cross-site scripting vulnerability: a crafted `cursor` token containing markup in `sort_prop` (or `sort_order`) executes script in the victim's browser on the wiki origin. No authentication or special permission is required. The payload is delivered via a crafted link. Version 7.2.0 contains a fix. |
| Open edX Platform enables the authoring and delivery of online learning at any scale. From Redwood until Ulmo and Verawood.1, the add_additional_attributes_to_notifications function in openedx/core/djangoapps/notifications/email/utils.py assigns notification content without sanitizing discussion-title values produced by get_notification_content in openedx/core/djangoapps/notifications/base_notification.py. An enrolled student can place CSS-capable markup in the post_title value supplied by lms/djangoapps/discussion/rest_api/discussions_notifications.py. Digest and batched-email rendering then passes that value through openedx/core/djangoapps/notifications/templates/notifications/digest_content.html as safe HTML, allowing email-open tracking and content spoofing or phishing when another learner opens a CSS-rendering client. The immediate-email path is not affected because it strips title markup and renders a separately sanitized body. This issue is fixed in Ulmo and Verawood.1. |
| SiYuan through 3.8.4 renders notebook names as raw HTML in the Daily Note picker dialog without escaping, allowing stored cross-site scripting in the Electron renderer. Attackers can create notebooks with HTML payloads in names that execute JavaScript with Node.js access when the picker opens, enabling operating system command execution. |
| SiYuan through 3.8.4 fails to escape heading style attributes when rendering outline and bookmark dock HTML, allowing stored cross-site scripting. Attackers can supply crafted notebooks or call administrative endpoints to inject malicious style values that execute in the Electron renderer with full system access. |
| Cross-site Scripting (XSS) in index.php in CuteNews v.2.1.2 allows remote unauthenticated attackers to supply an arbitrarily named URL parameter key, with part of its name containing any URL-encoded common XSS payload (such as "><script>alert(1)</script>). |
| CuteNews v.2.1.2 is vulnerable to Cross Site Scripting (XSS). Improper neutralization of the __referer value 2.0.1 allows a remote attacker to execute arbitrary JavaScript in the context of an authenticated user's session via a javascript: URI rendered as an unsanitized clickable link on the msg_info page. |
| Telegram Desktop before 6.9.4 allows XSS in the HTML exporter. (The first fixed stable version is 7.0.1.) This occurs in button.text.toUtf8 in export_output_html.cpp. Exploitation cannot occur unless HTML export was used by a victim. However, the exploit payload can be exported if a message were forwarded into a group by a member (it is not necessary for the message author to be a member of a group). |
| Concrete CMS before 9.5.3 improperly neutralized a user-supplied custom date format when rendering conversation messages, resulting in reflected cross-site scripting. An attacker could execute arbitrary JavaScript in the browser of a user who was tricked into submitting a crafted POST request to the conversation view endpoint. Exploitation was aided by the absence of a CSRF token on the endpoint, which allowed the payload to be delivered through an auto-submitting cross-origin POST without authentication. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.1 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| Concrete CMS 9.4.0 through 9.5.2 did not escape colliding page paths before rendering them in the location panel's duplicate-path confirmation dialog. The panel's check endpoint returned the submitted path unmodified in its JSON response, and client-side JavaScript inserted each value into the dialog as raw HTML, so a crafted page path executed script in the editor's authenticated browser session. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 2.0 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N. Thanks Yonatan Drori from Tenzai for reporting. |
| Concrete CMS below 9.5.4 did not validate the user timezone value (uTimezone) on write and rendered it without output encoding on the Dashboard user management page, where Date::getTimezoneDisplayName() returns any non-IANA value unchanged. A stored cross-site scripting payload saved in this field executed in an administrator's browser when they viewed the affected user in the Dashboard, running script in the admin session (for example to read CSRF tokens, create administrator accounts, or change site settings). In Concrete CMS 9.5.3 the field became reachable by unauthenticated visitors through public registration; in Concrete CMS below 9.5.3, the same field was reachable by any authenticated user through the account profile editor. Exploitation required concrete.misc.user_timezones to be enabled (off by default), and the unauthenticated path additionally required public registration to be enabled. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.7 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Suraj Bhosale for reporting. |
| Concrete CMS before 9.5.4 did not sanitize XML and XSLT documents uploaded through a public Form Block file-upload question. Plain XML uploads were validated by file extension only and stored as publicly accessible files that were served inline from the application's own origin. An unauthenticated visitor could therefore store an XML document containing an xml-stylesheet processing instruction that referenced an attacker-supplied, same-origin XSLT stylesheet. When a victim opened the stored file directly in a browser, the browser fetched the stylesheet, transformed the document into HTML, and executed attacker-controlled JavaScript in the Concrete CMS origin (stored cross-site scripting). If the victim was an authenticated administrator, the script could act with that administrator's session, and the reporter demonstrated creation of a new user in the Administrators group. The Concrete CMS security team gave this vulnerability a CVSS v4.0 score of 7.3 with vector CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Thanks Valentin SARRE (Independent security researcher) for reporting. |
