CVE-2026-72565

Executive Summary

CVE-2026-72565 is an unauthenticated SQL injection vulnerability in Tencent APIJSON through version 8.1.8. The flaw resides in the APIJSONORM library's AbstractSQLConfig.java, where per-role access control checks are applied only to the String form of the @having operator but are bypassed when the Map form is used, allowing a guest user to execute arbitrary SQL fragments. The vulnerability carries a CVSS score of 9.8 (Critical) and enables remote attackers to read arbitrary database tables regardless of table-level read permissions, leading to complete confidentiality, integrity, and availability compromise of the underlying database. As of this report, no official patch has been released.

Technical Analysis

APIJSON is an open-source framework developed by Tencent that automates JSON-based API generation from database schemas, enabling clients to specify complex query operations through structured JSON requests. The framework performs automatic validation, access control, and SQL generation server-side.

The vulnerability is rooted in the AbstractSQLConfig.java file within the APIJSONORM library — specifically in how the @having clause is processed. The @having operator allows clients to filter grouped results using aggregate functions (e.g., COUNT, SUM, AVG, MAX, MIN). APIJSON supports two distinct representations for this operator:

1. String form: "@having": "COUNT(id) > 10" — a raw SQL fragment.
2. Map form: "@having": {"COUNT(id)": ">"} or "@having": {"COUNT(id)": "> 10"} — a structured key-value representation.

Internally, the access-control mechanism implements a per-role allow-list check that evaluates whether the requested operation/column combination is permitted for the authenticated role (or guest/unauthenticated role). This check is applied to the String form of @having, but the code path handling the Map form fails to invoke the same validation routine.

The bypass works as follows:

1. The client sends an HTTP request with a JSON payload containing a query structure.
2. The @having field is supplied in Map form.
3. The allow-list validation function — which is invoked for String-form @having — is never called for the Map form.
4. The Map form values are concatenated into the final SQL HAVING clause without sanitization or permission checking.
5. An attacker can embed raw SQL injection payloads within the map values, corrupting the generated SQL statement.

The critical consequence is that this bypass extends beyond the HAVING clause itself. Because an attacker can inject arbitrary SQL fragments, they can manipulate the entire SQL statement — for example, appending UNION SELECT, subqueries, or modifying conditions to force the query to return rows from tables configured with get:[] (empty permission lists, meaning no role is authorized to read them). Tables with get:[] configurations are meant to be completely inaccessible, but this flaw nullifies that protection entirely.

Notably, the authentication requirement is nonexistent — a guest user (unauthenticated) can exploit this flaw because the @having Map-form processing path does not distinguish roles during the validation bypass.

Exploitation Scenarios

Scenario 1: Arbitrary Table Read via UNION-Based Injection

Step 1 — Reconnaissance/Target Identification:
The attacker identifies an exposed APIJSON endpoint by scanning for APIJSON-typical paths such as /, /get, or /head, or by detecting the framework signature in HTTP response headers or the server's default welcome page. Shodan queries can identify public APIJSON instances.

Step 2 — Crafting the Trigger Payload:
The attacker sends an HTTP POST request to a public APIJSON endpoint with the following JSON body:

{
  "User": {
    "id@": {},
    "@having": {
      "COUNT(id)": "> 0 UNION SELECT username, password, '1' FROM admin_user LIMIT 1--"
    }
  }
}

Step 3 — Server-Side Processing:
The server parses the @having field as a Map. Because the Map-form processing path lacks the allow-list check, the value > 0 UNION SELECT username, password, '1' FROM admin_user LIMIT 1-- is concatenated directly into the generated SQL statement:

SELECT id FROM User GROUP BY id HAVING COUNT(id) > 0 UNION SELECT username, password, '1' FROM admin_user LIMIT 1--

Step 4 — Data Exfiltration:
The injection appends a UNION query that retrieves credentials from an administratively protected table (admin_user). The database executes the complete statement and returns the admin credentials within the HTTP JSON response. The attacker has now exfiltrated sensitive data from a table explicitly configured as unreadable (get:[]).

Step 5 — Post-Exploitation:
With valid admin credentials, the attacker may escalate further: modify records, pivot to other systems sharing the same database, or deploy persistence. The confidentiality, integrity, and availability impact (CVSS subscores: C:H, I:H, A:H) is immediate and severe.

Scenario 2: Boolean-Based Blind Extraction

Step 1 — Target Identification:
Same reconnaissance as Scenario 1.

Step 2 — Blind Injection Payload:
The attacker crafts a request where the Map-form @having value contains a conditional subquery that yields a boolean observable difference in the response:

{
  "Product": {
    "name": "",
    "@having": {
      "COUNT(name)": "> (SELECT CASE WHEN (SELECT COUNT(*) FROM confidential_tbl) > 100 THEN 1 ELSE 999 END)"
    }
  }
}

