What is the CVSS score of CVE-2026-72565?

CVE-2026-72565 has a CVSS 3.1 base score of 9.8 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.5%.

Which versions of Tencent APIJSON are affected by CVE-2026-72565?

Tencent APIJSON (versions 8.1.8 and earlier) contains a critical unauthenticated SQL injection vulnerability that allows remote attackers to bypass framework access controls and read database tables…

How to fix or mitigate CVE-2026-72565?

Within 24 hours: immediately inventory all systems running Tencent APIJSON versions 8.1.8 or earlier and restrict direct internet access via network segmentation or reverse proxy; deploy web application firewall rules to reject requests containing @having parameters in Map form. Within 7 days: audit database access logs for suspicious @having usage and role-bypass patterns; review any tables marked with get:[] (unreadable) for unauthorized access; enable query logging at the database level to detect SQL injection attempts. Within 30 days: continuously monitor vendor advisories for a patched version; prepare a migration plan to upgrade APIJSON or replace it with an alternative framework; document which internal systems depend on APIJSON to prioritize remediation sequencing.

Tencent APIJSON CVE-2026-72565

EUVD-2026-55241 CRITICAL

SQL Injection (CWE-89)

2026-08-10 TuranSec

GHSA-46x4-v393-xfpx

Java SQLi Tencent Apijson

9.8

CVSS 3.1 · Vendor: TuranSec

Severity by source

Vendor (TuranSec) PRIMARY

9.8 CRITICAL

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

vuln.today AI

7.5 HIGH

Unauthenticated network-reachable, low-complexity injection with no user interaction (AV:N/AC:L/PR:N/UI:N); a HAVING-clause read primitive yields high confidentiality but no demonstrated integrity or availability impact.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (TuranSec).

CVSS VectorVendor: TuranSec

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Aug 10, 2026 - 11:15 vuln.today

CVE Published

Aug 10, 2026 - 10:40 cve.org

CRITICAL 9.8

DescriptionCVE.org

A SQL injection vulnerability in Tencent APIJSON through 8.1.8 allows unauthenticated remote attackers to bypass per-table access control and read arbitrary database tables via the Map-form @having operator. The APIJSONORM library's AbstractSQLConfig.java applies the per-role allow-list check only on the String form of @having but not on the Map form, allowing a guest user to inject raw SQL fragments and read tables that are configured with get:[] (empty, meaning no role can read them).

Articles & Coverage 1

News Critical SQL Injection in Tencent APIJSON through 8.1.8 - CVE-2026-72565 Aug 10, 2026

AnalysisAI

Unauthenticated SQL injection in Tencent APIJSON (through 8.1.8) lets remote attackers bypass the framework's per-table role-based access control and read tables explicitly marked unreadable (get:[]). The APIJSONORM library validates the per-role allow-list only for the String form of the @having operator, so supplying @having in its Map form smuggles raw SQL fragments past the guard as an anonymous guest user. No public exploit identified at time of analysis, but the flaw is trivially reachable over the network with no authentication.

Technical ContextAI

APIJSON is an open-source, JSON-based ORM/query protocol from Tencent that auto-generates SQL from client-supplied JSON, exposing database access directly to front-end clients with a role/permission model instead of hand-written endpoints. The @having operator maps to the SQL HAVING clause and can be expressed either as a String or as a Map (key/value) structure. In AbstractSQLConfig.java the allow-list enforcement that restricts which raw SQL fragments a given role may inject is applied on the String form only; the Map form is parsed and concatenated into the query without the same role check. This is a classic CWE-89 (improper neutralization of SQL) failure - the root cause is an incomplete/inconsistent input-validation path where one representation of the same feature is trusted while an equivalent one is not, and it interacts with APIJSON's access-control layer to also defeat per-table read restrictions. The single affected CPE is cpe:2.3:a:tencent:apijson:*, i.e. the APIJSONORM Java library embedded in applications built on the framework.

RemediationAI

No vendor-released patch version was identified at time of analysis, and the supplied references point only to the project repository and the affected AbstractSQLConfig.java source file rather than a tagged fix, so upgrade to a fixed release once Tencent publishes one (track https://github.com/Tencent/APIJSON releases). As concrete compensating controls: block or disable the Map form of the @having operator at the application/request-filter layer, or reject any request whose @having value is an object rather than a permitted string, which closes the specific bypass at the cost of losing Map-form HAVING functionality; enforce the per-table read allow-list server-side independent of @having form so tables set to get:[] are never queried by guest roles; require authentication on the APIJSON endpoint and remove guest/anonymous roles where feasible; and restrict network exposure of the APIJSON query endpoint to trusted internal callers (WAF/reverse-proxy rule denying HAVING-like SQL keywords in JSON bodies) - noting WAF pattern matching on JSON can produce false positives and is a stopgap, not a fix.