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
| CVE |
CVSS |
|
| CVE-2022-37434 |
9.8 CRITICAL |
heap-based buffer over-read/overflow in inflate via a large gzip header extra field. Fixed in 1.2.13 |
| CVE-2018-25032 |
7.5 HIGH |
memory corruption when deflating if the input has many distant matches. Fixed in 1.2.12 |
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.
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) andexiv2-ql-32.dll(2.1 MB) — referenced fromMetaProvider.csand the plugin's.csproj.Those DLLs statically link zlib, and zlib writes its own version banner into the binary:
zlib 1.2.11 is from January 2017. Current is 1.3.1.
The advisories in that range
inflatevia a large gzip header extra field. Fixed in 1.2.13What 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.
inflateGetHeader. I did not determine whether exiv2 ever calls that. If it doesn't, this one simply doesn't apply.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
stringsand 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.