Segment 1: HiddenMerit Morning Post · Issue 111

Focus on Database Frontiers, Practical Insights for DBAs September 23, 2026 ｜ 5 Selected Global Breaking News

01｜pg_partman Exposes Another High‑Risk SQL Injection Vulnerability (CVE-2026-61817): Low‑Privilege Users Can Plant Persistent Backdoors

The PostgreSQL partition management extension pg_partman has been found to have a serious SQL injection vulnerability (CVE-2026-61817), affecting versions before 5.5.0. This is the second high‑risk vulnerability disclosed in pg_partman recently.

Vulnerability Details: Functions including run_maintenance(), show_partitions(), show_partition_info(), undo_partition(), and partition_data_time() interpolate the writable part_config.time_dncoder text value directly into dynamic SQL without identifier quoting. A role with partman_user privileges can store malicious SQL instead of a legitimate decoder function name. When subsequent maintenance operations (including the pg_partman_bgw background worker) are triggered, the malicious SQL executes with the privileges of the default PostgreSQL superuser background worker role.

Attack Consequences: Successful exploitation can lead to full database compromise and potentially execute operating system commands as the PostgreSQL service account. The persisted malicious configuration row can continuously restore escalated access in subsequent maintenance cycles, forming a reliable backdoor. The vulnerability has been fixed in version 5.5.0.

DBA Perspective: This is the second high‑risk vulnerability disclosed in pg_partman within a week (the previous being CVE-2026-61821, CVSS 8.5). Both vulnerabilities share the same pattern — the background worker executes operations with superuser privileges, bypassing the caller’s permission boundaries. DBAs are advised to upgrade to 5.5.0 immediately and audit the time_dncoder field in the part_config table for anomalous entries.

02｜Oracle September CSPU Large‑Scale Leak: 247 Exploitable Without Authentication, Access Manager/WebLogic Multiple Products at CVSS 10.0

On September 15, Oracle released its September 2026 Critical Security Patch Update (CSPU), fixing 673 security patches covering 672 independent CVEs, with 246 vulnerabilities remotely exploitable without authentication, 104 CVEs rated 9.0 or above, and a maximum CVSS score of 10.0.

CVSS 10.0 Vulnerabilities Concentrated:

Oracle Access Manager (Authentication Engine): Unauthenticated attackers can fully compromise via HTTP. This component is often deployed at the front end of web applications, with high internet exposure risk.
Oracle WebLogic Server (Web Container): Core HTTP request processing component; unauthenticated remote attacks can fully compromise.
Oracle Platform Security for Java (Centralised Thirdparty Jars): Unauthenticated HTTP attackers can fully compromise.
Oracle Forms (Forms Services/C/S/Charmode): All three modes have unauthenticated remote vulnerabilities.

Database‑Related: Oracle Database Server RDBMS component has multiple low‑privilege escalation vulnerabilities, including CVE-2026-83271 (CVSS 8.8, DBMS_REDEFINITION privilege can fully compromise RDBMS), CVE-2026-83348 (Create DB Link privilege), and CVE-2026-83160 (Create Table privilege). These privileges are routinely granted in database development, meaning ordinary application accounts could become attack springboards.

DBA Perspective: The CVSS 10.0 vulnerabilities in this CSPU are concentrated in middleware products (Access Manager, WebLogic, Forms), which are often the “front door” to databases. Once middleware is compromised, attackers can penetrate directly to the backend database. DBAs are advised to work with middleware teams to immediately assess affected versions and prioritise patching internet‑exposed middleware instances. On the database side, review all accounts with DBMS_REDEFINITION, Create DB Link, and Create Table privileges to confirm they are configured according to the principle of least privilege.

📌 HiddenMerit In‑Depth Preview: Today’s in‑depth article – “pg_partman Serial Vulnerabilities Deep Dive: When PostgreSQL Extensions’ ‘Background Processes’ Become Superuser Backdoors” – will explore the technical essence of both pg_partman vulnerabilities and emergency response for DBAs.

03｜Dameng Investor Exchange Meeting: AI Capabilities Not Charged Separately, All‑in‑One Positioned as “Second Growth Curve”

On September 17, Dameng held an investor exchange meeting in Wuhan. Chairman Feng Yucai led the management team in discussions with institutional investors on AI layout, database all‑in‑one business, and other hot topics.

Dual AI Tracks: The company is advancing both “AI for DB” (intelligent operations, SQL optimisation, automatic index recommendations, fault self‑healing) and “DB for AI” (native vector retrieval, multi‑modal data processing). Dameng clarified: AI capabilities are currently not charged as a standalone module, but integrated into the overall product capability.

All‑in‑One Strategy: Dameng attaches great importance to its database all‑in‑one business, having incorporated it into its core strategic layout and explicitly positioning it as a “second growth curve.” H1 all‑in‑one revenue was RMB 27.12 million, up 519% year‑on‑year.

