HiddenMerit Daily · Issue 32

# 📊 HiddenMerit Daily · Issue 32

> Focus on Database Frontiers, Practical Insights for DBAs

> May 28, 2026 ｜ 5 Selected Global Breaking News

## 01｜DBA’s True Voice: “What We Fear in Core System Migration Isn’t the Technology – It’s the Collapse of Trust”

Recently, CETC Kingware published a real‑life sharing article from a frontline DBA titled “Core System Database Migration: We Were Afraid of Business Interruption.” Using the migration of a fund TA system as the backdrop, the article details the complete process of migrating an Oracle RAC cluster (60TB+ data, tens of millions of users) to KingbaseES V9, expressing the common feelings of countless DBAs in the finance, telecom, and energy industries.

The article reveals that although KingbaseES V9 withstood extreme stress tests of 20,000+ TPS, in the late hours before the production environment switchover, “staring at the migration tool, silently reciting those complex stored procedure conversion rules” – DBAs fear not the technical difficulties themselves, but the chain reaction of “what if response time slows by 10 milliseconds” on business, the settlement and clearing risk of “what if batch processing takes 5 hours instead of 3,” and the “irreparable collapse of trust after a business outage.”

In 2026, the penetration of domestic databases in key industries such as finance, energy, and telecommunications continues to rise, but the demands for stability from core workloads like transactions, billing, and settlement far exceed those of peripheral systems. The article notes that insufficient ISV adaptation depth and weak cross‑industry experience accumulation mean that “every switchover feels like reinventing the wheel.” However, through read‑write separation cluster architecture, refined architecture design, and the methodology support of Kingware’s “Core System Database Application Innovation Pilot Program,” the migration of domestic databases in core systems has moved from “unthinkable” to “practicable.”

- DBA Perspective: This article is a rare “frontline battle report” in the process of domestic database Xinchuang replacement. The migration of an Oracle RAC cluster with 60TB+ data and tens of millions of users is a typical scenario for the domestic replacement of financial core systems. When reading it, DBAs should pay special attention to the author’s candid record of “risk psychology” – this “fear” is actually a reverence for the production environment and a mark of professional DBA quality. For DBAs planning similar projects, the article provides highly practical reference points: from stress test data (20,000+ TPS) to stored procedure conversion details in the migration toolchain, to the “small steps, fast iteration” implementation strategy – all are reusable real‑world experiences.

- CTO Perspective: The value of this article is that it breaks through the “last mile of trust” in domestic database replacement. When stress test data meets the mark but the team is “afraid to press the confirm button,” it means that technology decision‑makers need to establish not just a performance baseline, but also a “psychological safety baseline.” Kingware’s “Pilot Program,” through methodology accumulation and benchmark case accumulation, is helping core industries build this confidence. CTOs should pay attention to such industry methodology outputs and use them as a reference framework for team capability building.

- Investor Perspective: The psychological barrier of frontline DBAs “afraid to press the confirm button” is precisely the commercial gap that domestic database vendors must cross – and it is also a moat. Whoever first accumulates enough “zero‑incident” migration cases in key industries such as finance, energy, and telecommunications will gain higher order premiums in this deep‑water Xinchuang replacement. Kingware’s “Pilot Program” methodology沉淀 is an important symbol of its transformation from a “product supplier” to an “industry solution service provider.”

Source: CETC Kingware Tech Blog

## 02｜Kingware Discloses “Organ Transplant” Practice for MySQL to Domestic Database Migration: Heterogeneous Coexistence Will Be the Future Norm

On May 27, CETC Kingware published a technical article titled “Database Architect: The ‘Organ Transplant’ Practice of MySQL to Domestic Database Migration in 2026.” The article points out that in 2026, as core business systems undergo a comprehensive transformation from monolithic architecture to microservices, MySQL migration will no longer be a one‑time “cutover operation,” but a three‑year “organ transplant” .

Core points of the article:

