How tainted metadata reached a dangerous sink
At the heart of the flaw is a classic tainted-data problem: untrusted input flowed into a system-level execution point without proper sanitization. The ExifTool code path that handles macOS file-creation dates maps the Spotlight attribute MDItemFSCreationDate to the internal alias FileCreateDate. When ExifTool iterates tags it assigns the current tag name to $tag and its text content to $val. If $tag matches MDItemFSCreationDate or FileCreateDate, that $val can be passed into the SetMacOSTags function.
Within SetMacOSTags the program built a shell command string ($cmd) and invoked system($cmd). In the vulnerable branch the filename parameter was properly escaped but the date value ($val) was not. Because metadata fields like FileCreateDate are drawn from files, an attacker able to set that field could inject single quotes into $val, break the command syntax and achieve command substitution via system().
The exploitation chain: -n, -tagsFromFile, and DateTimeOriginal
Exploitation required a specific set of steps tied to legitimate ExifTool features. Direct assignment to FileCreateDate is heavily validated by ExifTool’s PrintConvInv filter and rejected when malformed — for example, an invalid date/time produces “Invalid date/time.” But the -n (aka -printConv) flag instructs ExifTool to accept raw values and skip the PrintConvInv conversion step. That allowed an attacker to store unsanitized data in a permissive source tag such as DateTimeOriginal.
The vulnerable SetMacOSTags path is invoked only when metadata is copied into FileCreateDate, not when written directly. Using -tagsFromFile, an attacker can copy a raw, injected DateTimeOriginal into FileCreateDate and trigger the unsafe system() call. The author demonstrated the chain in the lab by first writing a DateTimeOriginal containing a single-quote payload with -n, then running:
cp evil_benign.jpg pwn.jpg; ../../exiftool -n -tagsFromFile evil_benign.jpg "-FileCreateDate<DateTimeOriginal" pwn.jpg
On macOS (Darwin), ExifTool uses /usr/bin/setfile when copying creation dates; the constructed command was executed via system() using the injected $val, demonstrating arbitrary command execution as the invoking user.
Impact: local command execution and realistic attack scenarios
Successful exploitation runs arbitrary shell commands with the privileges of the user invoking ExifTool. The Kaspersky write-up warns such an image can look benign and “easily find its way into a newsroom or any organization that processes photos on macOS using ExifTool.” Once processed, an attacker could deploy a trojan, exfiltrate data, drop additional malware, or use the compromised machine as a foothold to move laterally within a network.
How the maintainer fixed it in version 13.50
The maintainer addressed the flaw in ExifTool version 13.50 by removing reliance on manual shell-escaping and by switching to argument-list system calls. Previously the code concatenated a shell command string such as:
$cmd = "/usr/bin/setfile -d '${val}' '${f}'"; system $cmd;
The patched code invokes system with an argument list: system('/usr/bin/setfile', '-d', $val, $file); and introduces a System() wrapper to preserve the previous behavior of redirecting output to /dev/null while calling system with a list of arguments. Moving from a single concatenated string to a list-based call eliminates shell interpretation of $val and thereby closes the command-injection vector.
What this means for technologists, asset managers, and newsrooms
- Technologists and security teams: Verify all macOS photo-processing endpoints are running ExifTool 13.50 or later and scan for embedded or vendored copies of older ExifTool libraries in asset-management platforms and scripts.
- Asset managers and procurement leaders: Treat ExifTool as a supply-chain component: ensure third-party products and plugins that handle images do not ship older ExifTool versions, and consider continuous monitoring of open-source components.
- Newsrooms and media organizations: Isolate processing of untrusted images on dedicated machines or virtual environments with tightly limited network and storage access, and require devices connecting to corporate resources to run an active macOS security solution.
ExifTool users on macOS should update to 13.50 or later and audit any automation, embedded libraries, or third-party tools that might include older ExifTool code. Kaspersky’s advisory recommends using the Kaspersky Open Source Software Threats Data Feed for supply-chain monitoring and Kaspersky for macOS for endpoint protection; it also repeats a core engineering lesson: replace fragile string concatenation with list-based API calls to remove shell interpretation risks.
