ghsa

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...

### Impact An attacker could crash the server by sending malformed JWT JSON in `LoginPacket` due to a security vulnerability in [`netresearch/jsonmapper`](https://github.com/cweiske/JsonMapper), due to accepting `NULL` values in arrays whose types do not expect `NULL`. ### Patches This problem was fixed in 5.3.1 and 4.23.1 by updating JsonMapper to include the following commit: pmmp/netresearch-jsonmapper@4f90e8dab1c9df331fad7d3d89823404e882668c ### Workarounds A plugin may handle `DataPacketReceiveEvent` for `LoginPacket` and check that none of the input arrays contain `NULL` where it's not expected, but this is rather cumbersome.

### Impact The server uses ECDH to calculate a shared secret for the symmetric encryption key used to encrypt network packets after logging in. ECDH requires that the keys used must both belong to the same elliptic curve. In Minecraft: Bedrock Edition, the curve used is `secp384r1`. Using any other curve (for example `secp256r1`) to sign the `LoginPacket` JWTs would lead to successfully verifying the login chain, but would later crash due to an uncaught exception during ECDH key derivation due to the client-provided key belonging to a different curve than the server's key. It's also theoretically possible that a non-EC key could be used (e.g. RSA or DH), which would also pass login verification as long as SHA384 hashing algorithm was used for the JWT signatures, and also lead to a crash. ### Patches The problem was fixed in 4.23.1 and 5.3.1 in the following commit: 4e646d19a4a1e0d082bd4d1f5a58ae0182a268d9 While 4.x would not have crashed when this was encountered, the faulty validati...