| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Unauthenticated Cross Site Scripting (XSS) in wpDataTables <= 6.5.1.4 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Tagembed <= 7.4 versions. |
| Unauthenticated Cross Site Scripting (XSS) in TranslatePress <= 3.3.2 versions. |
| lxml is a library for processing XML and HTML in the Python language. Prior to 6.1.1, link attributes in ``lxml.html.defs.link_attrs`` were missing ``xlink:href``, which can be used for URL bypass attacks in embedded SVG/MathML/etc. content. This vulnerability was fixed in lxml 6.1.1 and lxml_html_clean 0.4.5. |
| Unauthenticated Cross Site Scripting (XSS) in Paymob for WooCommerce <= 4.1.10 versions. |
| Unauthenticated Cross Site Scripting (XSS) in GeoDirectory <= 2.8.173 versions. |
| Subscriber Cross Site Scripting (XSS) in Media LIbrary Assistant <= 3.39 versions. |
| Subscriber Cross Site Scripting (XSS) in WP BASE Booking <= 6.3.2 versions. |
| ATutor is vulnerable to Stored Cross Site Scripting in registration functionality. An attacker can register a new account and enter a JavaScript payload in the phone field during registration. When any authenticated user visits the attacker's public profile, the profile template echoes the phone value without output encoding and the browser executes the payload leading to the theft of user's session cookie.
Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. |
| ATutor is vulnerable to Reflected XSS in restore functionality. An attacker can provide a specially crafted URL that, when opened, results in arbitrary JavaScript execution in the victim's browser.
Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. |
| ATutor is vulnerable to Reflected XSS via popup parameter in preview.php. An authenticated attacker can inject a double quote into the popup parameter, break out of the attribute value, and append a new event handler such as onload. The related preview_top.php file sanitises these parameters, but that does not prevent XSS in the parent frameset rendered by preview.php itself.
Product is no longer actively supported and the vulnerabilities have not been fixed. Only version 2.2.4 was tested and confirmed as vulnerable, other versions were not tested but might also be vulnerable. |
| n8n before 1.123.69, 2.33.4, and 2.34.1 contains a stored cross-site scripting vulnerability in the Form node's completion page. The completion page applied its sandboxing Content-Security-Policy only when respondWith was not set to 'redirect', but responseText was always rendered as raw HTML. An authenticated member could set respondWith to 'redirect' via an expression while keeping responseText populated, causing the completion page to serve unsanitized HTML and script from the n8n origin. Any visitor who submitted the resulting public form would have that script execute same-origin with their session. |
| Unauthenticated Cross Site Scripting (XSS) in Aora <= 1.3.19 versions. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.13, an unauthenticated user who tricks another user into visiting a malicious web page could run unauthorized JavaScript in that user's browser. This could allow for unauthorized access to all relevant data available to that user and actions that affect system integrity. The Cross-Site Scripting (XSS) is possible because Splunk Web does not validate the origin and source of messages received by a page message handler. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The unauthenticated user should not be able to exploit the vulnerability at will. |
| Unauthenticated Cross Site Scripting (XSS) in Advance Product Search <= 1.4.8 versions. |
| Unauthenticated Cross Site Scripting (XSS) in Form Maker by 10Web <= 1.15.46 versions. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who holds the "power" Splunk role could create a malicious Splunk Web tour and cause arbitrary JavaScript to run in the browser of another user when that user opens a crafted tour link. The JavaScript runs in the browser of the affected user, allowing for access to all relevant data available to that user. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web renders tour content and tour navigation links without sufficient output encoding and accepts a tour selector value that can be treated as markup. The vulnerability requires another user to open a crafted tour link. The user who holds the "power" Splunk role should not be able to trigger JavaScript execution in another user's browser without that user interaction. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user that holds a role with the schedule_search capability could store a malicious script in an alert trigger condition field. When another user opens the crafted link, the script runs in the browser of that user and could access all data available to that user. The vulnerability is possible because Splunk Web uses the alert threshold value in generated alert trigger condition markup without escaping special characters. Successful exploitation requires another user to open the crafted link. For more information see Configure alert trigger conditions (https://help.splunk.com/en/splunk-enterprise/alert-and-respond/alerting-manual/10.4/manage-alert-trigger-conditions-and-throttling/configure-alert-trigger-conditions) and Define roles on the Splunk platform with capabilities (https://help.splunk.com/en/splunk-enterprise/administer/manage-users-and-security/10.2/manage-splunk-platform-users-and-roles/define-roles-on-the-splunk-platform-with-capabilities) in the Splunk documentation. |
| Etherpad is a real-time collaborative editor. Prior to 3.3.0, getHTMLFromAtext in src/node/utils/ExportHtml.ts interpolates values from the exportHtmlAdditionalTagsWithData plugin hook into span data attributes without HTML attribute escaping. A pad editor can place an attacker-controlled value into the attribute pool through moveOpsToNewPool and AttributePool.putAttrib. When a bundled plugin such as ep_font_color or ep_font_size registers the hook, opening the resulting HTML export causes the value to execute as stored cross-site scripting in the Etherpad origin. This issue is fixed in version 3.3.0. |
| ApostropheCMS is an open-source Node.js content management system, and sanitize-html provides a simple HTML sanitizer with a clear API. Under the default configuration, versions of `sanitize-html` prior to 2.17.4 can turn attacker-controlled content inside a disallowed `xmp` element into live HTML or JavaScript. This is a sanitizer bypass in the default `disallowedTagsMode: 'discard'` path and can lead to stored XSS in applications that render sanitized output back to users. Version 2.17.4 patches the issue. |
