CVE-2025-32969

What it actually does

This vulnerability allows a remote unauthenticated attacker to break out of XWiki's HQL query execution context and inject backend SQL. Because exploitation can occur even when anonymous page viewing and editing are disabled, access-control settings that normally protect content do not reliably prevent attack. Impact depends on the database engine and application privileges: at minimum, blind SQL injection can be used to infer data from the database, and in some configurations it may allow arbitrary SELECT, UPDATE, INSERT, or DELETE statements against XWiki application tables. Potential outcomes include disclosure of user records and password hashes, unauthorized content modification, privilege manipulation, data deletion, and persistence through database-backed application changes.

Why it matters to the business

An exposed vulnerable XWiki instance can be compromised without credentials, putting internal documentation, credentials stored in wiki content, user identity data, and operational knowledge at risk. The high EPSS score and weaponized exploit maturity indicate a strong likelihood of opportunistic internet-scale exploitation, even though the issue is not currently listed in CISA KEV and is not known to be ransomware-specific. Successful exploitation may cause data breach obligations, loss of trust in internal knowledge systems, service disruption, and costly recovery if attackers alter or delete database content.

How an attack unfolds

An attacker first identifies an internet-facing or otherwise reachable XWiki deployment and sends crafted HTTP requests to vulnerable functionality that causes XWiki to build or execute an HQL query. The payload is structured so that part of the input escapes the intended HQL context and is interpreted by the database as SQL. Because this is blind SQL injection, the attacker may not receive query results directly; instead, they infer results through differences in application behavior, HTTP response codes, response length, error messages, or timing delays. After confirming injection, the attacker enumerates database type and schema, extracts sensitive data such as user records or password hashes, and may attempt write operations if the database account permits them. In higher-impact scenarios, the attacker modifies wiki content, changes user privileges, inserts malicious objects or scripts into database-backed content, or deletes data to disrupt operations.

How to fix it

Upgrade XWiki components to versions containing the upstream fixes. For source-based deployments, ensure xwiki-commons includes commit d8a509c53e75e2773666a2824b6f8e24c650419f and xwiki-platform includes commit ce9ec01ee77a3c38f1038e567a34e4f215472f7a. If consuming vendor packages, apply the vendor-provided security updates and verify that the installed package versions meet or exceed the fixed versions listed for the relevant distribution. The listed Rocky Linux 8 package fixes include perl-App-cpanminus 0:1.7044-6.module+el8.10.0+1886+1635aa55, perl-CPAN-DistnameInfo 0:0.12-13.module+el8.10.0+1616+0d20cc68, perl-CPAN-Meta-Check 0:0.014-6.module+el8.10.0+1890+1072d5cf, perl-File-pushd 0:1.014-6.module+el8.10.0+1890+1072d5cf, perl-Module-CPANfile 0:1.1002-7.module+el8.10.0+1890+1072d5cf, perl-Parse-PMFile 0:0.41-7.module+el8.10.0+1890+1072d5cf, and perl-String-ShellQuote 0:1.04-24.module+el8.10.0+1890+1072d5cf. Treat configuration options that block anonymous viewing or editing as insufficient mitigation for this vulnerability. Until patched, restrict network access to XWiki, place it behind authentication or VPN controls, apply WAF rules for SQL injection patterns, reduce database privileges used by the application to the minimum required, ensure reliable backups, and monitor for suspicious unauthenticated requests.

How to confirm the fix worked

Confirm that the deployed XWiki build includes the fixed xwiki-commons and xwiki-platform commits or a vendor release that incorporates them. Validate package inventory against the fixed versions supplied by the relevant distribution. From an exposure perspective, verify whether XWiki endpoints are reachable without authentication from untrusted networks and whether WAF or reverse-proxy controls are in place. Use a safe, non-destructive vulnerability check from an approved scanner or vendor-provided test to confirm that crafted unauthenticated HQL/SQL injection probes no longer produce timing differences, SQL errors, or anomalous responses. Review database user privileges to ensure the XWiki application account cannot perform unnecessary administrative actions. After patching, restart the application as required, clear stale containers or images, and verify the running service is using the updated artifacts rather than only having updated files on disk.

