CVE-2025-32429

What it actually does

The vulnerable XWiki deleted-documents Velocity template accepts the `sort` request parameter and inserts it directly into an SQL `ORDER BY` clause without safe allow-listing or parameterization. Because `ORDER BY` expressions can contain database functions, subqueries, conditional expressions, and error/time-based payloads in many SQL dialects, an attacker can manipulate the generated query. Practical impact can include SQL error disclosure, boolean/time-based data extraction, reading sensitive application data, altering database-backed content if the database account permits writes, and potentially escalating further through XWiki data stored in the database such as users, permissions, tokens, pages, or configuration values.

Why it matters to the business

A successful attack can expose or corrupt wiki content, user information, deleted documents, access-control data, and other database-backed application records. If the wiki is used for operational documentation, credentials, runbooks, intellectual property, or internal collaboration, exploitation can lead to data breach, loss of trust in content integrity, service disruption, and costly incident response. The risk is elevated because exploit maturity is listed as weaponized, EPSS is high at 0.8541, and the issue has been public for over a year, giving attackers ample time to incorporate it into scanning and exploitation workflows. It is not currently listed in CISA KEV and is not marked as ransomware-associated, but the exploitation likelihood remains high.

How an attack unfolds

An attacker identifies an exposed XWiki instance and locates the deleted-documents view that invokes `getdeleteddocuments.vm`. The attacker sends requests with a crafted `sort` parameter instead of a normal sortable field. Because the value is copied into the SQL `ORDER BY` clause, the database evaluates attacker-controlled SQL expressions. The attacker first confirms injection using syntax errors, conditional ordering, or timing differences, then iterates payloads to infer database type, table structure, and sensitive values. Depending on database privileges and application configuration, the attacker may extract user records, page content, deleted-document metadata, authentication material, or permission data, and may attempt to modify database-backed application state to gain persistence or higher privileges.

How to fix it

Upgrade affected components to fixed versions or later. For XWiki source-based deployments, update `xwiki/xwiki-platform` to a revision containing commit `dfd0744e9c18d24ac66a0d261dc6cafd1c209101` and `xwiki/xwiki-commons` to a revision containing commit `ea21b6389eb2aeb9660ef5bc0bc38beeac372c9e`. For listed Alpaquita packages, update `bind` on Alpaquita 23 to `9.18.28-r0` or later and Alpaquita stream to `9.18.28-r1` or later, while also validating whether the package mapping is relevant to the deployed application stack. If immediate upgrade is not possible, restrict access to the deleted-documents endpoint, require authentication and least-privilege authorization, place a WAF or reverse proxy rule in front of the application to block suspicious `sort` values, and allow only known-good sort field names. Long term, ensure all dynamic SQL sort fields are selected from a server-side allow-list rather than accepting raw request values.

How to confirm the fix worked

Confirm the deployed XWiki code or package version contains the fixed commits or a later release that includes them. Review the implementation of `getdeleteddocuments.vm` and related deleted-document query code to verify that the `sort` parameter is validated against an allow-list of legitimate column names or sort keys and is not concatenated directly into SQL. From a non-production test context, send requests with invalid SQL syntax, SQL comments, database functions, and timing expressions in the `sort` parameter and verify that the application rejects them safely without SQL errors, response delays, or changed query behavior. Check package managers, build manifests, container images, and deployed artifacts to ensure no vulnerable XWiki component remains. Validate compensating controls by confirming WAF or reverse proxy logs show blocking for malicious `sort` patterns while normal deleted-document sorting still works.

Typical attack path

1. Discover an internet-facing or otherwise reachable XWiki deployment.
2. Request the deleted-documents functionality that uses `getdeleteddocuments.vm`.
3. Submit a benign `sort` value to establish normal behavior and response timing.
4. Submit crafted `sort` values containing SQL expressions, comments, functions, or subqueries to confirm SQL injection in the `ORDER BY` clause.
5. Fingerprint the database engine using errors, timing behavior, or dialect-specific functions.
6. Use boolean-based, error-based, or time-based techniques to enumerate schema and extract sensitive records.
7. Attempt to access or modify database-backed XWiki content, users, permissions, tokens, or configuration if database privileges allow.
8. Cover tracks by minimizing noisy errors or blending requests into normal application traffic.

How to detect it

Investigate historical web server, reverse proxy, load balancer, WAF, XWiki application, and database logs for requests to `getdeleteddocuments.vm` where the `sort` parameter contains SQL syntax rather than a simple field name. Prioritize evidence of SQL comments, quotes, parentheses, subqueries, conditional expressions, concatenation operators, encoded payloads, and timing functions such as `SLEEP`, `BENCHMARK`, or `pg_sleep`. Review application logs for SQL exceptions mentioning `ORDER BY`, deleted-document retrieval, invalid column names, syntax errors, or database-specific error messages around the same timestamps. Review database audit logs for abnormal queries issued by the XWiki database user, especially queries against user, permission, document, attachment, token, and configuration tables. Look for time-correlated slow queries and repeated requests with slightly changing `sort` values, which can indicate blind extraction. If exploitation is suspected, examine XWiki administrative events, newly created users, permission changes, page or attachment modifications, deleted-document access, suspicious script content, and unexpected configuration changes.

• getdeleteddocuments.vm
• getdeleteddocuments.vm?sort=
• sort=(select
• sort=select
• sort=case when
• sort=sleep(
• sort=benchmark(
• sort=pg_sleep(
• sort=extractvalue(
• sort=updatexml(
• sort=concat(
• sort=@@version
• sort=version()
• sort=database()
• sort=information_schema
• sort=--
• sort=%2D%2D
• sort=/*
• sort=%2F%2A
• ORDER BY
• SQL syntax
• invalid column
• Unknown column
• java.sql.SQLException
• org.hibernate.exception.SQLGrammarException
• getdeleteddocuments.vm sort

What your security team should do

• Treat this as high priority because exploit maturity is weaponized, EPSS is high, and the vulnerability has been public for over a year.
• Patch or upgrade affected XWiki components first on externally reachable and high-sensitivity wiki deployments.
• Search web, reverse proxy, WAF, application, and database logs for suspicious `getdeleteddocuments.vm` requests and malicious `sort` parameter values before and after patching.
• Temporarily restrict access to deleted-document administration or recycle-bin functionality until remediation is complete.
• Deploy WAF rules that block SQL metacharacters, comments, subqueries, and database timing functions in the `sort` parameter for the affected endpoint.
• Review database account privileges used by XWiki and remove unnecessary write, administrative, file, or external execution capabilities.
• After patching, rotate credentials or tokens that may have been stored in wiki pages, deleted documents, configuration, or database-backed secrets if exploitation is suspected.
• Correlate suspected exploit attempts with unusual XWiki authentication events, permission changes, page modifications, new administrator accounts, and database errors.