Listen to this Post
How the mentioned vulnerability works:
The `exiftool-vendored` npm package spawns ExifTool in `-stay_open True -@ -` mode, reading arguments from stdin line by line. In vulnerable versions (before v35.19.0), attacker-controlled strings are interpolated into command arguments without sanitizing line delimiters. A newline (\n) or carriage return (\r) inside a tag name, filename, or option value can split a single intended argument into multiple arguments. This enables argument injection – for example, injecting `\n -o /tmp/out\n` to redirect output. The injection occurs because the library fails to reject control characters before concatenating arguments. Attackers can make ExifTool read arbitrary files accessible to the process or write output to chosen filesystem paths. No remote code execution has been proven. The write-path issue specifically arises from unsanitized tag keys (not tag values, which are encoded). Confirmed affected inputs: tag keys in `ExifToolwrite` (tags object), `retain` options in deleteAllTags, `numericTags` in read, the `tagname` argument to binary-extraction methods, and filenames passed to write/read/delete/rewrite/extract methods. Also the `imageHashType` option (if type enforcement is bypassed). The `path.resolve()` call does not strip newlines, so attacker-controlled filenames with newlines are dangerous. Hardcoded-only strings are safe. The fix in v35.19.0 adds two layers: a `validateTagName` helper that rejects characters outside ExifTool tag grammar (letters, digits, :, -, _, , `?`, `+`,), and `ExifToolTask.renderCommand` rejects any argument containing \r, \n, or `\0` before transmission.
dailycve form:
Platform: `exiftool-vendored npm`
Version: `before 35.19.0`
Vulnerability: `Argument injection via`
Severity: `Medium (file read/write)`
Date: `Not specified in `
Prediction: `Already patched (2023?)`
What Undercode Say:
Check vulnerable version
npm list exiftool-vendored | grep -E 'exiftool-vendored@[0-9]+.[0-9]+.[0-9]+'
Exploit: inject newline into tag key
node -e "const {ExifTool} = require('exiftool-vendored'); const et = new ExifTool(); et.write('./image.jpg', {'Artist\n-o /tmp/pwn.txt': 'injected'}).catch(e=>console.log(e));"
Test unsafe filename
touch $'injected\n-o /tmp/out.txt'
node -e "const {ExifTool} = require('exiftool-vendored'); new ExifTool().read('./injected\n-o /tmp/out.txt').then(console.log);"
Workaround guard (denylist)
function assertSafeForExifTool(s) { if (typeof s !== 'string' || /[\x00-\x20=<>]/.test(s)) throw new Error('Unsafe'); }
Exploit:
Attacker supplies a tag key like `”Artist\n-o /tmp/evil.jpg”` to ExifToolwrite. The newline splits arguments, causing ExifTool to interpret `-o /tmp/evil.jpg` as a separate output option. Similarly, a filename `”picture.jpg\n-exec echo pwned”` (if ExifTool had such options) could inject. No RCE shown, but file read/write paths allow reading sensitive files (e.g., /etc/passwd) or writing to arbitrary locations via -o.
Protection from this CVE:
Upgrade to `[email protected]` or later. If upgrade impossible, reject all control characters (\r, \n, \0, \t) from tag keys, filenames, and option values before passing to the library. Use the conservative regex `/[\\x00-\\x20=<>]/` as a denylist. Prefer allowlist validation for tag names: only allow [A-Za-z0-9:_?+-]. Never pass unsanitized user input to write, read, deleteAllTags, rewriteAllTags, or binary-extraction methods.
Impact:
Successful exploitation allows an attacker to read any file accessible to the ExifTool process (e.g., configuration, credentials) and write output to arbitrary filesystem paths, potentially overwriting critical files or planting malicious metadata. No remote code execution, but combined with other weaknesses could escalate. Applications using attacker-controlled strings for tag keys, filenames, or the `imageHashType` option are vulnerable. Hardcoded strings are safe.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
