[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f0ycqUk0_KWIzs8-zKomvNUDrH9Gsj4vzATMpWoCSMuk":3},{"article":4,"iocs":43},{"id":5,"title":6,"slug":7,"summary":8,"ai_summary":9,"brief":10,"full_text":11,"url":12,"image_url":13,"published_at":14,"ingested_at":15,"relevance_score":16,"entities":17,"category_id":27,"category":28,"article_tags":32},"a3a0431e-aa7a-467b-836e-6feeb1964541","How an image could compromise your Mac: understanding an ExifTool vulnerability (CVE-2026-3102)","how-an-image-could-compromise-your-mac-understanding-an-exiftool-vulnerability-c-764cd8","We explain how a flaw in ExifTool allows attackers to compromise macOS systems via a malicious image (CVE-2026-3102).","CVE-2026-3102 is a critical vulnerability in ExifTool (version 13.49 and earlier) discovered by Kaspersky's GReAT team that allows attackers to execute arbitrary shell commands on macOS systems by embedding malicious payloads in image metadata. The flaw exploits unsanitized date values in the FileCreateDate tag that flow into a system() function without proper validation. Successful exploitation requires the -n flag and grants the attacker command execution privileges of the invoking user, potentially leading to full system compromise.","ExifTool CVE-2026-3102 allows arbitrary command execution on macOS via malicious image metadata.","Table of Contents IntroductionTechnical detailsDisclaimerTracing the vulnerable sinkFinding an unsanitized date valuePlanning the payload deliveryBypassing the filterTriggering the exploitPatch analysisHow to protect against ExifTool vulnerabilityConclusions Authors Lucas Tay Introduction ExifTool is a widely adopted utility for reading and writing metadata in image, PDF, audio, and video files. It is available both as a standalone command-line application and as a library that can be embedded in other software. In this article, we break down CVE-2026-3102, an ExifTool vulnerability discovered by Kaspersky’s Global Research and Analysis Team (GReAT) in February 2026 and patched by the developers within the same month. Affecting macOS systems with ExifTool version 13.49 and earlier, this flaw could let an attacker run arbitrary commands by hiding instructions inside an image file’s metadata. This investigation originated from revisiting an n-day vulnerability I first examined years ago: CVE-2021-22204. That flaw exploited weak regex-based sanitization before feeding user input into an eval sink. By auditing adjacent input validation routines across ExifTool codebase for similar oversights, I discovered CVE-2026-3102. Successful exploitation of CVE-2026-3102 enables an attacker to execute arbitrary shell commands with the privileges of the user invoking ExifTool, potentially leading to full system compromise. Technical details Disclaimer Exploiting CVE-2026-3102 requires the -n (also known as -printConv) flag and outputs machine-readable data without additional processing. Tracing the vulnerable sink Taint analysis (aka tainted data analysis) allows for the detection of “dirty” data that reaches dangerous locations without validation. In this context, a “sink” is a point or function in a program where data or a parameter marked as “tainted” or originating from an untrusted source (e.g., user input) can affect the program’s behavior. In ExifTool, these functions are eval and system, both of which are capable of executing system commands. While CVE-2021-22204 exploited an eval function as a sink, this vulnerability (CVE-2026-3102) targets the system function. Knowing the vulnerable sink, we needed to trace how user-controlled data reaches it. Below, we break down the details. Finding an unsanitized date value The screenshot above shows where the system() sink resides within the SetMacOSTags function. Tracing backward from system(), we identified the $cmd variable as the source of the executed command. This variable is assembled from three inputs: $file (properly sanitized), $setTags (processed iteratively), and $val (user-controlled and, crucially, left unsanitized in the vulnerable branch). In ExifTool, a tag is a named metadata field. When parsing an image, the utility extracts date and time values from standard EXIF records or macOS filesystem attributes. To handle file creation dates on macOS, ExifTool relies on the Spotlight system attribute MDItemFSCreationDate. Within the program code, this attribute maps to the internal alias $FileCreateDate. These two identifiers govern how the file creation date is stored and applied. This creates a critical link to the vulnerability: when parsing an image, ExifTool iterates through the discovered tags. The current tag’s name is assigned to the $tag variable, while its text content (e.g., a date string) is assigned to $val. The vulnerable code path is triggered only when $tag matches MDItemFSCreationDate or $FileCreateDate. At this point, the tag’s content flows into $val and is passed to the SetMacOSTags function. As shown in the screenshot below, the filename parameter is properly escaped, but the date value ($val) is not. Because the date is extracted directly from file metadata, an attacker can inject quotes into this field. This breaks the command structure and allows the payload to execute via the system() sink. The following screenshots show some of the tags that can be modified. With the vulnerable parameter identified, the next challenge was delivery: how to place our payload into FileCreateDate without triggering early validation? We found the answer in the official documentation. Planning the payload delivery Let’s refer to the documentation to understand how ExifTool handles tag operations and identify a legitimate feature that can be repurposed for exploitation. Specifically, we need to find a way to deliver our payload into the vulnerable FileCreateDate parameter. When looking for macOS-related tags as well as FileCreateDate, we can find the following information: To write or delete metadata, tag values are assigned using –TAG=[VALUE], and\u002For the -geotag, -csv= or -json= To copy or move metadata, the -tagsFromFile feature is used. (You can find the useful info on tag operations above and how it relates under the hood in ExifTool in the dedicated section of the documentation and on the ExifTool description page.) To trigger the vulnerability, we need to copy a string (date format: MM\u002FDD\u002FYYYY) using the -tagsFromFile feature, as this operation invokes the SetMacOSTags function where the unsanitized $val parameter reaches the system() sink. Why copy instead of writing directly? Because the vulnerable code path (SetMacOSTags) is only triggered when metadata is copied into FileCreateDate — not when it is written directly. By using -tagsFromFile, we can prepare a “source” tag (e.g., DateTimeOriginal) that accepts arbitrary values and copy that value into FileCreateDate, thereby invoking the vulnerable function with our controlled input. Furthermore, we want to introduce single quotes (since they are not being escaped in $val). For starters, we can look for date-time tag and copy via -tagsFromFile by searching the EXIF tag table. Direct assignment to FileCreateDate is heavily validated, so we looked for a source tag that accepts raw values and can be copied into the target field. The following snippet shows the beginning of said table. When doing the analysis, I made use of DateTimeOriginal though I believe you can also use CreateDate which is 0x9004 (see the following screenshot). Initial attempts to inject malformed dates failed: ExifTool’s built-in filter rejected the input. To bypass this, we examined how the tool handles raw metadata. Bypassing the filter To confirm that the PrintConvInv filter rejects invalid dates when written directly, I ran the following command, where evil_benign.jpg is a normal JPG with an invalid date time format. We are greeted with the error message: Invalid date\u002Ftime. This requires the time as well. The next screenshot confirms that direct exploitation fails: ExifTool’s date validation detects the malformed input and rejects the change, activating the internal PrintConvInv filter. That said, it is possible to ignore the formatting and use the -n flag which accepts raw values instead of human-readable value. The -n flag skips the PrintConvInv conversion step, which is exactly where input sanitization occurs. This confirmed we could park unsanitized data in a source tag. The final step was to trigger the vulnerable code path by copying that data into FileCreateDate. This means we should now be able to modify the DateTimeOriginal tag with the invalid date time format with an -n flag. Examining the EXIF metadata tag, we can confirm that we can store a raw value without a proper human readable format that ExifTool accepts: Triggering the exploit To inject commands, we have to revisit the single quote injection into this datetime related tag. The following screenshot shows that we have successfully set the datetime metadata with the single quote. With the payload safely stored in a source tag, the next step was to copy it into FileCreateDate, triggering the vulnerable system() call. The next step now is to copy the datetime tag to a file which invokes SetMacOSTags. According to the documentation, this is how we can copy the data from the SRC tag to the FileCreateDate tag as se","https:\u002F\u002Fsecurelist.com\u002Fexiftool-compromise-mac\u002F119866\u002F","https:\u002F\u002Fmedia.kasperskycontenthub.com\u002Fwp-content\u002Fuploads\u002Fsites\u002F43\u002F2026\u002F05\u002F19160550\u002Fexiftools-featured-scaled.jpg","2026-05-20T09:02:31+00:00","2026-05-20T10:00:11.270873+00:00",9,[18,21,24],{"name":19,"type":20},"ExifTool","product",{"name":22,"type":23},"Kaspersky","vendor",{"name":25,"type":26},"macOS Spotlight","technology","80544778-fabb-4dcd-aa35-17492e5dcf4f",{"id":27,"icon":29,"name":30,"slug":31},null,"Vulnerabilities","vulnerabilities",[33,38],{"category":34},{"id":35,"icon":29,"name":36,"slug":37},"574f766a-fb3f-487c-8d2c-0720ae75471b","Zero-day","zero-day",{"category":39},{"id":40,"icon":29,"name":41,"slug":42},"89f78b1c-3503-45a1-9fc7-e23d2ce1c6d5","Malware","malware",[44,48],{"type":45,"value":46,"context":47},"cve","CVE-2026-3102","Critical arbitrary command execution vulnerability in ExifTool affecting macOS systems running version 13.49 and earlier.",{"type":45,"value":49,"context":50},"CVE-2021-22204","Prior ExifTool vulnerability exploiting weak regex-based sanitization in eval sink; similar pattern exploited in CVE-2026-3102."]