openGauss JDBC CVE-2026-111440

The attacker must control the JDBC 'logger' connection parameter - supplied either in the JDBC URL or in connection properties - which names the logger class that LogFactory loads. Exploitation additionally requires that a class with a String-argument constructor and exploitable construction side effects already exists on the client's classpath, since the driver instantiates the named class before the (missing) Log subtype check. Limiting factors: this is NOT remote-unauthenticated against a default configuration - it requires the ability to influence connection configuration (local/config-level access, PR:L) and the presence of a suitable gadget class, which makes the attack high-complexity (AC:H). Affected versions are JDBC 1.1.0 and later 2.x/3.x/5.x/6.x (through 6.0.6) and 7.0.0-RC1/RC2/RC3; fixed in 7.0.0-LTS.

The provided CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, base 7.0 High) describes a constrained, precondition-heavy flaw rather than a mass-exploitable one. AV:L and PR:L together mean the attacker must already be able to influence the application's JDBC connection configuration (URL or connection properties), and AC:H reflects the dependency on a suitable loadable 'gadget' class with an exploitable String-argument constructor being present on the client classpath. No EPSS score, no CISA KEV listing, and no PoC were supplied, so exploitation status is 'no public exploit identified at time of analysis' - this is an unsafe-reflection (CWE-470) hardening gap, not an actively exploited bug. The C:H/I:H/A:H impact is largely theoretical/gadget-dependent: by itself the defect only instantiates an attacker-named class via its String constructor before the asSubclass type check, so actual confidentiality/integrity/availability impact hinges entirely on what is already on the classpath. The 'Information Disclosure' tag understates the broader class-loading/construction-side-effect nature of the issue. Net assessment: lower real-world priority than the 7.0 implies for most deployments - prioritize patching where connection strings are attacker-influenceable (multi-tenant apps, config-injection exposure). One signal to verify: AV:L assumes connection parameters are set via local/config control; if an application accepts JDBC connection parameters from untrusted network input, the effective attack vector could be closer to network - verify against the actual deployment.

An attacker who can influence an application's JDBC connection URL or properties (e.g., via config injection or an application that builds the connection string from untrusted input) sets the 'logger' parameter to the name of a class already present on the client classpath. When the driver connects, LogFactory loads and reflectively instantiates that class through its String constructor before any type validation, triggering unintended class loading and constructor side effects on the client host. No public PoC exists; realized impact depends on a suitable gadget class being available, consistent with the AC:H rating.