# CVE-2026-111441: openGauss HllObjectUnpack buffer overflow in HLL parsing

Source: https://junglewise.ai/threats/cve-2026-111441-opengauss-server-src-gausskernel-cbb-utils-hll-hll-cpp  
Publisher: Junglewise Threat Intelligence, https://junglewise.ai/threats  
Published: 2026-10-19. Updated: 2026-10-19  
License: CC BY 4.0 with a link back

CVE-2026-111441 · Severity: high · CVSS 8.1 · Published 2026-10-19

openGauss is an open-source relational database. The HLL (HyperLogLog) data type parser in openGauss has a buffer overflow vulnerability: when parsing user-supplied HLL data, the function fails to properly validate length fields, allowing an attacker with database access to craft malicious input that triggers a heap buffer overflow and potentially corrupt memory or crash the database.

Vendors: [openGauss](https://junglewise.ai/threats/vendors/opengauss).

## Quick answers

**Is CVE-2026-111441 exploited in the wild?** No. Junglewise Threat Intelligence has no report of CVE-2026-111441 being exploited in the wild.

**How severe is CVE-2026-111441?** High severity, with a CVSS score of 8.1, published 19 October 2026.

**Which products and versions are affected?** openGauss 2.1.0, 3.0.x, 3.1.x, 5.0.x, 5.1.0, 6.0.x, 7.0.0-RC1, 7.0.0-RC2, 7.0.0-RC3.

**Is there a fix for CVE-2026-111441?** Yes: fixed in 7.0.0-LTS. Until then: <UNKNOWN> Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.

**How is CVE-2026-111441 attacked?** It is attacked over the network, in a software library.

**Am I affected by CVE-2026-111441?** Check whether you run openGauss at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

## How to fix

- Fixed in 7.0.0-LTS

<UNKNOWN>

## Technical details

The HllObjectUnpack() function in src/gausskernel/cbb/utils/hll/hll.cpp parses lenUsed and lenTotal fields from user-provided packed HLL data but fails to validate that lenTotal >= lenUsed. It then allocates a buffer of size lenTotal but calls memcpy_s() with a destination size of lenUsed, allowing out-of-bounds writes that bypass the safe copy check. This can be triggered by any database user through SQL entry points like hll_in(), hll_print(), and hll_cardinality() by constructing a malformed HLL with lenTotal < lenUsed.

## Affected products

- openGauss openGauss 2.1.0, 3.0.x, 3.1.x, 5.0.x, 5.1.0, 6.0.x, 7.0.0-RC1, 7.0.0-RC2, 7.0.0-RC3

## Timeline

- 2026-10-19: disclosed
- 2026: patched: Fixed in 7.0.0-LTS by adding lenUsed <= lenTotal validation and correcting memcpy_s destination size

## References

- [https://opengauss.org/zh/download/archive/?version=7.0.0%20(LTS)](https://opengauss.org/zh/download/archive/?version=7.0.0%20(LTS))
- [https://opengauss.org/zh/download/archive/?version=7.0.0-RC3](https://opengauss.org/zh/download/archive/?version=7.0.0-RC3)

## Related threats

- [openGauss authorization bypass in pg_read_binary_file_blocks](https://junglewise.ai/threats/cve-2026-111439-opengauss-server-src-common-backend-utils-adt-genfile-cpp-pg)