DBA Perspective: Dameng’s strategy of “not charging separately for AI capabilities” essentially treats AI as the product’s “comprehensive competitiveness” rather than a “profit centre.” For DBAs, this means that when choosing Dameng products, AI capabilities are “standard” rather than “optional.” The all‑in‑one positioning as a second growth curve also confirms the trend of domestic databases moving from “software replacement” to “hardware‑software synergy.”

04｜New Batch of National Security Assessment Results Released: Three Centralised Databases Receive Grade I Certification, “Pass to Production Databases” Officially Issued

Recently, the China Information Security Evaluation Center released the “Security and Reliability Assessment Results Announcement (2026 No. 3).” Three products each achieved Grade I security and reliability certification: Hangzhou Yijing Shutong Xihe General Database System V1.0, Huawei Cloud NetrixDB V3.0, and Tencent Cloud TDSQL Centralised Relational Database Management System V10.3.

Industry Signal: This is the first time the national assessment has issued a “pass to production databases” in the centralised database category. The lifeblood of government and enterprise core systems — ledgers, customer data, transactions, government archives — all resides in centralised databases; if the database collapses, business goes to zero. Passing this assessment means domestic centralised databases have moved from the early stage of “usable as a fallback” into the main ranks of the candidate pool for government and enterprise core systems.

DBA Perspective: The old script of “foreign databases = stable, domestic = risky” is turning the page. For DBAs, this means the selection logic for domestic databases is shifting from “can it replace” to “how do we manage it well after replacement.” The urgency for frontline DBAs is no longer “should I learn domestic databases,” but “how do I rebuild the operational systems accumulated during the Oracle era on domestic databases.”

05｜YashanDB Shared Cluster Achieves <10 Second Automatic Recovery, Supporting Core System of a Bank in Kazakhstan

Science and Technology Daily reported that the YashanDB database system, independently developed by the Shenzhen Institute of Computing Sciences, has achieved a key breakthrough in shared cluster technology. After a fault was triggered, the data flow did not interrupt, and the fault recovery time curve rebounded sharply within less than 10 seconds, running smoothly — a key milestone for YashanDB in crossing the “financial‑grade high availability” threshold.

Technical Path: The team redesigned from the lowest‑level storage engine and transaction model, achieving full‑stack technical autonomy from cache coherency and global transaction management to cluster governance. Based on the original theory of “adaptive asynchronous parallelism,” the database cluster performance grows almost proportionally with the number of hardware nodes.

Deployment Progress: YashanDB has been applied in projects at the Digital Currency Research Institute of the People’s Bank of China, Liaoning Rural Commercial Bank, and Founder Securities, and has successfully gone live on the core system of Kazakhstan’s second‑largest commercial bank, moving from domestic core scenarios to international financial‑grade applications.

DBA Perspective: YashanDB’s measured data of “<10 second automatic recovery" provides a quantitative reference for domestic databases in financial‑grade high availability scenarios. The deployment at a Kazakh bank's core system also validates the applicability of domestic databases in overseas financial scenarios. For DBAs, this means the evaluation dimensions for domestic database selection are expanding from "feature benchmarking" to "international delivery capability."

[quads id="805"]

💡 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is the “Background Worker” Risk in PostgreSQL Extensions?

Both pg_partman vulnerabilities (CVE-2026-61821 and CVE-2026-61817) point to the same architectural risk: background workers execute operations with superuser privileges.

Component	Role	Default Privileges
Caller	`partman_user`	Low privileges
Background Process	`pg_partman_bgw.role`	PostgreSQL Superuser

Risk Logic:

A low‑privilege user triggers a background task.
The background process executes the operation with preset superuser privileges.
The caller’s permission boundaries are completely bypassed.

What Makes CVE-2026-61817 Unique: The malicious SQL is persistently stored in part_config.time_dncoder rather than executed immediately. When subsequent maintenance operations are triggered (including the automatic pg_partman_bgw), the malicious SQL executes with superuser privileges and can continuously restore escalated access in subsequent cycles, forming a reliable backdoor.

Implications for DBAs: Any component that executes operations with “higher privileges” (background processes, schedulers, agents, MCP Servers) requires independent privilege auditing. You cannot assume “the operation is safe” simply because “the caller has low privileges.” It is recommended to review the pg_partman_bgw.role configuration and assess whether it can be downgraded to a dedicated role with only the necessary DDL privileges.

HiddenMerit Team Production Slogan: 绩优隐于内，金石启新程 | Hidden deep. Merit bold. Forge ahead.

Segment 2: HiddenMerit In‑Depth · Issue 24

Focus on Database Frontiers, In‑Depth Analysis September 23, 2026 ｜ 1 In‑Depth Feature Article

pg_partman Serial Vulnerabilities Deep Dive: When PostgreSQL Extensions’ “Background Processes” Become Superuser Backdoors

1. Two High‑Risk Vulnerabilities in One Week

The PostgreSQL ecosystem had just experienced the impact of PostGREShell (CVE-2026-6471) when the pg_partman extension disclosed two high‑risk vulnerabilities in succession.