Trend Judgment: Over the next three years, the core logic of database migration will shift from “whether it can be migrated” to “how to migrate while running without performance loss.” According to Gartner analysis, hybrid database architecture will become mainstream in 2026, with enterprises maintaining a “dual‑track” operation model where MySQL and domestic databases coexist for the long term. Migration tools must have both “heterogeneous real‑time synchronisation” and “semantic automatic conversion” capabilities.

Scenario Design: A typical scenario is the smooth evolution of a core database during an e‑commerce promotion – business traffic does not decrease but may even surge. The migration tool needs to achieve millisecond‑level response for “read‑write separation” and “automatic failover,” ensuring transactional atomicity between heterogeneous databases. KingbaseES V9 achieves transparent mapping with source MySQL through its distributed transaction engine, allowing traffic to be gradually switched without modifying application code.

Solution Path: A three‑step evolutionary architecture – assessment → dual‑track → integration. Step one: full assessment and risk modelling. Step two: dual‑track parallel operation and grey‑scale validation (gradually switching 5% write traffic). Step three: architecture integration and autonomous control.

- DBA Perspective: The “organ transplant” metaphor is extremely apt. The risk level and complexity of database migration in financial core systems are fully comparable to a human organ transplant – the “rejection reaction” (differences in SQL dialects, transaction isolation levels, data type mappings) is the greatest technical risk. The article specifically notes that in a dual‑active deployment at a major financial customer, differences in heterogeneous transaction isolation levels between MySQL and the domestic database led to a 300% increase in data consistency check time under high concurrency. When doing migration assessments, DBAs must include such “hidden rejection” in their risk list and focus on testing transaction boundary behaviour under high concurrency during the grey‑scale validation phase.

- CTO Perspective: The article’s “dual‑track” architecture judgment – that enterprises will maintain heterogeneous database coexistence for the long term – is very important. This means that technology decision‑makers should not pursue a “one‑step” comprehensive replacement, but should design a “heterogeneous coexistence” architecture that allows core business to migrate gradually and smoothly. KingbaseES V9’s transparent mapping with source MySQL through its distributed transaction engine provides technical feasibility for such long‑term dual‑track operation.

- Investor Perspective: The “three‑year organ transplant” reveals the true cycle of Xinchuang replacement – this is not a short‑term “switch flipping” event, but a systematic project requiring 3‑5 years of continuous investment. For domestic database vendors, this means: customer stickiness is extremely high, replacement costs are enormous, and once a vendor enters the core system migration process, it is very difficult to be replaced. Vendors with complete migration toolchains and heterogeneous synchronisation capabilities will continue to receive service revenue throughout this long process.

## 03｜Ransomnews Releases 5‑Year Ransomware Economy Report: Exposure = Compromise, China Ranks First in Marked Databases

On May 26, the Ransomnews research team released a five‑year (May 2021 – May 13, 2026) ransomware economy research report. The study covered 65,907 database systems exposed to the public internet, of which 30,515 databases (46.3%) had already been implanted with ransomware or wipe notices at the time of discovery.

The most striking finding of the study is that MongoDB and MySQL exposure equals immediate compromise: of the 3,532 exposed MongoDB instances found, 3,525 carried ransomware marks; for MySQL, 2,930 out of 2,930 exposed instances carried ransomware marks – a near‑100% compromise rate. Elasticsearch and Kibana had compromise rates of approximately 98%. The research team explicitly states: “For these database engines, exposure is no longer ‘the probability of being compromised’ – it is the compromise itself.”

Despite the massive scale of the attacks (involving over 215 billion records), the attackers’ actual earnings were extremely low – 318 of 514 independent attacker wallets never received any payment. Total confirmed revenue over five years was only 9.78 BTC, approximately $753,000. Attackers adopted an industrialised, automated mass scanning and ransomware‑implantation model with highly reused attack templates. Geographically, China ranked first with 11,874 marked databases, followed by the United States with 4,194.

- DBA Perspective: This data is an extremely grave security warning for DBAs. 99% of exposed MongoDB and MySQL instances are immediately compromised – this means that if your database port is exposed to the public internet without access controls, compromise is no longer a “probability issue” but a “matter of time.” The study confirms that exposure itself is nearly equivalent to compromise. DBAs must implement the most basic security baseline: default prohibition of database port exposure to the public internet; mandatory whitelist access; strong authentication; regular vulnerability scanning. Database exposure management is not “nice to have” – it is the baseline for survival.

