Multiple stored cross-site scripting (XSS) vulnerabilities in TeamPass before 2.1.27.9 allow authenticated remote attackers to inject arbitrary web script or HTML via the (1) URL value of an item or (2) user log history. To exploit the vulnerability, the attacker must be first authenticated to the application. For the first one, the attacker has to simply inject XSS code within the URL field of a shared item. For the second one however, the attacker must prepare a payload within its profile, and then ask an administrator to modify its profile. From there, whenever the administrator accesses the log, it can be XSS'ed.

Firmware upgrade authentication bypass vulnerability was found in Dahua IPC-HDW4300S and some IP products. The vulnerability was caused by internal Debug function. This particular function was used for problem analysis and performance tuning during product development phase. It allowed the device to receive only specific data (one direction, no transmit) and therefore it was not involved in any instance of collecting user privacy data or allowing remote code execution.

When libvirtd is configured by OSP director (tripleo-heat-templates) to use the TLS transport it defaults to the same certificate authority as all non-libvirtd services. As no additional authentication is configured this allows these services to connect to libvirtd (which is equivalent to root access). If a vulnerability exists in another service it could, combined with this flaw, be exploited to escalate privileges to gain control over compute nodes.

The Hipchat for Mac desktop client is vulnerable to client-side remote code execution via video call link parsing. Hipchat for Mac desktop clients at or above version 4.0 and before version 4.30 are affected by this vulnerability.

A Server Side Request Forgery (SSRF) vulnerability could lead to remote code execution for authenticated administrators. This issue was introduced in version 2.2.0 of Hipchat Server and version 3.0.0 of Hipchat Data Center. Versions of Hipchat Server starting with 2.2.0 and before 2.2.6 are affected by this vulnerability. Versions of Hipchat Data Center starting with 3.0.0 and before 3.1.0 are affected.

In Zulip Server before 1.7.1, on a server with multiple realms, a vulnerability in the invitation system lets an authorized user of one realm on the server create a user account on any other realm.

A vulnerability in Swagger-Parser's version <= 1.0.30 and Swagger codegen version <= 2.2.2 yaml parsing functionality results in arbitrary code being executed when a maliciously crafted yaml Open-API specification is parsed. This in particular, affects the 'generate' and 'validate' command in swagger-codegen (<= 2.2.2) and can lead to arbitrary code being executed when these commands are used on a well-crafted yaml specification.

Command injection in evince via filename when printing to PDF. This affects versions earlier than 3.25.91.

An attacker submitting facts to the Foreman server containing HTML can cause a stored XSS on certain pages: (1) Facts page, when clicking on the "chart" button and hovering over the chart; (2) Trends page, when checking the graph for a trend based on a such fact; (3) Statistics page, for facts that are aggregated on this page.

typed-function before 0.10.6 had an arbitrary code execution in the JavaScript engine. Creating a typed function with JavaScript code in the name could result arbitrary execution.

math.js before 3.17.0 had an issue where private properties such as a constructor could be replaced by using unicode characters when creating an object.

math.js before 3.17.0 had an arbitrary code execution in the JavaScript engine. Creating a typed function with JavaScript code in the name could result arbitrary execution.

GitPHP by xiphux is vulnerable to OS Command Injections

In Pivotal Spring AMQP versions prior to 1.7.4, 1.6.11, and 1.5.7, an org.springframework.amqp.core.Message may be unsafely deserialized when being converted into a string. A malicious payload could be crafted to exploit this and enable a remote code execution attack.

In Pivotal Single Sign-On for PCF (1.3.x versions prior to 1.3.4 and 1.4.x versions prior to 1.4.3), certain pages allow code to be injected into the DOM environment through query parameters, leading to XSS attacks.

An issue was discovered in Pivotal Spring Web Flow through 2.4.5. Applications that do not change the value of the MvcViewFactoryCreator useSpringBinding property which is disabled by default (i.e., set to 'false') can be vulnerable to malicious EL expressions in view states that process form submissions but do not have a sub-element to declare explicit data binding property mappings. NOTE: this issue exists because of an incomplete fix for CVE-2017-4971.

In Cloud Foundry Foundation Credhub-release version 1.1.0, access control lists (ACLs) enforce whether an authenticated user can perform an operation on a credential. For installations using ACLs, the ACL was bypassed for the CredHub interpolate endpoint, allowing authenticated applications to view any credential within the CredHub installation.

An issue was discovered in Cloud Foundry Foundation cf-release (all versions prior to v279) and UAA (30.x versions prior to 30.6, 45.x versions prior to 45.4, 52.x versions prior to 52.1). In some cases, the UAA allows an authenticated user for a particular client to revoke client tokens for other users on the same client. This occurs only if the client is using opaque tokens or JWT tokens validated using the check_token endpoint. A malicious actor could cause denial of service.

In Pivotal Spring-LDAP versions 1.3.0 - 2.3.1, when connected to some LDAP servers, when no additional attributes are bound, and when using LDAP BindAuthenticator with org.springframework.ldap.core.support.DefaultTlsDirContextAuthenticationStrategy as the authentication strategy, and setting userSearch, authentication is allowed with an arbitrary password when the username is correct. This occurs because some LDAP vendors require an explicit operation for the LDAP bind to take effect.

An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets." Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security's Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) "deserialization gadget" that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown "deserialization gadgets" when Spring Security enables default typing.