When a File Converter Can Read the Server's Own Files
In October 2026 a security researcher disclosed a bug in a self-hosted file-conversion app called ConvertX. The flaw, tracked as CVE-2026-108694, is the kind that makes anyone who runs a converter wince: by uploading one ordinary-looking document, a user could trick the service into handing back the contents of private files sitting on its own server.
The project has since shipped a fix, and this is not a post about one app getting it wrong. It is about a trap that every file converter walks near, because the whole job of a converter is to open files that strangers send it. Understanding this one bug tells you most of what you need to know about whether a conversion tool is safe to trust.
What went wrong, in plain terms
Some document formats have a built-in feature that says, in effect, "paste the contents of this other file right here." It is genuinely useful when you are assembling a report from several pieces that you wrote. It becomes a weapon the moment the person writing the document is an attacker and the "other file" is one of the server's own secrets.
That is exactly what happened. The converter accepted a document format that supports an include instruction, and ran the conversion without sealing it off from the rest of the machine. So an attacker could upload a document that essentially said:
include the file at /etc/passwd
Convert it, download the result, and the output came back containing the contents of that server file. Swap the path and the same trick could reach a configuration file full of passwords, a private key, or the application's own source code. No break-in, no password guessing - the feature simply did what it was told, pointed at the wrong target.
Why this keeps happening to converters
A file converter is in a uniquely exposed position. A calculator app never has to open a hostile file. A converter does it all day, on purpose. And the powerful libraries that read complex formats are full of helpful features - include other files, fetch a web address, follow a link, run an embedded instruction - that are a gift to the author and a loaded gun in the hands of an attacker.
This same shape shows up again and again under different names: a drawing file that quietly reads a system file, a web page that reaches an internal address while being turned into a PDF, a spreadsheet that phones home through a linked image. Different formats, identical lesson: a tool that opens strangers' files must assume every file is trying to escape.
The real fix is not a single setting
The affected app patched the bug the direct way - a one-line switch that tells the conversion step to run in a restricted mode. That is the right thing to do, and if you run that app, updating closes the hole.
But a single switch, for a single tool, for a single format, is a fragile kind of safety. The next format added, or the next tool wired in, has to remember it all over again. The sturdier answer is to stop relying on each feature behaving and instead make misbehaviour pointless. A converter that is built properly does three things at once:
Seal off each job
Every conversion runs in its own locked room that can see only the file you handed it - not the server's files, not its secrets, not anyone else's upload.
Cut the network
The conversion has no way to reach the internet or any internal address, so a file that tries to "phone home" or pull a remote resource finds no road to travel.
Keep nothing
Files are processed and then erased, with no stored copies and no content logs - so there is nothing lingering to leak later.
The point of stacking them is that no single mistake is fatal. If one layer is misconfigured, the next still has to be defeated. A forgotten switch becomes a non-event instead of a breach.
How we think about it at topriv
Our own file converter, PrivConvert, is built on exactly this assumption: the file is hostile until proven otherwise. Every conversion runs inside its own isolated sandbox with no access to the server's files, no stored credentials, and no network, and your file is processed in memory and erased the instant the job is done. A document that tries to include a server file, or reach an address it should not, simply finds that the door and the road are not there.
We have written before about why this matters - why the libraries behind converters attract so many security fixes, and how we isolate every single conversion. This latest CVE is a textbook example of the problem both of those posts describe.
A switch you have to remember protects you until the day you forget. A sealed room protects you even then.
What it means if you convert files online
You should not have to audit anyone's code to stay safe. But it is worth knowing what separates a tool that takes this seriously from one that does not:
A converter that cuts corners
Runs conversions with free run of the server, keeps your uploads around, and trusts each file to behave. One clever document can reach far beyond its own contents.
A converter that is built right
Seals off every job with no files, no secrets and no network, and erases your upload when done. A hostile file lands in an empty room with no way out.
Bugs like CVE-2026-108694 will keep appearing, because opening untrusted files is hard and the features that cause them are often useful by design. The tools worth trusting are the ones where a flaw like this lands in a sealed, empty room - a patch note, not an incident.
Convert files the private way
Every job sealed off, no network, no stored files. Your upload is processed in memory and erased when done.
Try PrivConvert →topriv builds privacy-first digital tools. Follow us on X, Telegram, YouTube, and TikTok.