XWiki REST API Unauthenticated SQL Injection via HQL Bypass

CVE-2025-32969 is a critical SQL injection vulnerability affecting the XWiki Platform, a generic wiki platform written in Java. The vulnerability resides in the REST API component, specifically at the /rest/wikis/{wiki}/query endpoint. This endpoint allows users to perform searches using languages like Hibernate Query Language (HQL) or XWiki Query Language (XWQL). Ideally, these languages are abstractions that prevent direct SQL manipulation. However, the implementation failed to correctly sanitize specific 'short-form' HQL queries—queries that omit the SELECT clause and start directly with WHERE or ORDER BY.

Due to improper validation logic in the HqlQueryExecutor, an unauthenticated attacker can supply a malicious payload that the system interprets as a safe HQL fragment. In reality, the payload contains escape sequences that break out of the HQL parser's intended context. Once the query is translated to native SQL by the Hibernate engine, the injected SQL commands are executed by the database. This effectively grants the attacker direct interaction with the database management system (DBMS) with the privileges of the XWiki database user.

The vulnerability is rated Critical (CVSS 9.8) because it requires no authentication, can be exploited remotely over the network, and requires no user interaction. It affects a wide range of XWiki versions, from 1.8 up to recent releases in the 15.x and 16.x branches.

The root cause of this vulnerability is twofold: a logic error in query sanitization and the usage of an insecure query manager in the REST API context.

First, the HqlQueryExecutor.isSafeSelect method is responsible for ensuring that user-provided HQL does not contain dangerous constructs before execution. XWiki supports 'short-form' queries (e.g., where doc.name like 'A%'), which the system automatically expands into a full select statement. The vulnerability arose because the validation logic did not fully normalize these short-form queries before checking them. Attackers discovered that by using specific character sequences—such as combining backslashes with single quotes (1<>'1\')—they could confuse the HQL parser. The parser would interpret the input as a safe string literal, while the underlying SQL driver would interpret the escape characters differently, allowing the attacker to close the string and append raw SQL commands (e.g., UNION SELECT).

Second, the AbstractDatabaseSearchSource component, which handles REST API search requests, was injecting a generic QueryManager rather than the explicitly secured variant. The standard QueryManager does not automatically apply the rigorous authorization filters and context-aware checks required for public-facing endpoints. This architectural oversight meant that even if the HQL injection was difficult, the authorization boundaries were weaker than intended, facilitating the bypass of wiki-specific security policies.

The remediation for CVE-2025-32969 involved hardening the query executor and enforcing the use of secure components. The fix was applied in commit 5c11a874bd24a581f534d283186e209bbccd8113.

1. Enforcing Secure Query Manager In AbstractDatabaseSearchSource.java, the dependency injection was updated to explicitly request the secure QueryManager. This ensures that all queries processed through this source are subject to stricter security constraints by default.

// Vulnerable Code
@Inject
private QueryManager queryManager;
 
// Fixed Code
@Inject
@Named("secure") // Explicitly use the secure implementation
private QueryManager queryManager;

2. Normalizing Short-Form Queries The most critical fix occurred in HqlQueryExecutor.java. The updated code ensures that any query identified as a short-form statement is fully normalized (expanded into a complete SELECT statement) before it is passed to the safety validator. This prevents the validator from analyzing a partial fragment that looks safe but becomes dangerous upon expansion.

// Logic pseudo-code for the fix in HqlQueryExecutor
public void checkAllowed(Query query) {
    String statement = query.getStatement();
    
    // Fix: Normalize short queries (starting with 'where', 'order by')
    // to full 'select doc.fullName from XWikiDocument doc ...' form
    // BEFORE performing safety checks.
    if (isShortForm(statement)) {
        statement = normalizeToFullQuery(statement);
    }
    
    // Perform validation on the fully expanded statement
    if (!isSafeSelect(statement)) {
        throw new SecurityException("Query is not allowed");
    }
}

This change eliminates the ambiguity that allowed the parser bypass. By validating the exact string that will be processed by Hibernate, the system ensures that no hidden SQL context escapes remain.

Exploitation relies on sending a crafted GET request to the REST API. The attacker utilizes the q parameter to inject the malicious HQL/SQL payload and sets the type parameter to hql. A typical attack uses a Time-Based Blind SQL Injection vector, where the attacker asks the database to sleep for a specific duration to confirm the injection.

Proof of Concept Payload:

GET /rest/wikis/xwiki/query?q=where%20doc.name=length(%27a%27)*org.apache.logging.log4j.util.Chars.SPACE%20or%201%3C%3E%271%5C%27%27%20union%20select%201,2,3,sleep(7)%20%23%27&type=hql&distinct=0 HTTP/1.1
Host: target-xwiki.example.com

Payload Decomposition:

1. Prefix (where doc.name=...): This satisfies the parser's requirement for a "short-form" query, engaging the vulnerable code path.
2. HQL Escape (1<>'1\'): The sequence 1<>'1\'' is the core of the bypass. It leverages a discrepancy between how the HQL parser and the SQL driver handle escaped quotes. To HQL, this appears to be a comparison involving a string. To the SQL engine, the backslash escapes the quote, closing the string literal early.
3. Injection (union select ... sleep(7)): Once the string literal is closed in the generated SQL, the attacker appends a UNION SELECT statement invoking sleep(7). If the server takes 7+ seconds to respond, the vulnerability is confirmed.
4. Comment (#): The trailing hash character comments out the rest of the legitimate query generated by Hibernate, preventing syntax errors.

The impact of this vulnerability is severe due to the level of access obtained and the lack of authentication required.

Confidentiality (High): Attackers can extract the entire database contents. This includes wiki pages, configuration data, and critically, the xwikiusers table which contains user credentials (password hashes). Access to this table often allows for offline cracking or pass-the-hash attacks to gain administrative access to the application.

Integrity (High): While the PoC demonstrates a SELECT injection, the underlying flaw allows arbitrary SQL execution. Depending on the database user's privileges (often high in default configurations), an attacker could execute UPDATE or DELETE statements. This allows for defacement of the wiki, insertion of malicious JavaScript (XSS) into pages, or the creation of new administrative users.

Availability (High): Attackers can execute resource-intensive queries (e.g., BENCHMARK or long SLEEP commands) that exhaust database connection pools or CPU resources, rendering the XWiki instance unresponsive to legitimate users.