CVE’s

An issue was discovered in Couchbase Server 5.x and 6.x through 6.6.1 and 7.0.0 Beta. Incorrect commands to the REST API can result in leaked authentication information being stored in cleartext in the debug.log and info.log files, and is also shown in the UI visible to administrators.

An issue was discovered in Couchbase Server 5.x and 6.x before 6.5.2 and 6.6.x before 6.6.2. Internal users with administrator privileges, @cbq-engine-cbauth and @index-cbauth, leak credentials in cleartext in the indexer.log file when they make a /listCreateTokens, /listRebalanceTokens, or /listMetadataTokens call.

ZKConfigurationStore which is optionally used by CapacityScheduler of Apache Hadoop YARN deserializes data obtained from ZooKeeper without validation. An attacker having access to ZooKeeper can run arbitrary commands as YARN user by exploiting this. Users should upgrade to Apache Hadoop 2.10.2, 3.2.4, 3.3.4 or later (containing YARN-11126) if ZKConfigurationStore is used.

Each Apache Dubbo server will set a serialization id to tell the clients which serialization protocol it is working on. But for Dubbo versions before 2.7.8 or 2.6.9, an attacker can choose which serialization id the Provider will use by tampering with the byte preamble flags, aka, not following the server's instruction. This means that if a weak deserializer such as the Kryo and FST are somehow in code scope (e.g. if Kryo is somehow a part of a dependency), a remote unauthenticated attacker can tell the Provider to use the weak deserializer, and then proceed to exploit it.

In Apache Dubbo prior to 2.6.9 and 2.7.9, the usage of parseURL method will lead to the bypass of white host check which can cause open redirect or SSRF vulnerability.

LibreOffice supports digital signatures of ODF documents and macros within documents, presenting visual aids that no alteration of the document occurred since the last signing and that the signature is valid. An Improper Certificate Validation vulnerability in LibreOffice allowed an attacker to create a digitally signed ODF document, by manipulating the documentsignatures.xml or macrosignatures.xml stream within the document to contain both "X509Data" and "KeyValue" children of the "KeyInfo" tag, which when opened caused LibreOffice to verify using the "KeyValue" but to report verification with the unrelated "X509Data" value. This issue affects: The Document Foundation LibreOffice 7.2 versions prior to 7.2.5.

LibreOffice supports digital signatures of ODF documents and macros within documents, presenting visual aids that no alteration of the document occurred since the last signing and that the signature is valid. An Improper Certificate Validation vulnerability in LibreOffice allowed an attacker to modify a digitally signed ODF document to insert an additional signing time timestamp which LibreOffice would incorrectly present as a valid signature signed at the bogus signing time. This issue affects: The Document Foundation LibreOffice 7-0 versions prior to 7.0.6; 7-1 versions prior to 7.1.2.

LibreOffice supports digital signatures of ODF documents and macros within documents, presenting visual aids that no alteration of the document occurred since the last signing and that the signature is valid. An Improper Certificate Validation vulnerability in LibreOffice allowed an attacker to create a digitally signed ODF document, by manipulating the documentsignatures.xml or macrosignatures.xml stream within the document to combine multiple certificate data, which when opened caused LibreOffice to display a validly signed indicator but whose content was unrelated to the signature shown. This issue affects: The Document Foundation LibreOffice 7-0 versions prior to 7.0.6; 7-1 versions prior to 7.1.2.

In the LibreOffice 7-1 series in versions prior to 7.1.2, and in the 7-0 series in versions prior to 7.0.5, the denylist can be circumvented by manipulating the link so it doesn't match the denylist but results in ShellExecute attempting to launch an executable type.

"loolforkit" is a privileged program that is supposed to be run by a special, non-privileged "lool" user. Before doing anything else "loolforkit" checks, if it was invoked by the "lool" user, and refuses to run with privileges, if it's not the case. In the vulnerable version of "loolforkit" this check was wrong, so a normal user could start "loolforkit" and eventually get local root privileges.