OpenGauss - CraftedSignal Threat Feedhttps://feed.craftedsignal.io/vendors/opengauss/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioMon, 19 Oct 2026 04:57:39 +0000https://feed.craftedsignal.io/favicon-32x32.pngCraftedSignal Threat Feedhttps://feed.craftedsignal.io/3232https://feed.craftedsignal.io/favicon.svgArbitrary Class Instantiation in openGauss-connector-jdbchttps://feed.craftedsignal.io/briefs/2026-10-opengauss-jdbc-vulnerability/Mon, 19 Oct 2026 04:57:39 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-opengauss-jdbc-vulnerability/A vulnerability in the LogFactory component of openGauss-connector-jdbc allows attackers to trigger arbitrary class instantiation via reflection by controlling JDBC logger class parameters.The openGauss-connector-jdbc library contains a deserialization-style vulnerability located in the LogFactory.java class. The vulnerability stems from an insecure implementation of the logger class loading mechanism, where the application uses Class.forName to load a class specified by the JDBC connection string or properties. The LogFactory subsequently invokes the constructor of the loaded class via reflection and casts it to a Log type without performing proper type validation using asSubclass(Log.class).

An attacker who can influence the JDBC connection properties or the JDBC URL can specify an arbitrary class name that exists within the application's classpath. Because the library fails to verify that the specified class implements the Log interface before instantiation, the constructor of the attacker-supplied class is executed. This can result in unintended code execution or side effects on the client side, depending on the side effects triggered by the target class constructor. This vulnerability affects versions 1.1.0 through 6.0.6, as well as 7.0.0-RC1, 7.0.0-RC2, and 7.0.0-RC3.

Impact

Successful exploitation allows an attacker to instantiate arbitrary classes present in the application classpath during the initialization of a database connection. This can lead to local code execution or other malicious side effects on the client application depending on the available gadgets within the victim's runtime environment. The impact is significant for applications that accept database configuration from untrusted sources, such as multi-tenant platforms or web applications allowing user-defined database connectivity settings.

Recommendation

Prioritized actions for mitigation and defense:

  • Upgrade the openGauss-connector-jdbc library to version 7.0.0-LTS or higher to incorporate the asSubclass(Log.class) type validation fix.
  • Audit all application code paths that allow external inputs to modify JDBC connection parameters, particularly the logger configuration settings.
  • Implement strict input validation or allowlisting for JDBC connection parameters if upgrading the library is not immediately feasible.
]]>highadvisoryvulnerabilitydeserializationremote-code-executionHeap-Based Buffer Overflow in openGauss HllObjectUnpackhttps://feed.craftedsignal.io/briefs/2026-10-opengauss-heap-overflow/Mon, 19 Oct 2026 04:57:32 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-10-opengauss-heap-overflow/A heap-based buffer overflow in the HllObjectUnpack function of openGauss-server allows authenticated database users to achieve memory corruption via malformed HyperLogLog (HLL) objects.CVE-2026-111441 is a heap-based buffer overflow vulnerability residing in the HllObjectUnpack() function within the openGauss-server codebase (specifically src/gausskernel/cbb/utils/hll/hll.cpp). The vulnerability stems from improper length validation when processing packed HLL objects. The affected function parses 'lenUsed' and 'lenTotal' fields from user-supplied input; however, it fails to verify that 'lenTotal' is greater than or equal to 'lenUsed'. When allocating memory for the HLL object based on the potentially smaller 'lenTotal' and subsequently performing a memory copy using 'memcpy_s', the function uses 'lenUsed' as the destination size instead of the actual buffer size, resulting in an out-of-bounds heap write. This flaw is reachable via standard SQL entry points including hll_in(), hll_print(), and hll_cardinality(). The vulnerability affects versions 2.1.0 through 7.0.0-RC3 and was addressed in the 7.0.0-LTS release. An authenticated database user can leverage this to trigger memory corruption, potentially leading to a crash or arbitrary code execution.

Impact

Successful exploitation allows an authenticated user with standard database access privileges to trigger memory corruption on the database server. This can lead to service disruption via application crash or potentially remote code execution within the context of the database service. The vulnerability impacts a wide range of versions, including 2.1.0, 3.0.x, 3.1.x, 5.0.x, 5.1.0, 6.0.x, and 7.0.0-RC variants, potentially affecting any enterprise deployment utilizing the HLL utility functions.

Recommendation

  • Upgrade openGauss-server to version 7.0.0-LTS or higher to incorporate the fix for CVE-2026-111441.
  • Review the implementation of the HllObjectUnpack() function as described in the fix provided in PR #9380 at https://gitcode.com/opengauss/openGauss-server/pull/9380.
  • Audit database access logs to identify users invoking HLL-related functions, as these entry points are necessary to trigger the overflow.
]]>highadvisory