在 openGauss-server 的 src/common/backend/libpq/hba.cpp 中，复制连接认证存在访问控制绕过。hbagetauthmethod() 在处理 HADR/SW 复制发送方时，不要求 isnodeinternalconnection()，直接调用 checkhbareplication()。checkhbareplication() 仅按 replication 标记做弱匹配，缺少普通 checkhba() 中的远程 trust 禁止等完整校验。因此，非内部网络的 HADR/SW 复制连接可绕过内部连接限制和完整 pghba 策略完成认证，进而通过复制协议读取备份与日志数据。

此问题随 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 复制发送方必须经过 isnodeinternalconnection 校验，使外部复制连接改走普通 checkhba() 并触发禁止远程 trust 策略。修复pr见https://gitcode.com/opengauss/openGauss-server/pull/9757。

在 openGauss-server的 src/common/backend/utils/adt/genfile.cpp 模块中，内置函数 pgreadbinaryfileblocks() 存在权限校验逻辑缺陷。该函数在入口处仅校验了起始块号（startBlockNum）和块数量（blockCount）的范围，随后直接调用底层文件读取例程 ReadBinaryFileBlocksFirstCall()。该底层例程仅执行了路径规范化检查以及针对 .. 路径遍历和数据目录边界的基本检查，缺失了对调用者数据库权限（如 SELECT 权限）的校验。此外，辅助函数 isrowdatafile() 也仅用于识别文件形态，未包含权限检查。因此，任何拥有普通数据库连接权限的用户，只要能够通过 pgrelationfilepath() 等函数获取到目标表的底层关系文件路径（例如压缩数据的 compress 文件路径），即可无需具备该表的 SELECT 权限，直接读取表数据的二进制块。 此漏洞影响此前3.0.0到6.0.0间的所有版本及补丁版，并在7.0.0-LTS版本修复。修复patch详见：https://gitcode.com/opengauss/openGauss-server/pull/9374。

在 openGauss-connector-jdbc 的 pgjdbc/src/main/java/org/postgresql/log/LogFactory.java 中，LogFactory 根据 JDBC 连接参数中的 logger 类名调用 Class.forName 加载类后，直接反射调用以 String 为参数的构造函数，再转换为 Log。缺少 asSubclass(Log.class) 校验，非 Log 实现类也会在类型检查前被实例化。因此，当攻击者可控制 JDBC URL 或连接属性中的 logger 类名，且客户端 classpath 中存在可被加载的类时，可能在客户端触发非预期的类加载与构造副作用。

此漏洞自 JDBC 1.1.0引入，影响 1.1.0 及之后的 2.x、3.x、5.x、6.x 各版本及补丁（含 6.0.0 分支最新 6.0.6），以及 7.0.0-RC1、7.0.0-RC2、7.0.0-RC3，并在 7.0.0-LTS 版本修复。修复在 Class.forName 之后先执行 asSubclass(Log.class)，仅允许 Log 子类进入构造。修复pr见https://gitcode.com/opengauss/openGauss-connector-jdbc/pull/423。

在 openGauss-server 的 src/gausskernel/cbb/utils/hll/hll.cpp 中，内置函数 HllObjectUnpack() 存在长度校验缺陷。该函数从用户提供的 packed HLL 解析 lenUsed 与 lenTotal 后，仅检查输入长度足以覆盖 HLLHEADSIZE + lenUsed，随后按 lenTotal 分配缓冲区、按 lenUsed 调用 memcpys() 拷贝输入，既未校验 lenTotal >= lenUsed，也将 memcpys() 目标大小写成 lenUsed 而非实际分配的 lenTotal，导致安全拷贝无法拦截越界写。hllin()、hllprint()、hllcardinality() 等 SQL 入口会走同一解包路径。因此，普通数据库连接用户只需构造 lenTotal 小于 lenUsed 的畸形 packed HLL（例如经 ::hll 进入 hllin()），即可触发服务端堆越界写，存在内存破坏风险。此问题随 packed HLL 解包函数 HllObjectUnpack() 进入代码，v2.1.0 起即存在。受影响版本包括 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。该问题已在 7.0.0-LTS 版本修复，通过在 HllObjectUnpack() 中补齐 lenUsed <= lenTotal 校验，并将 memcpys() 的目标大小改为实际分配的 lenTotal。修复 PR 见 https://gitcode.com/opengauss/openGauss-server/pull/9380 。

openGauss 在处理带 NLS 参数的 totimestamp 调用时，totimestampwithfmtnls() 会将 nlsfmtstr 保存到 usess->parsercxt.nlsfmtstr。在 seqscan + sort 执行路径下，该字符串原本被分配在 SeqScan 的表达式上下文中；当 SeqScan 完成后，该内存上下文会被 reset，但后续结果输出阶段 timestampout() 仍会通过 CheckNlsFormat() 访问 usess->parsercxt.nlsfmtstr，导致访问已释放内存。攻击者在具备数据库 SQL 执行权限的情况下，可构造特定 totimestamp(..., ..., nlsparam) 查询触发 heap-use-after-free。在 ASan/Memcheck 环境下表现为数据库服务退出；在实际运行环境中可能造成后端进程异常退出，影响数据库服务可用性，形成拒绝服务风险。该问题在openGauss-server-7.0.0-RC1版本和openGauss-server-7.0.0-RC2版本存在，目前已在openGauss-server-7.0.0-RC3版本修复。由于 openGauss-server-7.0.0-RC1版本和openGauss-server-7.0.0-RC2均为创新版本，不会发布针对性补丁包，涉及版本升级至 openGauss-server-7.0.0-RC3或更新版本即可。