HCL Compass is vulnerable to lack of file upload security.  An attacker could upload files containing active code that can be executed by the server or by a user's web browser.

Thirty Bees Core v1.4.0 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the backup_pagination parameter at /controller/AdminController.php. This vulnerability allows attackers to execute arbitrary JavaScript in the web browser of a user via a crafted payload.

urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren't expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.

Archer Platform 6.x before 6.13 P2 HF2 (6.13.0.2.2) contains a stored cross-site scripting (XSS) vulnerability. A remote authenticated malicious Archer user could potentially exploit this vulnerability to store malicious HTML or JavaScript code in a trusted application data store. When victim users access the data store through their browsers, the malicious code gets executed by the web browser in the context of the vulnerable application. 6.14 (6.14.0) is also a fixed release.

IBM Security Verify Privilege On-Premises 11.5 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system. IBM X-Force ID: 240454.

github.com/crewjam/saml is a saml library for the go language. In affected versions the package does not validate the ACS Location URI according to the SAML binding being parsed. If abused, this flaw allows attackers to register malicious Service Providers at the IdP and inject Javascript in the ACS endpoint definition, achieving Cross-Site-Scripting (XSS) in the IdP context during the redirection at the end of a SAML SSO Flow. Consequently, an attacker may perform any authenticated action as the victim once the victim’s browser loaded the SAML IdP initiated SSO link for the malicious service provider. Note: SP registration is commonly an unrestricted operation in IdPs, hence not requiring particular permissions or publicly accessible to ease the IdP interoperability. This issue is fixed in version 0.4.14. Users unable to upgrade may perform external validation of URLs provided in SAML metadata, or restrict the ability for end-users to upload arbitrary metadata.

Adobe Commerce versions 2.4.7-beta1 (and earlier), 2.4.6-p2 (and earlier), 2.4.5-p4 (and earlier) and 2.4.4-p5 (and earlier) are affected by a stored Cross-Site Scripting (XSS) vulnerability that could be abused by a low-privileged attacker to inject malicious scripts into vulnerable form fields. Malicious JavaScript may be executed in a victim’s browser when they browse to the page containing the vulnerable field. Payload is stored in an admin area, resulting in high confidentiality and integrity impact.

An unsafe default configuration in KNIME Analytics Platform before 5.2.0 allows for a cross-site scripting attack. When KNIME Analytics Platform is used as an executor for either KNIME Server or KNIME Business Hub several JavaScript-based view nodes do not sanitize the data that is displayed by default. If the data to be displayed contains JavaScript this code is executed in the browser and can perform any operations that the current user is allowed to perform silently. KNIME Analytics Platform already has configuration options with which sanitization of data can be actived, see https://docs.knime.com/latest/webportal_admin_guide/index.html#html-sanitization-webportal https://docs.knime.com/latest/webportal_admin_guide/index.html#html-sanitization-webportal . However, these are off by default which allows for cross-site scripting attacks. KNIME Analytics Platform 5.2.0 will enable sanitization by default. For all previous releases we recommend users to add the corresponding settings to the executor's knime.ini.

Undici is an HTTP/1.1 client written from scratch for Node.js. Prior to version 5.26.2, Undici already cleared Authorization headers on cross-origin redirects, but did not clear `Cookie` headers. By design, `cookie` headers are forbidden request headers, disallowing them to be set in RequestInit.headers in browser environments. Since undici handles headers more liberally than the spec, there was a disconnect from the assumptions the spec made, and undici's implementation of fetch. As such this may lead to accidental leakage of cookie to a third-party site or a malicious attacker who can control the redirection target (ie. an open redirector) to leak the cookie to the third party site. This was patched in version 5.26.2. There are no known workarounds.

A stored cross-site scripting (XSS) vulnerability exists in the upload_brand.cgi functionality of peplink Surf SOHO HW1 v6.3.5 (in QEMU). A specially crafted HTTP request can lead to execution of arbitrary javascript in another user's browser. An attacker can make an authenticated HTTP request to trigger this vulnerability.

A vulnerability has been identified in Xpedition Layout Browser (All versions < VX.2.14). Affected application contains a stack overflow vulnerability when parsing a PCB file. An attacker can leverage this vulnerability to execute code in the context of the current process.

Wazuh is a security detection, visibility, and compliance open source project. In versions 4.4.0 and 4.4.1, it is possible to get the Wazuh API administrator key used by the Dashboard using the browser development tools. This allows a logged user to the dashboard to become administrator of the API, even if their dashboard role is not. Version 4.4.2 contains a fix. There are no known workarounds.

Improper Neutralization of Input During Web Page Generation (’Cross-site Scripting’) in RDT400 in SICK APU allows an unprivileged remote attacker to run arbitrary code in the clients browser via injecting code into the website.

A cross-site scripting vulnerability exists in Citadel versions prior to 994. When a malicious user sends an instant message with some JavaScript code, the script may be executed on the web browser of the victim user.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "specials_type_name[1]" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "featured_type_name[1]" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "formats_titles[7]" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "name" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "company_address" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.

Os Commerce is currently susceptible to a Cross-Site Scripting (XSS) vulnerability. This vulnerability allows attackers to inject JS through the "tax_class_title" parameter, potentially leading to unauthorized execution of scripts within a user's web browser.