CVE-2026-111438 in openGauss-server
Summary
by MITRE • 10/19/2026
在 openGauss-server 的 src/common/backend/libpq/hba.cpp 中，复制连接认证存在访问控制绕过。hba_getauthmethod() 在处理 HADR/SW 复制发送方时，不要求 is_node_internal_connection()，直接调用 check_hba_replication()。check_hba_replication() 仅按 replication 标记做弱匹配，缺少普通 check_hba() 中的远程 trust 禁止等完整校验。因此，非内部网络的 HADR/SW 复制连接可绕过内部连接限制和完整 pg_hba 策略完成认证，进而通过复制协议读取备份与日志数据。
此问题随 HADR 复制发送方绕过内部连接校验进入代码，自 3.0.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。该问题已在 7.0.0-LTS版本修复，通过要求 HADR/SW 复制发送方必须经过 is_node_internal_connection 校验，使外部复制连接改走普通 check_hba() 并触发禁止远程 trust 策略。修复pr见https://gitcode.com/opengauss/openGauss-server/pull/9757。
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/19/2026
The vulnerability identified in openGauss-server involves a critical access control bypass within the Host-Based Authentication (HBA) mechanism, specifically affecting the handling of High Availability Disaster Recovery and Standby Writer replication connections. The flaw resides in the src/common/backend/libpq/hba.cpp file, where the hba_getauthmethod function fails to enforce internal network verification for HADR or SW replication senders. Instead of validating whether the connection originates from an authorized internal node via is_node_internal_connection(), the code directly invokes check_hba_replication(). This deviation from standard authentication protocols creates a significant security gap that allows unauthorized external entities to bypass intended access restrictions.
From a technical perspective, the core issue lies in the insufficient validation logic within check_hba_replication(). Unlike the standard check_hba() function which performs comprehensive checks including prohibitions on remote trust authentications for non-local connections, check_hba_replication() relies solely on weak matching based on the replication flag. This simplified approach ignores critical security policies designed to prevent unauthenticated or improperly authenticated access from external networks. Consequently, an attacker located outside the trusted internal network can establish a replication connection that is treated as legitimate by the database engine, effectively circumventing the rigorous checks applied to standard client connections.
The operational impact of this vulnerability is severe, as it enables potential data exfiltration and integrity compromise. By exploiting this bypass, an unauthorized actor can authenticate using methods such as trust or other weak authentication schemes that would normally be restricted for remote users. Once authenticated through this flawed replication path, the attacker gains access to sensitive database operations, including the ability to read backup files and transaction logs via the replication protocol. This exposure compromises the confidentiality of stored data and undermines the integrity of the database system by allowing unauthorized synchronization or manipulation of data streams that are typically protected from external view.
This security flaw has been present since version 3.0.0 when HADR replication sender logic was introduced without adequate internal connection verification. The vulnerability affects multiple major versions including 3.0.x, 3.1.x, 5.0.x, 5.1.0, and 6.0.x, as well as early release candidates of version 7.0 such as RC1 through RC3. The issue was formally addressed in the openGauss-server repository via pull request number 9757, which introduced a mandatory check for is_node_internal_connection() before processing replication authentication requests. This fix ensures that external replication connections are routed through the standard check_hba() function, thereby enforcing prohibitions on remote trust authentications and aligning replication security with general database access policies.
In terms of industry standards classification, this vulnerability corresponds to CWE-287 Improper Authentication, as it involves a failure in verifying user identity or system integrity before granting access privileges. Furthermore, the exploitation technique relates to ATT&CK T1078 Valid Accounts and potentially T1530 Data from Cloud Storage Object if backups are accessed via replication streams. The flaw represents a classic case of logic error where specific code paths for administrative functions like replication were not subjected to the same security rigor as general user connections, highlighting the importance of consistent authentication policy enforcement across all database interaction vectors.
To mitigate this risk in affected environments that have not yet applied the patch from version 7.0-LTS onwards, administrators should strictly limit network exposure of openGauss instances by configuring firewalls to allow replication traffic only from known internal IP addresses or subnets. Additionally, enforcing strong authentication methods such as scram-sha-256 and disabling trust-based authentication for all remote connections can reduce the attack surface even if this specific bypass is attempted. Regular auditing of pg_hba.conf configurations and monitoring for unusual replication connection attempts are recommended practices to detect potential exploitation activities in legacy versions prior to the official fix deployment.