- CTO Perspective: China ranking first globally in the number of marked databases indicates that domestic enterprises still have significant gaps in database exposure management. CTOs should establish “exposure management” as a dedicated metric and make database port public exposure a zero‑tolerance item in security baselines. The study also reveals an important fact: ransomware attacks can operate without relying on ransom payments – attackers use automated tools for batch scanning and implantation, and even with a tiny fraction of payments, the overall economic model remains viable.

- Investor Perspective: Over 30,000 databases ransomed in five years and 215 billion records leaked, yet total attacker revenue was only $753,000 – this contrast reveals a huge value gap in the database security market. Enterprise customer demand for database access control, exposure scanning, and compliance auditing services will continue to grow. Security companies that can provide database “zero trust” access solutions and automated exposure management are likely to gain valuation premiums from this wave of security anxiety.

## 04｜dotCMS Discloses Critical SQL Injection Vulnerability: Read, Write, Delete Any Database Content Without Authentication

On May 27, security researchers disclosed a critical SQL injection vulnerability in the core system of dotCMS, numbered CVE-2026-8054. The vulnerability affects versions 25.11.04‑1 through 26.04.28‑02, with affected endpoints including /api/auditPublishing/get and /api/auditPublishing/getAll.

The core issue is that these two API endpoints neither enforce authentication nor adequately sanitise user input, directly concatenating unsanitised input into dynamic SQL statements. A remote unauthenticated attacker can exploit this vulnerability to read, modify, or delete arbitrary database content.

The vulnerability has been fixed in dotCMS Core version 26.04.28‑03, where access to the affected endpoints requires an authenticated backend user with publishing-queue portlet permissions. LTS versions are not affected – the vulnerable code path was never backported to LTS versions.

- DBA Perspective: CVE-2026-8054 is a textbook case of a critical vulnerability – missing authentication + SQL injection, two fatal defects叠加. As an enterprise‑grade content management system, dotCMS’s audit publishing API endpoints are accessible without authentication and directly拼接 user input into SQL, essentially hanging a “welcome intruders” sign on the database door. Users of affected versions must upgrade immediately to version 26.04.28-03 or higher. The fact that LTS versions are not affected also reminds DBAs: when selecting technology, prioritise LTS versions, which typically have more mature security audit and patch management processes.

- CTO Perspective: The dotCMS vulnerability again confirms that “API security is the outpost of data security.” Two audit publishing API endpoints exposed to the public internet without authentication reflect a common security design flaw – development teams assume “these interfaces won’t be accessed externally,” but attackers scan every exposed endpoint. CTOs should establish an API security baseline: all API endpoints require authentication by default unless there is a clear architectural reason for an exception, and exceptions must go through security review.

- Investor Perspective: API security vulnerabilities in “data‑intensive applications” such as enterprise‑grade CMS, low‑code platforms, and BI tools are becoming a key breakthrough point for attackers. These platforms typically have direct read‑write access to backend databases. Once the API is compromised, core data assets are directly exposed. Security companies providing API security scanning, runtime protection, and vulnerability management services will benefit from the continued growth of enterprise application security spending.

## 05｜BillaBear Event Repository SQL Injection: Authenticated Users Can Execute Arbitrary SQL Commands

On May 19, the open‑source subscription management and billing platform BillaBear was disclosed to have an SQL injection vulnerability, numbered CVE-2026-31069. The vulnerability affects all versions before January 2026.

The vulnerability exists in the EventRepository component. User‑controlled metric filter names and aggregation attributes are directly interpolated into SQL queries via the sprintf() function without proper sanitisation or identifier quoting. Although filter values use parameterised queries, the filter identifiers (keys) are not parameterised. An authenticated attacker with ROLE_ACCOUNT_MANAGER privileges can exploit this vulnerability to execute arbitrary SQL commands.

