Otter Wiki is an open-source, self-hosted wiki application built with Python and Flask. It uses Markdown for page content and stores wiki data in a Git repository. The project also supports features such as user authentication, page attachments, extended Markdown, and page history.
As I actively hunt for 0day vulnerabilities and publish CVEs, Otter Wiki caught my attention and I decided to take a closer look at it for possible security vulnerabilities. During testing, I discovered a path traversal vulnerability in Otter Wiki 2.22.1 and in this article I will explain it.
From DataTable Embedding to Path Traversal
While exploring Otter Wiki, I noticed that it supports role-based users with different permissions. This made the low-privileged user functionality an interesting attack surface, so I created a normal non-administrator account and assigned it only the permissions needed to Read, Write, and Upload.
I started by testing the application for common web vulnerabilities and business logic issues. Since Otter Wiki uses Markdown for page content, I played around with different inputs and payloads, including XSS and local file inclusion-style payloads.
After testing the obvious inputs, I started going through Otter Wiki's official documentation to better understand the additional syntax and features available inside a page. This is where the DataTable embedding caught my attention.
According to the official documentation, Otter Wiki supports a DataTable embedding that can render CSV attachments directly inside a page. The embedding accepts a src option that is supposed to contain the filename of a CSV attachment associated with the current page.
A normal example looks like this:
{{datatable
|src=data.csv
|header=true
}}
The fact that src was being used to reference a file immediately made it an interesting input to test. Instead of providing a normal attachment filename, I started supplying traversal sequences to see whether the path was properly restricted to the page's attachment directory.
One of the first payloads I tried was:
{{datatable
|src=../../settings.cfg
|header=false
}}
However, my initial attempts kept returning an error.
At first, it looked like the traversal simply did not work. After digging into the behavior further, I found something important: the attachment directory for a newly created page did not exist yet. In my fresh installation, the directory was only created after an attachment had been uploaded to the page.
So I opened the page's Attachments menu and uploaded a harmless file such as dummy.txt. This initialized the attachment directory that the DataTable functionality expected to use.
I then returned to the page and tried the same traversal payload again.
This time, it worked.
Using the following payloads, I was able to traverse outside the page's attachment directory and read both Otter Wiki's configuration file and the system's /etc/passwd file.
# Config File Disclosure - Test
{{datatable
|src=../../settings.cfg
|header=false
}}
# System File Disclosure - Test
{{datatable
|src=../../../etc/passwd
|header=false
}}
Note: For /etc/passwd, I tested multiple traversal depths to determine the correct path. The payload shown above includes only the traversal level that successfully reached the file.
After saving and rendering the page, the contents of the referenced files were displayed through the DataTable output.
At this point, it was clear that the DataTable src value could be abused with ../ sequences to escape the intended attachment location and access files elsewhere on the filesystem. What initially looked like a simple file-embedding feature had turned into an arbitrary local file disclosure vulnerability which available to a low-privileged user with page editing and attachment upload permissions.
Disclosure Timeline
- August 2, 2026, 02:28 AM: Vulnerability reported to the Otter Wiki maintainer
- August 2, 2026, 01:52 PM: The maintainers accepted the report.
- August 2, 2026, 02:49 PM: The issue was patched and Otter Wiki 2.22.2 was released. I was credited in the v2.22.2 release notes.
- I asked whether they wanted to request a CVE, but the maintainer preferred not to create additional noise around the issue. I respected that decision and did not request a CVE from my side.
- August 3, 2026: The report was closed.
The overall disclosure process was very fast. The maintainers reviewed the issue and released a patched version within hours.