Step 3 — Response Analysis:
By observing whether a result set is returned or an error occurs, the attacker systematically extracts table names, column names, and row data one bit at a time.

Step 4 — Full Extraction:
Through iterative requests, the attacker reconstructs complete database contents, including columns beyond the get:[] protection list.

Impact Assessment

Business Impact:
APIJSON is used to power public-facing REST APIs across numerous Tencent services and third-party deployments. An unauthenticated attacker can read arbitrary tables, including authentication credentials, personally identifiable information, financial records, and proprietary business data. Because the vulnerability allows SQL injection with no privilege requirements, the entire database backend is exposed.

Affected Systems:
All APIJSON deployments running version 8.1.8 or earlier that expose /get or equivalent endpoint paths to untrusted networks. The APIJSONORM library is the affected component, so any application embedding this library is vulnerable.

Blast Radius:

• Confidentiality: Complete — arbitrary database read via UNION/subquery injection.
• Integrity: High — SQL injection can be leveraged for data modification or deletion.
• Availability: High — the attacker can execute statements that lock or corrupt tables, or trigger resource exhaustion.

The CVSS vector reflects this with a base score of 9.8: Network vector, low attack complexity, no privileges required, no user interaction, and high impact across all three security pillars.

Detection Guidance

Sigma Rule

title: APIJSON @having Map-Form SQL Injection Attempt
id: 3f8c6e2a-9d41-4c7a-b3e5-7a1f8d0e2c44
status: experimental
description: Detects HTTP requests to APIJSON endpoints containing a Map-form @having field with potential SQL injection payloads.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-72565
author: Valtersit SOC
date: 2026/01/15
logsource:
    category: webserver
    product: apache
    service: http
detection:
    selection_method:
        cs-method:
            - 'POST'
            - 'PUT'
    selection_url:
        cs-uri-query|contains:
            - '/get'
            - '/head'
    selection_body|contains:
        - '"@having"'
    selection_sqli|contains:
        - 'UNION SELECT'
        - 'UNION ALL'
        - 'substr('
        - 'sleep('
        - 'benchmark('
        - '--'
        - '/*'
    condition: selection_method and selection_url and selection_body and selection_sqli
fields:
    - c-ip
    - cs-uri-query
    - cs-useragent
falsepositives:
    - Legitimate API clients using Map-form @having with complex aggregate expressions
level: high

YARA Rule

rule CVE_2026_72565_APIJSON_SQLi
{
    meta:
        author = "Valtersit SOC"
        description = "Detects SQL injection patterns targeting APIJSON @having Map-form bypass"
        cve = "CVE-2026-72565"
        date = "2026-01-15"
        severity = "critical"
    strings:
        $a1 = "\"@having\"" ascii
        $a2 = "@having" ascii no_case
        $b1 = "UNION SELECT" ascii no_case
        $b2 = "UNION ALL" ascii no_case
        $b3 = "information_schema" ascii no_case
        $b4 = "substr(" ascii no_case
        $b5 = "benchmark(" ascii no_case
        $b6 = "sleep(" ascii no_case
        $b7 = "--" ascii
        $b8 = "/*" ascii
        $b9 = "COUNT(" ascii no_case
    condition:
        any of ($a*) and 2 of ($b*) and filesize < 10KB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-72565 APIJSON @having Map-Form SQL Injection Attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/get"; http.request_body; nocase; content:"\"@having\""; http.request_body; nocase; pcre:"/(UNION\s+(ALL\s+)?SELECT|substr\s*\(|sleep\s*\(|benchmark\s*\(|information_schema|--|\/\*)/i"; sid:202672565; rev:1; reference:cve,2026-72565; classtype:attempted-admin; priority:1;)

Elastic Detection

// Elastic EQL rule for APIJSON SQL injection via Map-form @having
sequence by source.ip, destination.ip with maxspan=5m
  [network where event.category == "network" and protocol == "http"
   and http.request.method in ("POST", "PUT")
   and wildcard(http.request.uri, "*/get*", "*/head*")]
  [network where event.category == "network" and protocol == "http"
   and wildcard(http.request.body.text, "*\"@having\"*")
   and (wildcard(http.request.body.text, "*UNION*SELECT*") or
        wildcard(http.request.body.text, "*substr(*") or
        wildcard(http.request.body.text, "*sleep(*") or
        wildcard(http.request.body.text, "*information_schema*") or
        wildcard(http.request.body.text, "*benchmark(*") or
        wildcard(http.request.body.text, "*--*"))]

Splunk SPL Query

