Calendar of Doom: A Critical HQL Injection in XWiki

Calendars are usually the most boring part of any application. They show dates, maybe a meeting or two, and that's it. But in the world of XWiki, the Full Calendar Macro decided to spice things up by turning a simple JSON data feed into a high-stakes gambling game with your database.

Here is the setup: XWiki uses Hibernate to talk to its database. The Full Calendar Macro needs to fetch events, so it uses a Velocity script (Calendar.JSONService) to query the backend. Normally, a developer would write a specific query to fetch events.

In this case, however, the developers apparently decided that writing queries was too much work. Instead, they built what essentially amounts to a database proxy. They exposed parameters like request.sql, request.wheresql, and request.fromsql directly to the web. If you've ever thought, "Man, I wish I could just SELECT * FROM users via a URL parameter," this vulnerability is for you.

The vulnerability lies in how the Calendar.JSONService constructs its Hibernate Query Language (HQL) statement. HQL is an object-oriented dialect of SQL. It's powerful, but it still suffers from the same injection flaws as standard SQL if you treat it like a string concatenation party.

Here is the logic flaw: The script checks if the sql parameter is present in the HTTP request. If it is, it sets the HQL query directly to the value of that parameter. No filtering, no validation, no questions asked.

But wait, it gets worse. In XWiki, Velocity scripts run with the permissions of the last author who saved the document. If an administrator or a user with "Programming Rights" installed or updated this macro, that script runs with God-mode privileges.

So, you have an unauthenticated endpoint (accessible to Guests) that accepts raw database commands and executes them with the highest possible privileges. It's not just a hole in the wall; the entire wall is missing.

Let's look at the code before the patch. It is breathtaking in its simplicity and danger.

#if ("$!{request.sql}" != '')

direct injection point 1: Just overwrite the whole query

#set ($hql = $request.sql) #else

direct injection point 2: Concatenate partial strings

#set ($hql =", BaseObject as obj $!{request.fromsql} where doc.fullName=obj.name and obj.className='${request.classname}' $!{request.wheresql}") #end

#foreach ($item in $services.query.hql($hql).addFilter('currentlanguage').execute())

... return data ...

#end

The code literally says: "If the user provided `sql`, run it. Otherwise, construct a query using other user inputs (`fromsql`, `classname`, `wheresql`)." Even the "safe" path is riddled with injection points because `$\{request.classname\}` is interpolated directly into the string without binding.

Exploiting this is trivial. You don't need complex boolean-blind inferencing or time-based payloads (though those work too). You can just ask for the data you want.

Scenario: An attacker wants to dump all user credentials.

Vector: The sql parameter.

Payload:

GET /xwiki/bin/view/Calendar/JSONService?sql=select doc.fullName, doc.content from XWikiDocument doc where doc.fullName like '%Profile%'

Because the script iterates over the results and returns them as JSON, the attacker simply receives the database contents in the HTTP response. Since the script likely runs with Programming Rights, the attacker bypasses all document-level access controls. They can read private pages, password hashes (if stored in docs), and configuration secrets.

The remediation in version 2.4.5 (Commit 5fdcf06a05015786492fda69b4d9dea5460cc994) is a multi-layered approach. They didn't just fix the injection; they neutered the execution context.

Key Changes:

1. Removed sql parameter: You can no longer replace the entire query string.
2. Bind Parameters: The classname is now bound using .bindValue(), preventing string breakouts there.
3. Drop Permissions: This is the critical part.

#set ($discard = $xcontext.dropPermissions()) #foreach ($item in $services.query.hql($hqlStatement).bindValue("classname", "$!{request.classname}")...)

> [!NOTE]
> **Researcher Insight**: Notice that `$request.fromsql` and `$request.wheresql` are *still* concatenated into the query string in the fix! However, because `$xcontext.dropPermissions()` is called, the query now runs as the current user (e.g., Guest). Even if you inject SQL, you can only query documents you already have permission to see. This turns a Critical Data Exfiltration bug into a potential (but limited) Denial of Service annoyance.