Mingyu Chen

**Name of the Vulnerable Software and Affected Versions** Apache Doris versions 1.2.0 through 2.0.4 **Description** The issue is related to the download of code without integrity check in Apache Doris, which may result in remote command execution. An attacker authorized to create a JDBC catalog can use an arbitrary driver jar file with an unchecked code snippet, which will be run when the catalog is initializing without any check. **Recommendations** For Apache Doris versions 1.2.0 through 2.0.4, users are recommended to upgrade to version 2.0.5 or 2.1.x, which fixes the issue. As a temporary workaround, consider restricting access to the JDBC catalog creation functionality to minimize the risk of exploitation. Additionally, avoid using arbitrary driver jar files with unchecked code snippets in the affected API endpoints until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Apache Doris versions prior to 1.2.8 Apache Doris versions prior to 2.0.4 **Description** The issue is related to a possible race condition vulnerability in Apache Doris, where some code uses the `chmod()` method. This method poses a risk of someone renaming a file out from under the user and chmodding the wrong file. The impact of this issue is considered minimal. **Recommendations** For Apache Doris versions prior to 1.2.8, upgrade to version 2.0.4 or later, which fixes the issue. For Apache Doris versions prior to 2.0.4, upgrade to version 2.0.4 or later, which fixes the issue. As a temporary workaround, consider restricting access to the `chmod()` method until a patch is available.

**Name of the Vulnerable Software and Affected Versions** SoftwareX versions prior to 2.0.3 **Description** The issue allows unauthenticated access through the API endpoints "/api/snapshot" and "/api/get log file". This could potentially lead to a DoS attack or allow an attacker to retrieve arbitrary files from the FE node. **Recommendations** For versions prior to 2.0.3, upgrade to version 2.0.3 to fix the issue. As a temporary workaround, consider restricting access to the "/api/snapshot" and "/api/get log file" API endpoints to minimize the risk of exploitation.