uscat, as of 2021-12-28, is vulnerable to Cross Site Scripting (XSS) via "close registration information" input box.

uscat, as of 2021-12-28, is vulnerable to Cross Site Scripting (XSS) via the input box of the statistical code.

The vulnerability origins in the commissioning process where an attacker of the ControlTouch can enter a serial number in a specific way to transfer the device virtually into her/his my.busch-jaeger.de or mybuildings.abb.com profile. A successful attacker can observe and control a ControlTouch remotely under very specific circumstances. The issue is fixed in the cloud side of the system. No firmware update is needed for customer products. If a user wants to understand if (s)he is affected, please read the advisory. This issue affects: ABB and Busch-Jaeger, ControlTouch

The backup function in ABB Telephone Gateway TG/S 3.2 and Busch-Jaeger 6186/11 Telefon-Gateway saves the current settings and configuration of the application, including credentials of existing user accounts and other configuration's credentials in plaintext.

The Configuration pages in ABB Telephone Gateway TG/S 3.2 and Busch-Jaeger 6186/11 Telefon-Gateway for user profiles and services transfer the password in plaintext (although hidden when displayed).

Improper implementation of Access Control in ABB Telephone Gateway TG/S 3.2 and Busch-Jaeger 6186/11 Telefon-Gateway allows an unauthorized user to access data marked as restricted, such as viewing or editing user profiles and application settings.

The web server in ABB Telephone Gateway TG/S 3.2 and Busch-Jaeger 6186/11 Telefon-Gateway allows access to different endpoints of the application without authenticating by accessing a specific uniform resource locator (URL) , violating the access-control (ACL) rules. This issue allows obtaining sensitive information that may aid in further attacks and privilege escalation.

An issue was discovered in USC iLab cereal through 1.3.0. It employs caching of std::shared_ptr values, using the raw pointer address as a unique identifier. This becomes problematic if an std::shared_ptr variable goes out of scope and is freed, and a new std::shared_ptr is allocated at the same address. Serialization fidelity thereby becomes dependent upon memory layout. In short, serialized std::shared_ptr variables cannot always be expected to serialize back into their original values. This can have any number of consequences, depending on the context within which this manifests.

An issue was discovered in USC iLab cereal through 1.3.0. Serialization of an (initialized) C/C++ long double variable into a BinaryArchive or PortableBinaryArchive leaks several bytes of stack or heap memory, from which sensitive information (such as memory layout or private keys) can be gleaned if the archive is distributed outside of a trusted context.

Multiple SQL injection vulnerabilities in ZeusCart 4.x.