Typical attack path

1. Discover a reachable XWiki instance, commonly through web fingerprinting, search engine indexing, or scanning for XWiki-specific paths and headers.
2. Send unauthenticated requests containing malformed HQL/SQL control characters or conditional expressions to the vulnerable endpoint.
3. Confirm blind SQL injection through behavioral differences such as timing delays, changed response size, HTTP errors, or true/false condition responses.
4. Fingerprint the database backend, such as MySQL or MariaDB, and determine which SQL functions and syntax are accepted.
5. Enumerate database metadata and application tables using blind extraction techniques.
6. Extract sensitive records such as user information, password hashes, authentication tokens, or confidential wiki content.
7. If database permissions allow, execute write queries to modify content, create or elevate users, insert malicious database-backed content, or delete records.
8. Cover tracks by minimizing noisy errors, rotating source infrastructure, and potentially altering application audit data stored in the database.

How to detect it

Investigate web server, reverse-proxy, WAF, XWiki application, and database logs for unauthenticated requests to XWiki endpoints containing SQL control characters, encoded operators, comments, database function names, or metadata table references. Because exploitation may be blind, look for repeated requests with small payload variations, consistent response-size differences, spikes in 4xx or 5xx errors, and timing anomalies where requests take several seconds longer than normal. Pay special attention to payloads using MySQL or MariaDB time-delay functions such as SLEEP or BENCHMARK, conditional expressions, UNION SELECT attempts, references to information_schema, and URL-encoded quotes or comments. Correlate suspicious web requests with database logs showing unexpected SELECT activity against user or credential-related tables, unauthorized UPDATE/INSERT/DELETE statements, schema enumeration, or errors referencing malformed SQL. Review XWiki audit and application logs for unexpected changes to pages, users, groups, rights, scripts, or objects made around the time of suspicious unauthenticated requests. If compromise is suspected, compare database contents to known-good backups, check for newly created administrator accounts or altered rights, and perform credential rotation for accounts whose hashes or secrets may have been exposed.

• /xwiki/bin/view/
• /xwiki/bin/get/
• /xwiki/bin/view/%27
• /xwiki/bin/get/%27
• %27%20or%20%271%27%3D%271
• %22%20or%20%221%22%3D%221
• union%20select
• UNION SELECT
• information_schema
• INFORMATION_SCHEMA
• sleep(
• SLEEP(
• benchmark(
• BENCHMARK(
• pg_sleep(
• waitfor%20delay
• WAITFOR DELAY
• extractvalue(
• updatexml(
• --%20
• %23
• /*
• */
• java.sql.SQLException
• SQLSyntaxErrorException
• org.hibernate.QueryException
• org.hibernate.exception.SQLGrammarException
• unexpected token
• could not extract ResultSet
• You have an error in your SQL syntax
• Table 'information_schema
• HQL

What your security team should do

• Prioritize patching all exposed XWiki deployments immediately because exploit maturity is weaponized and the EPSS score indicates high exploitation probability.
• Inventory all XWiki Standard Flavor, containerized XWiki, source-based XWiki, and distribution-packaged XWiki deployments, including non-production systems reachable over the network.
• Temporarily restrict unauthenticated network access to XWiki until the fixed build is deployed and validated.
• Review web, reverse-proxy, WAF, application, and database logs for signs of blind SQL injection attempts and suspicious unauthenticated access before and after remediation.
• Rotate credentials and invalidate sessions if logs indicate successful data extraction or database modification may have occurred.
• Harden the database account used by XWiki so it has only the privileges necessary for normal operation and no unnecessary administrative capabilities.
• Create or verify recent offline backups before remediation and confirm restore procedures in case data tampering is discovered.
• Add SIEM detections for SQL injection payload fragments against XWiki paths, especially time-based blind SQL functions and database metadata enumeration terms.