CVE-2026-111440
7.0HighPublished 19 Oct 2026 · NVD status: Received · AI triage by gemini-3.8-flash
- Attack vector
- Local
- Complexity
- High
- Privileges needed
- Low
- User interaction
- None
- Impact
- Full C/I/A compromise
- Weakness
- CWE-470
Impact
Attackers who can supply JDBC connection parameters can trigger arbitrary class instantiation on the client. This requires the attacker to control the JDBC URL or connection properties.
Root cause
LogFactory instantiates arbitrary classes from the logger parameter using reflection before validating that the class implements the Log interface.
Affected systems
openGauss-connector-jdbc 1.1.0 through 6.0.6 (including all 2.x, 3.x, 5.x, 6.x releases) and 7.0.0-RC1 through 7.0.0-RC3
CVSS v3.1 · CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
Fix & remediation
Upgrade openGauss-connector-jdbc to version 7.0.0-LTS. As an interim workaround, sanitize or disallow untrusted input in JDBC connection URLs and properties, specifically blocking the logger attribute.
AI-suggested. Run it in staging first and check it against the vendor advisory. Why?
NVD description
在 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。