GHSA-cw26-7653-2rp5

Impact

exiftool-vendored starts ExifTool in -stay_open True -@ - mode, where arguments are read from stdin one per line. In affected versions, several caller-supplied strings were interpolated into ExifTool arguments without rejecting line delimiters. A newline or carriage return inside one of those strings could split a single intended argument into multiple ExifTool arguments, allowing argument injection. The fix also rejects NUL bytes as unsafe control characters.

Applications that pass attacker-controlled strings to affected APIs may allow an attacker to make ExifTool read files accessible to the ExifTool process, or write output to attacker-chosen file system paths accessible to that process. No remote code execution has been demonstrated.

The reported write-path issue is caused by unsanitized tag keys. Tag values passed to ExifTool#write are not affected, because WriteTask already encodes whitespace characters in values (e.g. \n -> 
) before transmission.

Confirmed affected inputs:

• Tag-name arguments / tag keys — keys of the tags object passed to ExifTool#write; entries of the retain option to ExifTool#deleteAllTags; entries of the numericTags option to ExifTool#read; the tagname argument to ExifTool#extractBinaryTag and #extractBinaryTagToBuffer.
• Filename / path arguments to ExifTool#write, #read, #readRaw, #deleteAllTags, #rewriteAllTags, #extractBinaryTag, #extractBinaryTagToBuffer, and the binary-extraction convenience methods #extractJpgFromRaw, #extractPreview, and #extractThumbnail. path.resolve() does not strip newlines, so an application that accepts attacker-controlled filenames containing newline characters was vulnerable.
• The imageHashType option to ExifTool#read. TypeScript types restrict this to a literal union, but JS callers or callers with weakened type checking could reach the sink.

Applications that only pass hardcoded strings for tag names,...