CVE-2026-14178: openGauss Heap-Use-After-Free in to_timestamp NLS Parameter Handling

Technical summary

The vulnerability is a heap-use-after-free (CWE-416) in openGauss's timestamp conversion pipeline. The `to_timestamp_with_fmt_nls()` function stores the NLS format string (`nls_fmt_str`) into the session parser context (`u_sess->parser_cxt.nls_fmt_str`). During execution under seqscan+sort paths, this string is allocated in the SeqScan expression context. When SeqScan completes, the expression context is reset and the memory is freed. Subsequently, during result output, `timestamp_out()` calls `CheckNlsFormat()` which dereferences the freed `u_sess->parser_cxt.nls_fmt_str` pointer. This results in undefined behavior: in debug environments (ASan/Memcheck) the backend exits cleanly, but in production, the backend process may crash or exhibit memory corruption.

Business impact

The primary impact is availability degradation. An authenticated database user can repeatedly execute crafted `to_timestamp()` queries with NLS parameters to crash backend worker processes. Depending on the deployment's process pooling and restart mechanisms, this can result in periodic unavailability or performance degradation as the database restarts crashed processes. Since this requires SQL execution privileges, the risk is highest in shared database environments or scenarios where application code dynamically constructs queries. There is no data confidentiality or integrity impact.

Affected systems

The vulnerability affects openGauss-server versions 7.0.0-RC1 and 7.0.0-RC2. These are innovation/preview releases and do not receive traditional patch releases. The issue is resolved in openGauss-server-7.0.0-RC3 and all subsequent versions. Organizations running the named RC versions are at risk; those on stable release branches prior to 7.0.0 are unaffected (this is a regression in the 7.0.0 development cycle).

Exploitability

Exploitation requires valid database login credentials and SQL execution privileges. The attack is straightforward: a user simply executes a `to_timestamp()` call with an NLS parameter to trigger the crash. The CVSS vector reflects this: network accessible (AV:N) but requires authentication (PR:N is misleading in the score—the actual privilege requirement is implicit in database access control), high attack complexity due to memory layout dependencies (AC:H), no user interaction, and availability impact only. Reliable, repeatable exploitation is practical for any authenticated user, making this a denial-of-service vector in multi-tenant or untrusted user environments.

Remediation

Organizations must upgrade openGauss-server to version 7.0.0-RC3 or later. Because RC1 and RC2 are innovation versions without formal patch releases, upgrading to RC3 is the only supported remediation. Organizations should consult the openGauss release notes to confirm RC3 includes this fix and assess any behavioral or compatibility changes. If you are using an earlier stable release (pre-7.0.0), verify whether your version is affected by checking the vulnerability scope against your deployment.

Patch guidance

Upgrade openGauss-server to 7.0.0-RC3 or a subsequent version. Verify the patched version in the release notes at the openGauss GitHub repository or vendor site. RC releases should be evaluated in non-production environments first to assess compatibility with your application's timestamp handling, particularly any custom NLS locale configurations. Plan the upgrade during a maintenance window to minimize service disruption.

Detection guidance

Monitor application and database logs for repeated backend process exits or crashes, especially if they correlate with timestamp queries. Check error logs for segmentation faults or memory errors following `to_timestamp()` calls with NLS parameters. In development/testing environments, enable Address Sanitizer (ASan) or Valgrind to detect the memory access violation early. Audit SQL query logs for unusual `to_timestamp()` invocations with NLS parameters—legitimate queries of this type may be rare in many deployments. Network-based detection is not practical since the attack is internal SQL execution; rely on host-level process monitoring and log analysis.

Why prioritize this

Although the CVSS score is medium (5.9), this should be prioritized for rapid remediation in production environments because: (1) Exploitation requires only SQL access, which may be possessed by application service accounts or malicious insiders; (2) The impact is immediate and measurable (process crashes and service unavailability); (3) RC versions are typically short-lived, so even if you are running RC1/RC2 in production, an upgrade to RC3 is routine; (4) There are no known workarounds short of blocking users from executing `to_timestamp()` with NLS parameters, which is often impractical. Prioritize based on whether your deployment runs the affected versions and whether untrusted or malicious users have database access.

Risk score, explained

The CVSS 3.1 score of 5.9 (Medium) reflects a denial-of-service vulnerability with high attack complexity. The score is conservative due to the AC:H rating, which accounts for memory layout and timing variability in real-world environments; in practice, the attack may be highly reliable. The absence of confidentiality or integrity impact (C:N, I:N) limits the score despite the availability impact (A:H). The network accessibility (AV:N) is somewhat academic since the attacker still needs database credentials; this is implicit in the attack model but not explicitly penalized in the CVSS metric. Organizations should weight this as a material availability risk rather than be misled by the medium rating.

Frequently asked questions