When checking if the Browsing Context had been discarded in `HttpBaseChannel`, if the load group was not available then it was assumed to have already been discarded which was not always the case for private channels after the private session had ended. This vulnerability affects Firefox < 117, Firefox ESR < 115.2, and Thunderbird < 115.2.

A mishandled security check when creating a WebSocket in a WebWorker caused the Content Security Policy connect-src header to be ignored. This could lead to connections to restricted origins from inside WebWorkers. This vulnerability affects Firefox < 109, Firefox ESR < 102.7, and Thunderbird < 102.7.

A regression in the way hashes were calculated caused rules containing the address range syntax (x.x.x.x - y.y.y.y) that only differ in the address range(s) involved to be silently dropped as duplicates. Only the first of such rules is actually loaded into pf. Ranges expressed using the address[/mask-bits] syntax were not affected. Some keywords representing actions taken on a packet-matching rule, such as 'log', 'return tll', or 'dnpipe', may suffer from the same issue. It is unlikely that users have such configurations, as these rules would always be redundant. Affected rules are silently ignored, which can lead to unexpected behaviour including over- and underblocking.

free5gc UDM provides Unified Data Management (UDM) for free5GC, an open-source project for 5th generation (5G) mobile core networks. In versions up to and including 1.4.1, the service reliably leaks detailed internal error messages (e.g., strconv.ParseInt parsing errors) to remote clients when processing invalid pduSessionId inputs. This exposes implementation details and can be used for service fingerprinting. All deployments of free5GC using the UDM Nudm_UECM DELETE service may be vulnerable. free5gc/udm pull request 76 contains a fix for the issue. No direct workaround is available at the application level. Applying the official patch is recommended.

Issue summary: Applications using RSASVE key encapsulation to establish a secret encryption key can send contents of an uninitialized memory buffer to a malicious peer. Impact summary: The uninitialized buffer might contain sensitive data from the previous execution of the application process which leads to sensitive data leakage to an attacker. RSA_public_encrypt() returns the number of bytes written on success and -1 on error. The affected code tests only whether the return value is non-zero. As a result, if RSA encryption fails, encapsulation can still return success to the caller, set the output lengths, and leave the caller to use the contents of the ciphertext buffer as if a valid KEM ciphertext had been produced. If applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an attacker-supplied invalid RSA public key without first validating that key, then this may cause stale or uninitialized contents of the caller-provided ciphertext buffer to be disclosed to the attacker in place of the KEM ciphertext. As a workaround calling EVP_PKEY_public_check() or EVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate the issue. The FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.

WAL-G before 1.1, when a non-libsodium build (e.g., one of the official binary releases published as GitHub Releases) is used, silently ignores the libsodium encryption key and uploads cleartext backups. This is arguably a Principle of Least Surprise violation because "the user likely wanted to encrypt all file activity."

VirtualSquare picoTCP (aka PicoTCP-NG) through 2.1 does not properly check whether header sizes would result in accessing data outside of a packet.