Tencent APIJSON CVE-2026-72565

Exploitation requires that the target application expose an APIJSON query endpoint reachable by an untrusted/guest role and that the request use the @having operator in its Map (object) form rather than the String form - the Map form is the exact code path that skips the per-role allow-list check in AbstractSQLConfig.java. The high-value target is tables configured with get:[] (empty read allow-list), which the bug lets a guest read. Per CVSS AV:N/AC:L/PR:N/UI:N there is no authentication, user interaction, or special client requirement beyond crafting the Map-form @having payload. The practical limiting factor is deployment: the app must be built on a vulnerable APIJSONORM (≤8.1.8) and permit anonymous/guest queries to the affected endpoint.

The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, base 9.8) is consistent with the description: reachable over the network, low complexity, no privileges, no user interaction - a genuinely easy-to-trigger condition on exposed APIJSON instances. However, the described impact is reading arbitrary tables, which maps cleanly to Confidentiality:High but does not clearly support Integrity:High or Availability:High as scored; the raw-9.8 I:H/A:H components appear inflated for a HAVING-clause read primitive, so my independent assessment lowers real integrity/availability impact (see assessed vectors). No EPSS score, KEV entry, POC, or SSVC data was supplied. There is no evidence of active exploitation and no public exploit identified at time of analysis, so this should be treated as a high-severity, high-exposure but not-yet-known-exploited issue: prioritize based on whether an APIJSON backend is internet-reachable. The main real-world limiter is deployment footprint (relatively niche framework), not exploit difficulty.

An attacker with only guest/anonymous access sends a crafted APIJSON request containing an @having condition expressed as a Map instead of a String, embedding a raw SQL fragment that the role allow-list fails to inspect. The injected HAVING clause is concatenated into the generated query, letting the attacker read rows from tables configured as unreadable (get:[]) and exfiltrate database contents. No public exploit was identified at time of analysis, but the low complexity and lack of authentication make weaponization straightforward.