Bundled exiv2 DLL statically links zlib 1.2.11 (January 2017)

Hello — and first, some history I should own rather than skip past.

I raised #1972 here previously and I was wrong: I suggested SHA-pinning an action reference that was a deliberately maintained release branch. So I'd understand a degree of scepticism. I've tried to be more careful this time, and I've written down explicitly what I did not establish.

What I observed

QuickLook.Plugin/QuickLook.Plugin.ImageViewer/ commits prebuilt exiv2 binaries — exiv2-ql-64.dll (2.4 MB) and exiv2-ql-32.dll (2.1 MB) — referenced from MetaProvider.cs and the plugin's .csproj.

Those DLLs statically link zlib, and zlib writes its own version banner into the binary:

$ strings exiv2-ql-64.dll | grep -iE 'inflate|deflate'
deflate 1.2.11 Copyright 1995-2017 Jean-loup Gailly and Mark Adler
inflate 1.2.11 Copyright 1995-2017 Mark Adler

zlib 1.2.11 is from January 2017. Current is 1.3.1.

The advisories in that range

What I did NOT establish — and it matters for both

Neither CVE is shown to be reachable here, and I'm not claiming either is exploitable.

• CVE-2022-37434 — NVD notes it applies only to applications that call inflateGetHeader. I did not determine whether exiv2 ever calls that. If it doesn't, this one simply doesn't apply.
• CVE-2018-25032 — that's the deflate (compression) path. QuickLook previews images, which is mostly a read path; whether exiv2 compresses during metadata handling I did not establish.

What I think is fair to say: a nine-year-old zlib ships inside a plugin whose job is parsing untrusted image files, and nothing in the project's tooling can see it.

Why it's invisible

zlib here is statically linked inside another prebuilt binary. There's no manifest entry for exiv2, let alone for the zlib within it. Dependabot has nothing to read, no source scanner parses a PE binary, and the version is only recoverable by running strings and recognising zlib's copyright banner.

I also could not determine exiv2's own version — the binary exposes zlib's banner but no clean exiv2 version string — so I can't tell you how old the exiv2 itself is.

Suggestion

Rebuilding the bundled exiv2 against a current zlib (1.3.1) would close it. That's regenerating a binary rather than editing a manifest, which is precisely why it went unnoticed — no criticism intended.

Disclosure: AI-assisted (Claude Opus 5). I read the version banner out of the committed DLL, confirmed the plugin references, and fetched both CVEs from NVD myself before posting.

Start in QuickLook.Plugin/QuickLook.Plugin.ImageViewer/, especially MetaProvider.cs and the plugin's .csproj, to trace the committed exiv2-ql-64.dll and exiv2-ql-32.dll. Inspect the DLLs with the shown strings command and determine how they can be rebuilt; done means the bundled binaries use current zlib and their relevant versions and CVE reachability are documented.