📊 HiddenMerit Morning Post · Issue 66

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

01｜Azure Cosmos DB Exposes Cross‑Tenant Access Vulnerability: Wiz Finds “Master Key” Can Access Any Customer Database

On July 31, cloud security company Wiz disclosed a critical vulnerability chain in Microsoft Azure Cosmos DB, codenamed CosmosEscape, which could potentially allow attackers to access customer databases across tenants, including private and network‑isolated database instances. Microsoft stated that the vulnerability has been fully fixed, with no evidence of exploitation, and that no customer action is required.

Technical Details: Wiz researchers found that attackers could exploit this vulnerability to access nearly any Microsoft customer’s Cosmos DB account, including Microsoft’s own Cosmos databases used for services such as Entra ID and Teams. The vulnerability is essentially a “master key” in the Azure Cosmos DB control plane, enabling retrieval of access keys across customers and tenants, achieving full read/write access. Researchers also demonstrated how to query Cosmos DB’s internal account catalog to enumerate databases and precisely locate target organisations by tenant or subscription ID.

Security Impact: Security experts noted that cross‑tenant vulnerabilities in shared cloud platforms are particularly severe because they undermine the core promise of cloud infrastructure – that customers on the same platform are isolated from each other. The affected scope covers thousands of Microsoft customers and the data behind their applications, chatbots, and AI capabilities. When a single vulnerability can touch everyone’s data, the damage radius is the entire platform.

DBA Perspective: CosmosEscape is an important wake‑up call for cloud database security. The vulnerability resides in the cloud platform control plane, not in user configurations – meaning even if DBAs have implemented comprehensive permission management and encryption at the application layer, they cannot defend against cross‑tenant risks at the infrastructure layer. A security expert cited in SecurityBrief commented: “Cloud‑side vulnerabilities are often not assigned CVEs and are quietly fixed, meaning customers often cannot determine whether they were ever exposed. It’s not a security strategy to assume the next one will also be found before being exploited.” DBAs using Azure Cosmos DB should review access logs and treat this event as a trigger for a “zero‑trust” architecture – private endpoints, least‑privilege access controls, and application‑layer encryption should become standard configuration.

02｜Oracle July CPU Sets Record: 1,449 Patches Fix 1,235 CVEs, AI‑Driven Internal Vulnerability Discovery Surges 10x

On July 21, Oracle released its July 2026 Critical Patch Update (CPU), containing 1,449 security patches fixing 1,235 independent CVEs – the largest single patch release in Oracle’s history. 261 patches were rated Critical, with high‑severity patches accounting for 52.7%. Among the 32 affected product families, Oracle E‑Business Suite topped the list with 410 patches (45 remotely exploitable without authentication), followed by Oracle Fusion Middleware with 355 patches (219 remotely exploitable).

AI‑Driven Vulnerability Discovery: The root cause of the CPU’s record size is AI‑assisted vulnerability discovery. UpGuard analysis shows that 77% of the CVEs in this CPU are Oracle‑owned vulnerabilities (1,110), compared to a historical quarterly average of only 102 Oracle‑owned CVEs. The number of Oracle‑owned CVEs jumped 10.9 times from the steady‑state level of 2021‑2025, and this jump was sudden rather than gradual – the January and April 2026 CPUs were still at normal levels (68 and 109 Oracle CVEs). Oracle has explicitly stated that its security engineering has introduced cutting‑edge AI models from Anthropic and OpenAI. External researchers only received credit for 54 CVEs this quarter, within the historical normal range – the vast majority were discovered internally with AI assistance. The median CVE was reserved only 13 days before patch release, and 75.6% of CVEs were fixed within 30 days of public disclosure.

DBA Perspective: This record‑breaking CPU sends two clear signals: first, AI‑driven vulnerability discovery is causing Oracle‑owned CVE counts to surge by an order of magnitude, and DBAs must shift from a “quarterly patch” cadence to a “monthly security baseline” response mode (Oracle launched its monthly CSPU mechanism in May 2026); second, Oracle E‑Business Suite and Fusion Middleware are the hardest hit areas – enterprises using both products face doubled patch urgency. Although the core Oracle Database has only 15 patches (6 remotely exploitable without authentication), as a core system, DBAs should set patch priority to P0. A security expert cited in ADTmag commented: “Oracle’s response cadence means customers running self‑managed deployments should actively plan monthly CSPU windows in addition to the quarterly CPUs.”

03｜LoongArch Officially Enters PostgreSQL Official Repository: Becomes PGDG’s Fourth CPU Architecture

In July, the PostgreSQL Global Development Group (PGDG) APT repository maintainer announced that LoongArch (loong64) has officially entered the PostgreSQL official repository. LoongArch thus becomes the fourth CPU architecture officially supported by the PGDG APT repository, joining AMD64, ARM64, and PPC64EL – completing a milestone breakthrough from “0 to 1” for an independent instruction set architecture entering the international top‑tier open‑source database ecosystem.

Technical Details: The LoongArch build host uses the Loongson 3B6000 processor, with the software package bootstrap build completed in early July. The LoongArch PostgreSQL packages are included in the same package system as other mainstream architectures – sharing the same repository, package names, signing mechanisms, and update cadence, with the official repository’s trust endorsement. Users installing Debian‑based Loongson devices can configure the PGDG APT source to obtain, deploy, and use officially signed PostgreSQL packages and extension ecosystem (including PostGIS, TimescaleDB, pgvector, etc.).

