Deark - Security information

[This document is a draft. It might be added to the Deark distribution at some point. Last modified or reviewed: 2026-08-16.]

Deark is intended to be generally safe to use with untrusted input files. However, it is written in a language that isn’t memory-safe, and its default mode of operation necessarily has an extremely large attack surface. It undoubtedly has some security flaws.

But Deark is just a hobbyist project, with no real operating budget, and no security response team.

Even if it had memory safety, it could still have security flaws, such as path traversal errors (it could write files where it shouldn’t), confusion related to Unicode filenames, and various denial of service-type errors (infinite loops, excessive resource use, ...).

Even when Deark works as designed, it may behave in an unexpected and disorderly fashion. For example, it might create thousands of output files that you weren’t expecting. A tiny file might decompress to a very large one. Etc.

We don’t want to scare you off from using Deark. Unless you’re exposing it to files that could have been deliberately crafted to attack it, it’s probably fine. We just want to be honest about what to expect.

The owners of the project declare their intention to fix known security issues within a reasonable amount of time. But this is not a promise. And the fix might not trigger an immediate new official binary release. The project does not have the resources to make a new binary release every day, so the fix might be only in the source code for some time.

Tips for using Deark more securely

If you only use Deark to decode old files that predate Deark’s existence, you’re probably pretty safe.
Use suitable command-line options to restrict what Deark will do (see below).
Run Deark in an isolated environment, such as a virtual machine.
Compiling Deark yourself, using a recent version of the source code, is preferred over using the official releases.
If you use Linux, compiling Deark with Fil-C is an excellent idea. That will make it memory-safe. Deark is easy to compile with Fil-C, though it has not yet been extensively tested with it.
This should be obvious, but: Do not connect Deark to a public web server, unless you’re really sure you know what you’re doing.

Command-line options that can improve security

For more information about these options, refer to the “readme” file.

`-zip`	Create only one output file. Greatly reduces the chance of bad behavior, and eliminates path traversal vulnerabilities.
`-onlymods`	Best option for reducing the attack surface, but you have to know the input format, and can break things unexpectedly.
`-m`	Good option for reducing the attack surface, but you have to know the input format.
`-onlydetect`	Similar to `-m`, but errors will be handled differently.
`-disablemods`	Can protect against a known vulnerability, or a high risk module.
`-nodetect`	Can protect against a known vulnerability, or a high risk module.
`-nonames`	Slightly reduces the chance of path-traversal and other filename-related issues.
`-n`	Don’t overwrite existing files.
`-maxfiles`	Limit the number of output files.
`-main`	Don’t extract certain “auxiliary” files.
`-get`	Write only one output file.
`-t`	Use a specfic name for the output file.
`-maxfilesize`	Limit the output file size.
`-maxtotalsize`	Limit the total output size.
`-maxdim`	Limit the size of images.
`-l`	Don’t actually write any files.
`-id`	Don’t actually write any files.

Reporting security issues

Preferably, send reports by email, especially if the vulnerability seems easy to exploit. Using the public bug tracker is, however, not forbidden.

[Back to main Deark page]