| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| MCP Appium is an MCP server that provides AI assistants with tools to automate mobile app testing on Android and iOS. In versions prior to 1.85.10, the createLocatorGeneratorUI function interpolates attacker-controlled element attributes — text, content-desc, resource-id, and locator selector values — directly into an HTML template literal without any HTML or JavaScript context escaping. An attacker who controls the UI of the app under test can inject arbitrary HTML and JavaScript into the MCP UI resource returned by the generate_locators tool. When a victim's MCP client renders this resource, the injected script executes and can invoke arbitrary MCP tools via window.parent.postMessage, leading to unauthorized MCP tool execution such as taking screenshots, reading page source, or any other registered capability. This issue has been fixed in version 1.85.10. |
| justhtml before 1.12.0 (versions <= 1.11.0) contains a mutation cross-site scripting (mXSS) vulnerability in the serialization of raw-text elements such as <style> and <script>. When a DOM tree is processed by sanitize_dom() using a custom policy that keeps these elements, text nodes inside them are serialized literally without escaping, allowing attacker-controlled text containing the matching closing tag sequence to break out of the raw-text context and inject arbitrary HTML into the serialized output. The default sanitization policy is not affected because it drops the contents of style and script. |
| A vulnerability was found in SourceCodester Stock Management System 1.0. This issue affects some unknown processing of the file /php_action/getOrderReport.php. Performing a manipulation of the argument clientName/clientContact results in cross site scripting. It is possible to initiate the attack remotely. The exploit has been made public and could be used. |
| justhtml before 1.17.0 contains multiple security issues in sanitization, serialization, and programmatic DOM handling. When custom policies preserve foreign namespaces (SVG/MathML), dangerous content such as HTML integration points (SVG <foreignObject>, MathML <annotation-xml encoding="text/html">) and mutation-XSS parser-differential payloads could survive sanitization and become active HTML after reparse; SVG filter="url(...)" and preserved <style> could leave resource-loading CSS (@import, background-image:url()). Programmatic script/style/Comment nodes could serialize into active markup. Additional hardening fixes address sanitize-pipeline cache mutation and DOM parent/child cycles that could cause infinite loops. Most issues affect advanced or custom configurations rather than the default JustHTML(..., sanitize=True) safe path. |
| Horde IMP's AppleDouble MIME viewer writes an attacker-controlled attachment name into an HTML status block without escaping it. In lib/Mime/Viewer/Appledouble.php, _IMPrender() obtains the name of the data part with IMP_Contents::getPartName(), which returns the MIME part's own name parameter as supplied by the message, and passes it through sprintf into the text of an IMP_Mime_Status object. IMP_Mime_Status::__toString() concatenates each text entry directly into the surrounding table markup, so the value reaches the rendered page verbatim. A message crafted as multipart/appledouble whose data part carries markup in its name parameter therefore executes script in the context of any user who views it, and the payload persists in the mailbox. Exploitation requires no account on the target system, only the ability to send mail to a user. Version 7.2.0 escapes the value with htmlspecialchars(). The researcher additionally chains this flaw with the arbitrary file read of CVE-2026-58451, and reports that script running in an administrator's session can reach an application code-execution path. |
| Hugo's default fenced-code-block renderer writes attribute values taken from the code-fence info string into the rendered HTML without escaping them. New in markup/internal/attributes/attributes.go converts every attribute value from a byte slice to a string as it is stored, deliberately dropping the escaping that used to happen there, and RenderAttributes in the same file escapes only values that are still byte slices, so its escaping branch is never reached and every value is written verbatim. The function's documentation states that it performs HTML escaping of string attributes, which it does not. A quote inside an attribute value in the info string therefore terminates the attribute and allows a further attribute, including an event handler, to be placed on the wrapper element, and the script runs for every visitor who loads the page. This path is reached under the default configuration, with code fences enabled and without goldmark's unsafe setting or any custom render hook. Attribute names beginning with on are filtered when the attributes are parsed, so injection is achieved through the value rather than the name. |
| Marko is a declarative, HTML-based language for building web apps. Prior to marko version 5.38.36 and prior to @marko/runtime-tags 6.0.164, when dynamic text is interpolated into a <script> or <style> tag the Marko runtime failed to prevent tag breakout when the closing tag used non-lowercase casing. An attacker able to place input inside a <script> or <style> block could break out of the tag with </SCRIPT>, </Style>, etc. and inject arbitrary HTML/JavaScript, resulting in cross-site scripting. This issue has been patched in marko version 5.38.36 and @marko/runtime-tags 6.0.164. |
| A weakness has been identified in SourceCodester Class and Exam Timetabling System 1.0. Affected is an unknown function of the file /BSIS1.php. Executing a manipulation of the argument course can lead to cross site scripting. The attack may be launched remotely. The exploit has been made available to the public and could be used for attacks. |
| Use of Hard-coded Credentials vulnerability in TÜBİTAK BİLGEM Software Technologies Research Institute Liderahenk allows Try Common or Default Usernames and Passwords.
This issue affects Liderahenk: before 3.5.5. |
| YOURLS is a self-hosted, customizable URL shortener written in PHP. From 1.5.1 until 1.10.4, YOURLS stores the HTTP Referer header through yourls_get_referrer(), yourls_sanitize_url_safe(), and yourls_log_redirect(), then aggregates the value in yourls-infos.php and passes the derived domain through yourls_get_domain(), yourls_stats_pie(), and yourls_google_array_to_data_table(). The chart builder concatenates labels into inline JavaScript without JavaScript-string escaping, so an unauthenticated attacker can poison the statistics of an existing short URL with a crafted referrer. When an administrator or public stats-page viewer opens the affected statistics page, attacker-controlled JavaScript executes in the YOURLS origin and can access admin-visible data, the API signature token, and privileged same-origin actions. This issue is fixed in version 1.10.4. |
| Improper Neutralization of Input During Web Page Generation ("Cross-site Scripting") vulnerability in Drupal Drupal core allows Stored XSS. This issue affects Drupal core versions: from 0.0.0 to 10.6.13, from 11.3.0 to 11.3.14, from 11.4.0 to 11.4.4, from 0.0.0 to 11.0.*, from 0.0.0 to 11.1.*, from 0.0.0 to 11.2.*. |
| Combodo iTop is a web based IT service management tool. Prior to 3.2.3, there is a Reflected Cross-Site Scripting (XSS) vulnerability in the synchro import script. This issue has been fixed in version 3.2.3. |
| Ech0 before 4.7.3 contains a stored cross-site scripting vulnerability in the public RSS feed where tag names and markdown content are rendered without HTML escaping. Attackers with admin privileges can inject malicious tag names or raw HTML in echo content that executes as JavaScript in RSS readers that render HTML-type summaries, affecting anonymous subscribers and other users. |
| justhtml versions 0.9.0 through 1.21.0 contain a cross-site scripting vulnerability in to_markdown() where inline code spans fail to account for blank lines as block boundaries. Attackers can inject blank lines into code or pre element text to break the inline span, causing sanitized HTML to be emitted unescaped and re-parsed as live Markdown by compliant renderers. |
| Adminer before 5.4.3 inserts unsanitized database server version strings into script tags with valid CSP nonces without proper validation. Attackers controlling a rogue MySQL server can return crafted version strings that break out of the JavaScript context and execute arbitrary code, bypassing Content Security Policy protections. |
| In Splunk SOAR versions below 8.6.0, a user who holds the "Incident Commander" Splunk SOAR role could store JavaScript in a note and run it in the browser of another user when that user opens the note. The stored Cross-Site Scripting (XSS) vulnerability is possible because Splunk SOAR can treat existing note content as Hypertext Markup Language (HTML) without sanitizing that content when the note format changes. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "Incident Commander" Splunk SOAR role should not be able to exploit the vulnerability at will. For more information see Manage roles and permissions in Splunk SOAR (Cloud) (https://help.splunk.com/en/splunk-soar/soar-cloud/administer-soar-cloud/manage-your-splunk-soar-cloud-users-and-accounts/manage-roles-and-permissions-in-splunk-soar-cloud) in the Splunk documentation. |
| 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 store a Dashboard Studio workflow action with a crafted Uniform Resource Locator (URL). When another authenticated user selects the stored action from Event Actions and selects Continue, attacker-controlled JavaScript runs in the browser of that user. This could expose data or actions available through Splunk Web to that user. The vulnerability is possible because Dashboard Studio does not sufficiently validate workflow-action URLs before processing them. The vulnerability requires the attacker to phish the affected user by tricking them into initiating a request within their browser. The user who holds the "power" Splunk role should not be able to exploit the vulnerability at will. For more information see 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. |
| In Splunk Enterprise versions below 10.4.2, 10.2.6, 10.0.9, and 9.4.14, a user who does not hold the "admin" or "power" Splunk roles could store a dashboard view that runs JavaScript in the browser of another user who opens it and hovers over a sparkline table cell, allowing for access to all relevant data and system integrity available to that user. The vulnerability is possible because the dashboard table renderer does not sufficiently restrict tooltip options or escape tooltip content before display. |
| 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 store a malicious ui-tour knowledge object that matches an auto-tour page name and share the object at the app level. The object can execute arbitrary JavaScript in the browser of another authenticated user who visits a standard Splunk Web page. The JavaScript could expose all relevant data and affect system integrity within the second user permissions. The Cross-Site Scripting (XSS) vulnerability is possible because Splunk Web resolves auto-tour entries from the app namespace and uses untrusted tour content when building the tour image. |
| 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. |
