CVE-2026-111440: Unsafe Reflection in openGauss-connector-jdbc's LogFactory

Overview

openGauss-connector-jdbc, the openGauss project's PostgreSQL JDBC driver fork (a "pgjdbc" derivative used to connect Java applications to openGauss databases), is affected by a high-severity unsafe reflection vulnerability tracked as CVE-2026-111440. The flaw carries a CVSS 3.1 score of 7.0 (High), with vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H, and was published on October 19, 2026 (reserved October 16, 2026).

The vulnerability lives in LogFactory.java (pgjdbc/src/main/java/org/postgresql/log/LogFactory.java), the component responsible for instantiating the driver's logging implementation. According to the NVD description, LogFactory loads a class via Class.forName based on the logger class name supplied through JDBC connection parameters — either in the connection URL or in the properties object passed to the driver — and then directly reflects into that class's String-argument constructor, casting the result to the driver's internal Log type. The code is missing an asSubclass(Log.class) check, so classes that are not Log implementations can be instantiated before any type validation occurs. An attacker who controls the logger connection parameter, paired with a loadable "gadget" class already present on the client application's classpath, can trigger unintended construction of an arbitrary class on the JDBC client side.

This pattern echoes earlier, real-world JDBC driver issues — including CVE-2022-21724 (pgjdbc's authenticationPluginClassName trust-boundary violation) and historical MySQL Connector/J "logger"/"detectServerKeepAlive" gadget-chain problems — where connection-time class-name parameters became an unsafe-reflection primitive on the client. The openGauss project (as CNA) fixed the issue in 7.0.0-LTS by reordering the logic so asSubclass(Log.class) runs immediately after Class.forName, before construction, via GitCode pull request #423. Beyond the NVD record and that patch, public technical detail is limited — openGauss-connector-jdbc is a lower-profile, regionally-focused project, and no CISA KEV listing or independent proof-of-concept was found at the time of publication. This advisory is written from the NVD description together with publicly indexed vulnerability-database summaries (VulDB, EUVD, Strix) that mirror it; CosmicBytez Labs will update it if more detail becomes available.

Technical Details

How It Works

What LogFactory does

LogFactory is the driver's internal mechanism for selecting which Log implementation handles diagnostic output for a given connection. Historic pgjdbc-derived drivers expose a connection property that lets an application plug in a custom logging class by name rather than being locked to a single built-in logger. That design is reasonable in principle — but it means the class name itself arrives as untrusted, attacker-influenceable configuration data, which is exactly the kind of value that needs rigorous validation before it is used to instantiate anything.

Root cause

Per the NVD description, when a connection is established, LogFactory takes the logger class name from the JDBC URL or connection properties and calls Class.forName(loggerClassName) to load it. Immediately afterward, the code reflects into that class's String-argument constructor and invokes it, then casts the resulting object to Log. The missing step is a call to asSubclass(Log.class) between loading the class and constructing it — the check that would confirm the loaded class is actually a valid Log implementation before any code from it runs. Because that validation never happens, any class on the client's classpath with a compatible single-String constructor can be instantiated, regardless of whether it has anything to do with logging. The cast to Log only fails — if it fails at all — after the constructor has already executed, which is too late to prevent any side effects the constructor itself produces.

Attack chain

1. Attacker gains the ability to influence the "logger" JDBC
   connection parameter — e.g. a JDBC URL or properties object
   built in part from attacker-controlled input, or a connection
   string shipped in attacker-modifiable configuration.
2. Attacker sets logger to the fully-qualified name of a class
   already present on the client application's classpath that
   has a single-String constructor with useful side effects
   (a "gadget" class).
3. On connection setup, LogFactory calls Class.forName(logger)
   and loads the class.
4. LogFactory reflects into the class's String constructor and
   invokes it BEFORE checking asSubclass(Log.class).
5. The gadget class's constructor runs with attacker-chosen
   input, on the JDBC client, regardless of whether the class
   is a legitimate Log implementation.
6. Only after construction does the code attempt (and fail) to
   cast the result to Log -- by which point any constructor
   side effects have already occurred.

Why this matters for JDBC-consuming applications

The practical severity of this bug depends heavily on what "gadget" classes are reachable on a given application's classpath — the vulnerability itself is a primitive, not a guaranteed remote-code-execution exploit, which is reflected in the CVSS vector's AV:L (local attack vector) and AC:H (high attack complexity) components. The realistic exposure is applications that construct JDBC connection URLs or properties from external or user-influenceable input (a known anti-pattern that has produced real CVEs in other PostgreSQL- and MySQL-derived JDBC drivers), or environments where a shared/templated connection string can be tampered with before it reaches the driver. Combined with a sufficiently dangerous class on the classpath — a known risk surface given how much logging, serialization, and templating tooling typically ships alongside enterprise Java applications — this unsafe-reflection primitive could be escalated toward denial of service, information disclosure, or further code execution.

Impact Assessment

Recommendations

For developers and administrators using openGauss-connector-jdbc

1. Upgrade to openGauss-connector-jdbc 7.0.0-LTS or later. This is the vendor-confirmed fix for CVE-2026-111440; versions 1.1.0 through 6.0.6 and 7.0.0-RC1 through RC3 remain exposed.
2. Audit how JDBC connection URLs and properties are constructed in your applications. Never build connection strings or property maps — especially the logger parameter — from user-supplied, external, or otherwise untrusted input.
3. Pin and validate connection configuration at the application layer; treat JDBC URLs the same way you would treat any other externally-influenceable configuration surface, with strict allow-listing of acceptable values.
4. Review classpath contents for known gadget classes (common in logging frameworks, template engines, and serialization libraries) if you cannot immediately patch, since the practical impact of this flaw depends on what is reachable at runtime.

For security and AppSec teams

1. Inventory applications using openGauss-connector-jdbc (or other pgjdbc-derived drivers) across your Java estate and confirm driver versions against the fixed release.
2. Apply the same scrutiny to JDBC driver dependencies as to application frameworks — unsafe-reflection and class-loading bugs in database drivers have a track record (CVE-2022-21724 and similar MySQL Connector/J issues) and are easy to overlook during routine dependency reviews.
3. Monitor for anomalous class loading or unexpected object construction in application logs following database connection events, particularly in environments where connection parameters pass through configuration templating or multi-tenant provisioning.

For software supply-chain / dependency management

1. Track this CVE in SCA tooling and flag any pinned openGauss-connector-jdbc version at or below 6.0.6, or in the 7.0.0-RC1–RC3 range, for upgrade.
2. Review downstream consumers — any internal library, ORM wrapper, or data-access layer that bundles or recommends openGauss-connector-jdbc should be updated and re-published alongside the driver fix.

Key Takeaways

1. CVE-2026-111440 is a CVSS 7.0 High-severity unsafe reflection flaw (CWE-470) in openGauss-connector-jdbc's LogFactory class.
2. The root cause is a missing asSubclass(Log.class) validation: the driver loads a class named in the logger JDBC connection parameter via Class.forName and reflects into its String constructor before confirming it is actually a Log implementation.
3. Exploitation requires an attacker-controlled logger parameter value plus a usable "gadget" class already on the client application's classpath — reflected in the CVSS vector's local attack vector and high attack complexity.
4. The issue affects versions 1.1.0 through 6.0.6 and 7.0.0-RC1 through RC3; it is fixed in 7.0.0-LTS via GitCode pull request #423.
5. No confirmed in-the-wild exploitation or CISA KEV listing exists as of October 19, 2026, and EPSS scores the near-term exploitation probability as low.
6. This bug mirrors a known class of JDBC driver issues — connection-parameter-driven class instantiation — seen previously in pgjdbc (CVE-2022-21724) and MySQL Connector/J; applications that build connection strings from untrusted input are the realistic exposure path.

Sources

• NVD — CVE-2026-111440
• VulDB — CVE-2026-111440
• Strix — CVE-2026-111440
• GitCode — opengauss/openGauss-connector-jdbc pull request #423

CosmicBytez Labs will update this advisory if the openGauss project or independent researchers publish additional technical detail on CVE-2026-111440.