index=web sourcetype=iis OR sourcetype=apache OR sourcetype=nginx
| where match(method, "(?i)^(POST|PUT)$")
    AND match(uri, "(?i)(/get|/head)")
    AND match(_raw, "(?i)\"@having\"")
    AND (match(_raw, "(?i)UNION\\s+(ALL\\s+)?SELECT")
         OR match(_raw, "(?i)substr\\s*\\(")
         OR match(_raw, "(?i)sleep\\s*\\(")
         OR match(_raw, "(?i)benchmark\\s*\\(")
         OR match(_raw, "(?i)information_schema")
         OR match(_raw, "(?i)--"))
| stats count by src_ip, uri, _time
| sort - _time
| table _time, src_ip, uri, count
| rename _time as "Timestamp", src_ip as "Source IP", uri as "Request URI"

Wazuh OSSEC Rule

<group name="apijson_web,">
  <rule id="100725" level="15">
    <if_sid>31151</if_sid>
    <match>POST </match>
    <regex>\/get|\/head</regex>
    <description>APIJSON request with SQL injection indicators in @having parameter</description>
    <group>sql_injection,attack,web_attack,</group>
    <field name="url">\.json</field>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100726" level="15">
    <if_sid>100725</if_sid>
    <regex>"@having"</regex>
    <description>APIJSON Map-form @having bypass — SQL injection attempt (CVE-2026-72565)</description>
    <group>sql_injection,attack,web_attack,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100727" level="15">
    <if_sid>100726</if_sid>
    <regex>UNION SELECT|UNION\s+ALL\s+SELECT|substr\(|sleep\(|benchmark\(|information_schema|--</regex>
    <description>Confirmed SQL injection payload in APIJSON @having (CVE-2026-72565)</description>
    <group>sql_injection,attack,web_attack,critical,</group>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED — no patch evidence from any tracked source.

There is currently no official patch, and APIJSON 8.1.8 is the last known release. Immediate and long-term actions are required.

1. Immediate Mitigations (no patch available):

• Disable @having altogether at the application layer if aggregate filtering is not business-critical. This can be done by rejecting any incoming request containing the @having key before it reaches AbstractSQLConfig.java.
• Deploy a WAF signature to block requests containing both "@having" and SQL metacharacters (UNION, --, subquery patterns, comments). The Suricata rule above can be adapted to ModSecurity or a commercial WAF.
• Place the APIJSON endpoint behind mandatory authentication even for guest-access features. Create temporary middleware that requires valid API keys for all requests using the Map-form @having.
• Network-level restrictions: Limit access to the API endpoint to trusted IP ranges using ingress firewall rules, significantly shrinking the attack surface.

2. Patch/Upgrade Steps:

• Monitor Tencent APIJSON releases: The official GitHub repository (Tencent/APIJSON) is the primary source for a future fix. Expected patch behavior: applying the allow-list check to the Map-form @having path identically to the String form.
• Vendor communication: Contact the Tencent security team through the repository's security advisory channel to request status updates and potential hotfixes.
• Do not simply upgrade to the latest version without confirming the fix — verify the commit history for changes to AbstractSQLConfig.java regarding @having handling before deployment.

3. Long-Term Hardening:

• Database-level mitigations: Run the database with the principle of least privilege — the application account should have read access only to tables it genuinely needs, and SELECT should be blocked at the database level for tables with get:[] configurations. Apply row-level or column-level security where supported (e.g., PostgreSQL Row-Level Security, MySQL column grants).
• Input validation framework: Implement a strict JSON schema validator upstream that rejects @having map values containing non-alphanumeric characters beyond a defined whitelist (>, <, =, alphanumerics, spaces, commas, parentheses).
• SQL statement audit: Enable database query logging to detect anomalous statements referencing tables not in the application's normal query plan.
• Security testing: Include this specific Map-form bypass in regression test suites. Use API fuzzing tools to test all parameter forms (String, Map, Array) for consistent access-control enforcement.
• Architecture review: Evaluate replacing the unrestricted SQL-clause interface with parameterized, pre-built queries that never accept raw SQL fragments from clients.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-72565
2. Tencent APIJSON GitHub Repository: https://github.com/Tencent/APIJSON
3. APIJSON Documentation (AbstractSQLConfig.java reference): https://github.com/Tencent/APIJSON/blob/master/APIJSONORM/src/main/java/apijson/orm/AbstractSQLConfig.java
4. CWE-89 — SQL Injection: https://cwe.mitre.org/data/definitions/89.html
5. CISA Known Exploited Vulnerabilities Catalog (no entry; monitor for updates): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat Actor Intelligence: As of this report's publication, there is no known exploit-in-the-wild activity, public PoC, or threat actor campaign targeting CVE-2026-72565. However, SQL injection vulnerabilities in open-source API frameworks with guest-user access typically attract rapid weaponization within 30–60 days of disclosure. The EPSS score has not yet been assigned by FIRST.org. SOC teams should maintain elevated alerting for any traffic matching the detection rules above, especially from untrusted source IPs.