CVE-2026-111440 in openGauss-connector-jdbc
Summary
by MITRE • 10/19/2026
在 openGauss-connector-jdbc 的 pgjdbc/src/main/java/org/postgresql/log/LogFactory.java 中，LogFactory 根据 JDBC 连接参数中的 logger 类名调用 Class.forName 加载类后，直接反射调用以 String 为参数的构造函数，再转换为 Log。缺少 asSubclass(Log.class) 校验，非 Log 实现类也会在类型检查前被实例化。因此，当攻击者可控制 JDBC URL 或连接属性中的 logger 类名，且客户端 classpath 中存在可被加载的类时，可能在客户端触发非预期的类加载与构造副作用。
此漏洞自 JDBC 1.1.0引入，影响 1.1.0 及之后的 2.x、3.x、5.x、6.x 各版本及补丁（含 6.0.0 分支最新 6.0.6），以及 7.0.0-RC1、7.0.0-RC2、7.0.0-RC3，并在 7.0.0-LTS 版本修复。修复在 Class.forName 之后先执行 asSubclass(Log.class)，仅允许 Log 子类进入构造。修复pr见https://gitcode.com/opengauss/openGauss-connector-jdbc/pull/423。
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in openGauss-connector-jdbc stems from a critical flaw within the LogFactory class, specifically located at pgjdbc/src/main/java/org/postgresql/log/LogFactory.java. This component is responsible for instantiating logging objects based on configuration parameters provided during JDBC connection establishment. The core technical deficiency lies in the sequence of operations performed when loading and initializing these logger classes. Upon receiving a logger class name from the JDBC URL or connection properties, the system invokes Class.forName to load the specified class into memory. Immediately following this step, the code attempts to instantiate an object by calling its constructor that accepts a String argument. Crucially, before performing any type verification to ensure the loaded class is actually a subclass of Log, the instantiation occurs without prior validation using asSubclass(Log.class). This omission means that if an attacker can control the logger class name parameter and there exists a malicious or unintended class on the client's classpath with a compatible String constructor, that arbitrary class will be instantiated.
This architectural flaw creates a significant security risk categorized under CWE-20 Improper Input Validation and potentially CWE-470 Use of Externally-Controlled Input to Select Classes or Code. The operational impact is severe because it allows for Unrestricted Class Loading when the attacker has control over JDBC connection parameters. By manipulating the logger class name, an adversary can trigger side effects associated with the static initialization blocks or constructors of arbitrary classes present in the application's environment. This could lead to remote code execution if a gadget chain exists within the available libraries, denial of service through resource exhaustion during complex object construction, or information disclosure via unintended method calls triggered by the instantiation process. The vulnerability has been present since JDBC version 1.1.0 and affects all subsequent major versions including 2.x, 3.x, 5.x, and 6.x up to patch level 6.0.6, as well as release candidates 7.0.0-RC1 through RC3. It was only remediated in the stable Long Term Support version 7.0.0-LTS.
The mitigation strategy implemented in the fixed versions addresses this issue by enforcing strict type checking prior to object instantiation. The corrected code now executes an asSubclass(Log.class) check immediately after Class.forName but before invoking any constructors. This ensures that only classes explicitly extending or implementing the Log interface are permitted to proceed with initialization, thereby preventing the loading and execution of arbitrary non-logging classes. Organizations running affected versions must upgrade to openGauss-connector-jdbc 7.0.0-LTS or later immediately. For environments where an immediate upgrade is not feasible, a temporary workaround involves strictly validating and whitelisting allowed logger class names at the application configuration layer before they are passed to the JDBC driver, ensuring that only known safe logging implementations can be specified in connection strings. This aligns with ATT&CK technique T1059 Command and Scripting Interpreter if the instantiated classes lead to script execution, or more broadly under Defense Evasion tactics involving library hijacking through improper input validation.