- DBA Perspective: CVE-2026-31069 is a classic case of “incomplete parameterisation” – developers thought they were safe using parameterised queries but forgot to handle identifiers such as table names and column names the same way. Such vulnerabilities still appear frequently in the ORM era, reminding DBAs and development teams that parameterised queries are not a silver bullet. When dealing with dynamic table names, column names, or order‑by fields, whitelist validation must be used. It is recommended to check the usage of billing platforms such as BillaBear and upgrade to patched versions promptly.

- CTO Perspective: The BillaBear vulnerability reveals the danger of “partial parameterisation” – developers parameterised query values but still used string concatenation for query structure (column names, table names). This kind of “incomplete defence” is often more dangerous than no defence at all because it creates a false sense of security. CTOs should add specialised checks for dynamic SQL construction in code reviews, ensuring that all user input (whether query values or query structure) is properly handled.

- Investor Perspective: BillaBear, dotCMS, and other enterprise applications disclosing SQL injection vulnerabilities intensively within the same week reflects that security validation for “data‑intensive applications” still has significant gaps. As enterprise data stacks become more complex, the demand for security auditing of application‑layer APIs will continue to grow, benefiting service providers offering DAST, SAST, and interactive application security testing.

## 📅 Recent Database Hot Topics Recap

| Date | Event | Core Highlights |

|------|-------|-----------------|

| May 26 | Ransomnews releases 5‑year ransomware economy report | Over 30,000 exposed databases ransomed; MongoDB/MySQL exposure = compromise; China ranks first in marked databases |

| May 27 | Kingware publishes DBA true voice article | Core system database migration: “What we fear isn’t the technology – it’s the collapse of trust” |

| May 27 | Kingware publishes MySQL migration “organ transplant” practice article | Heterogeneous dual‑track becomes future norm; migration is a three‑year systematic project |

| May 27 | dotCMS SQL injection vulnerability CVE-2026-8054 disclosed | API endpoints without authentication; can read, write, delete any database content |

| May 19 | BillaBear CVE-2026-31069 disclosed | Authenticated users can execute arbitrary SQL; case of incomplete parameterisation |

| May 29 | Tencent Cloud “Database + AI” product launch (1 day countdown) | Debut of six core engines; Agent‑era data foundation final unveiling |

## 📌 Issue Summary

| News | Core Keywords | DBA Actions | CTO/Decision‑Maker Focus | Investor Perspective |

|------|---------------|-------------|--------------------------|----------------------|

| DBA true voice: core system migration | Financial core migration, 60TB+ data, collapse of trust | Establish migration risk assessment framework; value “psychological safety baseline”; learn “small steps, fast iteration” strategy | Xinchuang replacement for core systems needs not only performance baseline but team psychological safety baseline | “Zero‑incident” migration cases are the rarest commercial moat for domestic DB vendors |

| MySQL migration “organ transplant” practice | Heterogeneous dual‑track, three‑year systematic project, transaction isolation difference → check +300% | Include “hidden rejection” in risk list; focus on testing transaction boundary behaviour under high concurrency | Design long‑term heterogeneous coexistence architecture; allow gradual migration of core business | Vendors with strong migration toolchains and heterogeneous sync capabilities will continue to receive service revenue |

| Ransomnews ransomware economy report | Exposure = compromise, China ranks #1, $753k in 5 years | Default prohibition of DB port public exposure; mandatory whitelist + strong authentication | Make DB public exposure a “zero tolerance” item in security baseline | Zero trust DB access and exposure scanning security companies gain valuation premium |

| dotCMS SQL injection CVE-2026-8054 | API without authentication, arbitrary R/W/D, LTS unaffected | Upgrade immediately to 26.04.28-03; prioritise LTS versions | API security baseline: all endpoints require authentication by default | API security scanning and runtime protection companies benefit from application security spending growth |

| BillaBear SQL injection CVE-2026-31069 | Incomplete parameterisation, unquoted identifiers, authenticated privilege escalation | Check usage of billing platforms; dynamic table/column names must use whitelist validation | Add dedicated dynamic SQL checks in code reviews; incomplete defence is more dangerous than none | DAST/SAST security testing service providers see continued demand growth |

> HiddenMerit Team Production

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