openGauss Heap Buffer Overflow in HLL Object Unpacking Function
A flaw in openGauss allows ordinary database users to trigger heap writes, affecting multiple versions up to recent release candidates.
Key points
- CVSS 8.1 HIGH rated vulnerability in openGauss HLL functions
- Affects versions 2.1.0 through 7.0.0-RC3
- No confirmed fix for affected versions yet
A heap buffer overflow vulnerability in openGauss allows attackers to corrupt memory via crafted HyperLogLog objects. The flaw exists in the HllObjectUnpack function across multiple supported versions of the database server.
What happened
Researchers identified a length validation defect in the HllObjectUnpack function within openGauss-server. The issue allows an attacker to trigger a heap buffer overflow by providing malicious packed HLL data. This vulnerability has a CVSS score of 8.1, rated as high severity by the National Vulnerability Database. It was assigned identifier CVE-2026-111441 and is linked to CWE-122 weaknesses. The flaw originates in the src/gausskernel/cbb/utils/hll/hll.cpp source file. Affected versions include 2.1.0, 3.0.x, 3.1.x, 5.0.x, 5.1.0, and 6.0.x series. Additionally, release candidates 7.0.0-RC1, RC2, and RC3 are impacted. The vulnerability has been present since version 2.1.0.
Why it matters
Ordinary database connection users can exploit this flaw. By constructing malformed packed HLL objects, an attacker can cause the server to write beyond allocated memory boundaries. Functions such as hll_in, hll_print, and hll_cardinality all use the vulnerable unpacking path. This means any SQL query invoking these functions can trigger the memory corruption. The flaw occurs because the code fails to verify that lenTotal is greater than or equal to lenUsed. It also misconfigures the memcpy_s target size, disabling safety checks.
Next steps
- Audit all openGauss installations for affected version numbers
- Disable HLL functions if immediate patching is not possible
- Monitor system logs for unexpected memory access violations
- Verify vendor status for confirmed remediation updates
Detection notes
Teams usually monitor for anomalous process behaviour in database server logs. Check whether heap integrity checks have failed or unexpected crashes occurred during query execution. Look for spikes in memory usage or segmentation faults triggered by specific SQL functions. Contain the incident by isolating affected database instances from the network. Verify that no unauthorised code execution occurred after the crash. Review audit logs for suspicious queries involving HLL data types. Ensure that logging captures detailed error messages for forensic analysis.
What to do and how to stay safe: openGauss
- Verify your openGauss version against the affected list
- Restrict access to HLL functions for standard users
- Monitor for heap corruption indicators in system logs
- Wait for vendor confirmation before applying updates
Step-by-step guide: Emergency Patching: How to Fix Critical Flaws Without Breaking Production
General security guidance from the Packet Tribune newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which openGauss versions are affected by CVE-2026-111441?
Versions 2.1.0, 3.0.x, 3.1.x, 5.0.x, 5.1.0, 6.0.x, and 7.0.0-RC1 to RC3 are affected.
Is there a patch available for this vulnerability?
No fix has been confirmed yet for the affected versions.
What is the CVSS score for this issue?
The CVSS score is 8.1, rated as high severity.