DBA Perspective: LoongArch entering the PostgreSQL official repository is a key step for domestic chip ecosystems into the global open‑source mainstream. Previously, deploying PostgreSQL on LoongArch required manual source compilation or reliance on third‑party ports, with lagging updates and complex operations. Now, DBAs can directly obtain PostgreSQL versions and extensions synchronised with x86/ARM architectures on Loongson devices via the official APT source. PostgreSQL has topped the Stack Overflow usage survey for three consecutive years, and its robust plugin ecosystem (pgvector for vector databases, TimescaleDB for time‑series databases, etc.) is a critical data foundation for the AI era. Loongson users can now natively enjoy this ecosystem dividend.

04｜CETC Kingware: KingbaseES V9 Core Engine Fully Self‑Developed, “Core Code” Sovereignty Enters Deep Water

With the official release of the domestic database list, CETC Kingware published a technical article articulating its “autonomous control” technology roadmap. The core judgment: The new benchmark of autonomous control is defined by the degree of self‑development of the core engine, not by the length of the compatibility list.

Technology Self‑Development: KingbaseES V9’s core engine adheres to a fully self‑developed path. The core source code has been certified by authoritative institutions as independently developed, with no open‑source code found – ensuring the autonomy and security of the technology path. Kingware has achieved full‑chain independent design from storage management and concurrency control to query optimisation, fundamentally avoiding open‑source licensing risks. The system configuration follows standard system configuration specifications, ensuring absolute control of underlying instructions.

Full‑Stack Ecosystem: Kingware has completed extensive mutual certification with mainstream domestic chips, operating systems, and middleware, building a compatibility ecosystem of over 11,000 products. In the financial sector, Kingware has been successfully deployed in the core transaction systems of multiple large financial institutions, supporting real‑time processing of massive transaction data.

DBA Perspective: Domestic database competition is moving from “compatibility benchmarking” into the “core engine self‑development” deep water. KingbaseES V9’s full self‑development means that when DBAs are evaluating Xinchuang projects in heavily regulated industries such as finance and government, they can include “core code autonomy rate” as a key dimension in selection assessments. Kingware’s cumulative installations exceeding 1 million sets and large‑scale validation across six industries – government, telecommunications, energy, transportation, healthcare, and manufacturing – provide a reference benchmark for DBAs in cross‑industry Xinchuang projects.

05｜Postgres Pro Enterprise Manager 2.8 Released: BiHA Quorum Synchronous Replication and AQO Adaptive Query Optimisation

On July 30, Postgres Professional released Postgres Pro Enterprise Manager 2.8 (PPEM 2.8), a unified management and monitoring platform for Postgres Pro Enterprise clusters, adding several enterprise‑grade operational capabilities.

Key New Features:

BiHA Quorum Synchronous Replication: Graphic interface configuration of quorum synchronous replication, allowing a balance between transaction processing speed and data protection, simplifying high‑availability infrastructure construction without manual tuning.
Centralised Configuration Management: Administrators can view and modify cluster and single‑node parameters via the web interface, supporting different configurations for different servers in a single operation.
Adaptive Query Optimisation (AQO): Added AQO support, automatically correcting query execution plans based on historical execution statistics, improving performance on high‑load systems.
Metrics and Log Management: Added management of metrics and log collection parameters for pgpro‑otel‑collector.

[quads id="805"]
User Session Management: Added user profile and active session management functionality.
DBA Perspective: PPEM 2.8’s quorum synchronous replication configuration graphical interface simplifies the tuning of complex distributed consistency, lowering the barrier to building financial‑grade high‑availability PostgreSQL clusters. AQO adaptive query optimisation is an important tool in the PostgreSQL ecosystem for addressing “execution plan drift” – in high‑concurrency mixed‑load scenarios, execution plans can degrade as data distribution changes. AQO automatically corrects plans based on historical execution statistics, meaning DBAs can expect a reduction in “firefighting” frequency. DBAs using Postgres Pro Enterprise should evaluate AQO’s real‑world effectiveness in mixed‑load scenarios.

📚 SQL Little Knowledge Point

This Issue’s Knowledge Point: What is a “Control Plane” Vulnerability?

The core of the CosmosEscape vulnerability is a permissions boundary failure in the control plane. Understanding the control plane is key to understanding cloud database security architecture.

Data Plane vs. Control Plane:

Dimension	Data Plane	Control Plane
Function	Stores and processes user data	Manages infrastructure (create/delete/configure DB instances)
Accessor	Application users	Cloud administrators, automation scripts
Permission Scope	Specific database/table	Entire cloud account, cross‑tenant
Security Focus	SQL injection, data encryption, access control	Authentication, permission models, internal boundaries

Why Control Plane Vulnerabilities Are More Dangerous: Data plane vulnerabilities typically affect only a single tenant’s data, while control plane vulnerabilities may allow attackers to access any customer’s data across tenants. A security expert cited in SecurityBrief commented: “When a single vulnerability can touch everyone’s data, the damage radius is the entire platform. That’s why this is news, not a footnote.”

CosmosEscape’s Implications: Control plane vulnerabilities represent a “systemic risk” for cloud databases – they are not within the DBA’s conventional security control scope (such as SQL injection defence or access control lists), but are flaws in the cloud platform’s internal architecture. For DBAs, this means that even if the application layer has implemented all the correct security configurations, it cannot completely eliminate architectural risks from the cloud platform itself. The best defence is a “zero‑trust” architecture – private endpoints, application‑layer encryption, and least‑privilege access controls, rather than relying entirely on the cloud platform’s perimeter defences.

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