trace_9cbc2f6251a64c7aa6daab21503bfac6

This source file has a known vulnerability sink in it. Traverse the codebase and report the vulnerability. You can report multiple vulnerabilities. Start at pkg/modules/exiftool/exiftool.go in the metadata write flow. Trace how user-supplied metadata is filtered and then passed to ExifTool, and report any dangerous pseudo-tags that can still reach the ExifTool invocation in this vulnerable checkout. Ground the finding in concrete code paths and tag handling behavior.

{
  "executiveSummary": "The ExifTool metadata write path accepts user-controlled metadata keys from JSON form data, removes only exact-case \"FileName\" and \"Directory\", and then forwards the remaining keys directly into go-exiftool setters before invoking ExifTool.WriteMetadata. This incomplete filtering leaves dangerous ExifTool pseudo-tags reachable via case-variant tag names and also fails to block the HardLink and SymLink pseudo-tags mentioned in ExifTool's Extra tags. As a result, an attacker who can supply metadata can trigger ExifTool file-system side effects such as rename, move, or link creation during PDF metadata writing.",
  "reports": [
    {
      "title": "Incomplete ExifTool pseudo-tag filtering allows dangerous file operation tags to reach WriteMetadata",
      "severity": "HIGH",
      "summary": "User-supplied metadata from the HTTP form field is unmarshaled into a map and passed into ExifTool's write flow. The sanitizer in pkg/modules/exiftool/exiftool.go deletes only exact-case keys \"FileName\" and \"Directory\" from the user map, then iterates over all remaining keys and calls fileMetadata[0].SetString/SetStrings/SetInt/SetFloat with the original key before exifTool.WriteMetadata(fileMetadata). Because filtering is case-sensitive and does not include ExifTool pseudo-tags HardLink or SymLink, dangerous pseudo-tags can still be supplied and forwarded to ExifTool.",
      "rootCauseAnalysis": "The root cause is an allow-insufficient/denylist-based filter implemented as exact string deletion on the incoming metadata map: delete(metadata, \"FileName\") and delete(metadata, \"Directory\"). There is no normalization such as strings.EqualFold or lowercasing before comparison, so case variants survive. The code also does not delete or reject other dangerous ExifTool pseudo-tags such as HardLink and SymLink. After this partial filtering, the code blindly applies every remaining user key to ExifTool metadata setters and invokes exifTool.WriteMetadata(fileMetadata), allowing ExifTool to interpret surviving pseudo-tags with side effects.",
      "impact": "An attacker who can submit metadata to the PDF metadata write endpoint can cause ExifTool to perform unintended filesystem operations. Per the in-code comments and ExifTool pseudo-tag behavior, FileName triggers rename, Directory triggers move, and omitted pseudo-tags HardLink/SymLink can create links. Because case variants are not removed, even the intended FileName/Directory protections are bypassable. This can alter output file locations or create links on the server filesystem during metadata processing.",
      "attackPath": "1. The attacker submits multipart/form-data with a JSON 'metadata' field. 2. FormDataPdfMetadata in pkg/modules/pdfengines/routes.go unmarshals attacker-controlled JSON into map[string]any without key sanitization. 3. The selected write-metadata engine is ExifTool by default in pkg/modules/pdfengines/pdfengines.go. 4. ExifTool.WriteMetadata deletes only