#java

An issue was discovered in Papaya Viewer 4a42701. User-supplied input in form of DICOM or NIFTI images can be loaded into the Papaya web application without any kind of sanitization. This allows injection of arbitrary JavaScript code into image metadata, which is executed when that metadata is displayed in the Papaya web application

A flaw was found in Keycloak. This flaw depends on a non-default configuration "Revalidate Client Certificate" to be enabled and the reverse proxy is not validating the certificate before Keycloak. Using this method an attacker may choose the certificate which will be validated by the server. If this happens and the KC_SPI_TRUSTSTORE_FILE_FILE variable is missing/misconfigured, any trustfile may be accepted with the logging information of "Cannot validate client certificate trust: Truststore not available". This may not impact availability as the attacker would have no access to the server, but consumer applications Integrity or Confidentiality may be impacted considering a possible access to them. Considering the environment is correctly set to use "Revalidate Client Certificate" this flaw is avoidable.

In Spring Boot versions 3.0.0 - 3.0.6, 2.7.0 - 2.7.11, 2.6.0 - 2.6.14, 2.5.0 - 2.5.14 and older unsupported versions, there is potential for a denial-of-service (DoS) attack if Spring MVC is used together with a reverse proxy cache. Specifically, an application is vulnerable if all of the conditions are true: * The application has Spring MVC auto-configuration enabled. This is the case by default if Spring MVC is on the classpath. * The application makes use of Spring Boot's welcome page support, either static or templated. * Your application is deployed behind a proxy which caches 404 responses. Your application is NOT vulnerable if any of the following are true: * Spring MVC auto-configuration is disabled. This is true if WebMvcAutoConfiguration is explicitly excluded, if Spring MVC is not on the classpath, or if spring.main.web-application-type is set to a value other than SERVLET. * The application does not use Spring Boot's welcome page support. * You do not have a proxy which...

NSX-T contains a reflected cross-site scripting vulnerability due to a lack of input validation. A remote attacker can inject HTML or JavaScript to redirect to malicious pages.

A lateral privilege escalation vulnerability in XXL-Job v2.4.1 allows users to execute arbitrary commands on another user's account via a crafted POST request to the component /jobinfo/.

skycaiji v2.5.4 is vulnerable to Cross Site Scripting (XSS). Attackers can achieve backend XSS by deploying malicious JSON data.

Red Hat Security Advisory 2023-3323-01 - Go Toolset provides the Go programming language tools and libraries. Go is alternatively known as golang.

Red Hat Security Advisory 2023-3319-01 - Go Toolset provides the Go programming language tools and libraries. Go is alternatively known as golang.

WBCE CMS version 1.6.1 suffers from a cross site scripting vulnerability.

### Impact Highlight may record passwords on customer deployments when a password html input is switched to `type="text"` via a javascript "Show Password" button. This differs from the expected behavior which always obfuscates `type="password"` inputs. A customer may assume that switching to `type="text"` would also not record this input; hence, they would not add additional `highlight-mask` css-class obfuscation to this part of the DOM, resulting in unintentional recording of a password value when a `Show Password` button is used. ### Patches `[email protected]` resolves the issue via https://github.com/rrweb-io/rrweb/pull/1184 This patch tracks changes to the `type` attribute of an input to ensure an input that used to be a `type="password"` continues to be obfuscated. ### Workarounds We have deployed a change to our data ingest to obfuscate passwords server side from older clients. This means that upgrading to the latest version of highlight.run is not necessary but recommended...