ghsa

If a Jetty `OpenIdAuthenticator` uses the optional nested `LoginService`, and that `LoginService` decides to revoke an already authenticated user, then the current request will still treat the user as authenticated. The authentication is then cleared from the session and subsequent requests will not be treated as authenticated. So a request on a previously authenticated session could be allowed to bypass authentication after it had been rejected by the `LoginService`. ### Impact This impacts usages of the jetty-openid which have configured a nested `LoginService` and where that `LoginService` will is capable of rejecting previously authenticated users. ### Original Report > working on a custom OpenIdAuthenticator, I discovered the following: > > https://github.com/eclipse/jetty.project/blob/jetty-10.0.14/jetty-openid/src/main/java/org/eclipse/jetty/security/openid/OpenIdAuthenticator.java#L505 > > In the case where the LoginService does return that the authentication has been rev...

Cross-site Scripting (XSS) - Reflected in GitHub repository librenms/librenms prior to 23.9.0.

Code Injection in GitHub repository librenms/librenms prior to 23.9.0.

Cross-site Scripting (XSS) - DOM in GitHub repository librenms/librenms prior to 23.9.0.

Cross-site Scripting (XSS) - Generic in GitHub repository librenms/librenms prior to 23.9.0.

Cross-site Scripting (XSS) - DOM in GitHub repository librenms/librenms prior to 23.9.0.

Cross-site Scripting (XSS) - Stored in GitHub repository librenms/librenms prior to 23.9.0.

Froala Editor v4.0.1 to v4.1.1 was discovered to contain a cross-site scripting (XSS) vulnerability.

HashiCorp Vault and Vault Enterprise transit secrets engine allowed authorized users to specify arbitrary nonces, even with convergent encryption disabled. The encrypt endpoint, in combination with an offline attack, could be used to decrypt arbitrary ciphertext and potentially derive the authentication subkey when using transit secrets engine without convergent encryption. Introduced in 1.6.0 and fixed in 1.14.3, 1.13.7, and 1.12.11.

### Impact Wasmtime versions from 10.0.0 to 12.0.1 contain a miscompilation of the WebAssembly `i64x2.shr_s` instruction on x86_64 platforms when the shift amount is a constant value that is larger than 32. Only x86_64 is affected so all other targets are not affected by this. The miscompilation results in the instruction producing an incorrect result, namely the low 32-bits of the second lane of the vector are derived from the low 32-bits of the second lane of the input vector instead of the high 32-bits. The primary impact of this issue is that any WebAssembly program using the `i64x2.shr_s` with a constant shift amount larger than 32 may produce an incorrect result. This issue is not an escape from the WebAssembly sandbox. Execution of WebAssembly guest programs will still behave correctly with respect to memory sandboxing and isolation from the host. Wasmtime considers non-spec-compliant behavior as a security issue nonetheless. This issue was discovered through fuzzing of Wasmt...