The First: CVE-2026-61821 (CVSS 8.5) — drop_partition_id() and drop_partition_time() use part_config.retention_schema as the target for ALTER TABLE SET SCHEMA. A low‑privilege user can specify a schema for which they lack CREATE privileges, and the background worker executes the move with superuser privileges, bypassing authorization checks.

The Second: CVE-2026-61817 — functions such as run_maintenance() and show_partitions() interpolate part_config.time_dncoder directly into dynamic SQL. An attacker can store malicious SQL instead of a legitimate function name, which executes with superuser privileges when background maintenance is triggered.

The two vulnerabilities have different attack paths, but the core problem is identical: the system makes overly optimistic security assumptions about “low‑privilege accounts,” and the background process’s superuser privileges become an “amplifier” for attackers.

2. The Technical Essence of the Second Vulnerability: A Persistent Backdoor

What makes CVE-2026-61817 more dangerous than CVE-2026-61821 is that the malicious payload is persistent.

Attack Chain:

Implantation: An attacker with partman_user privileges stores malicious SQL (instead of a legitimate decoder function name) in the part_config.time_dncoder field.
Dormancy: The malicious SQL is persistently stored in the database and does not execute immediately — this allows it to bypass many “real‑time detection” mechanisms.
Trigger: When subsequent maintenance operations (including automatic maintenance by the pg_partman_bgw background worker) use that configuration value, the malicious SQL is concatenated into dynamic SQL and executed.
Privilege Escalation: The background worker executes with the identity of pg_partman_bgw.role — which defaults to a PostgreSQL superuser.
Persistence: The malicious configuration row continuously restores escalated access in subsequent maintenance cycles, forming a reliable backdoor.

Comparison with PostGREShell:

Dimension	PostGREShell (CVE-2026-6471)	pg_partman (CVE-2026-61817)
Attack Entry	`REPLICATION` account	`partman_user` account
Exploitation Method	Logical replication plugin path loads malicious code	`time_dncoder` field stores malicious SQL
Persistence Mechanism	Requires re‑triggering replication	Configuration row persisted, auto‑restored
Execution Privileges	Database process privileges	Superuser background worker role

3. Why Is “Background Process Superuser” a Dangerous Pattern?

pg_partman’s design is not unique. Many database automation tools adopt a similar pattern: background processes run with high privileges, executing operations on behalf of low‑privilege users.

Traditional Privilege Model: User A executes an operation → the system checks whether A has privileges → execute if yes, reject if no.

pg_partman’s Model: User A triggers the background process → the background process executes the operation with superuser privileges → the system does not check A’s privileges.

This means: any user who can trigger the background process gains superuser execution capability — even if they themselves have only low privileges.

More dangerously: when the malicious payload is persistently stored, the attacker doesn’t need to maintain continuous access. One implantation, long‑term effectiveness. Every trigger of a background maintenance cycle is an “automatic renewal” of the attacker’s escalated access.

4. Emergency Action Checklist for DBAs

Priority 1: Upgrade pg_partman Immediately upgrade to 5.5.0 or higher.

Priority 2: Audit the part_config Configuration Table Check the time_dncoder field for anomalous entries:

SELECT set_name, time_dncoder 
FROM partman.part_config 
WHERE time_dncoder IS NOT NULL 
  AND time_dncoder !~ '^[a-z_][a-z0-9_]*$';

Normal values should be legitimate decoder function names (such as partman.decode_partition_time). Any entry containing SQL keywords or anomalous characters should be treated as suspicious.

Priority 3: Review Background Process Privilege Configuration

SHOW pg_partman_bgw.role;

If this role is a superuser (the default), assess whether it can be downgraded to a dedicated role with only the necessary DDL privileges.

Priority 4: Review partman_user Privilege Scope Identify which accounts have partman_user privileges and assess whether all of them need this privilege.

5. The Bigger Picture: “Privilege Model Fragmentation” in the PostgreSQL Extension Ecosystem

The consecutive emergence of pg_partman’s two vulnerabilities and the PostGREShell vulnerability points to a structural challenge in the PostgreSQL ecosystem: the lack of a unified standard for extension privilege models.

The PostgreSQL kernel has a mature privilege management system (roles, privileges, RLS, column‑level privileges), but extensions can freely define their own privilege models. pg_partman defined partman_user and pg_partman_bgw.role, but did not mandate that “background process privileges should inherit the caller’s privileges” or that “background processes should not use superuser.”

Implications for DBAs:

Every PostgreSQL extension requires independent security assessment — you cannot assume that “the PostgreSQL kernel is secure” equals “the entire database is secure.”
Audit all automation components running with “high privileges” (background processes, schedulers, agents, MCP Servers).
Minimise automation component privileges — not “give it superuser and be done,” but “give it exactly the privileges it needs.”

As PostgreSQL grows from a “database kernel” into a “database platform,” security governance of the extension ecosystem is becoming a new required course for DBAs.