# Unfixed CRITICAL and HIGH findings we ship knowingly. # # Read with .trivyignore, which does the opposite job. That file hides findings # that are absent from the artifact. This one keeps findings that are PRESENT # and have no upstream fix visible: the release scan still reports every ID # below in the job summary and in the published JSON report, it just does not # fail the build on them. Anything not listed here does fail. # # The release workflow's blocking scan uses ignore-unfixed, which is right for # what it gates (a fix exists and we did not take it) and blind to everything # here. Without this file the count of unfixed findings in a shipped image was # structurally zero. # # Adding an entry means claiming three things and writing down the evidence: # the finding is present, no fix exists in any channel we can consume, and you # have checked whether user input can reach the vulnerable code. Re-check on # every release. Removing the cause beats adding a line. # # Every entry below is Debian 12 (arm64). amd64 is on Ubuntu 24.04 and carries # NONE of them: a full scan of the 2.2.0 amd64 image reports zero unfixed # CRITICAL and zero unfixed HIGH. So the amd64 release jobs report this whole # list as absent, and the arm64 base is the single cause of every line here. # Moving arm64 to Ubuntu 24.04 deletes this file. See IMG-20260726-005. # # Verified against the real 2.2.0 arm64 image rather than inferred from the # Dockerfile: package presence by dpkg-query, load paths by LD_DEBUG=libs and # readelf DT_NEEDED, reverse dependencies by apt-cache rdepends --installed, # and fix availability by apt-cache policy plus the Debian security tracker. # # What was fixed rather than listed, in this pass: # libraw20/libraw-bin removed with the apt entry in #649; LibRaw 0.22.2 is # built from source and is the only copy in the image. # libde265 1.1.1 built from source and loaded in place of Debian's # 1.0.11, so the HEVC decoder that actually receives an # attacker's .heic bitstream is the fixed line. # libheif pinned build moved 1.21.2 to 1.23.1; the old pin was # itself listed as affected by CVE-2026-3950. # xvfb, wget, purged. 12 packages and 14 findings gone, each verified # openssh-client by dry-run to take nothing else with it. # --------------------------------------------------------------------------- # Reachable from a user upload. These are the ones that matter. # --------------------------------------------------------------------------- # OpenEXR 3.1.5. ImageMagick's exr.so coder links libOpenEXR-3_1.so.30, and an # .exr upload reaches it through decodeExr (apps/api/src/lib/format-decoders.ts), # so a malformed EXR gets to the vulnerable parser. Confirmed with LD_DEBUG=libs # convert sample.exr. /usr/bin/djxl links OpenEXR too, so every .jxl decode also # initialises it, though only the JXL parser touches those bytes. # # This entry used to list three IDs. The tracker now has sixteen open against # bookworm's 3.1.5 and ten are unfixed in sid's 3.4.6 as well, so a base bump # does not clear them either. Trixie's 3.1.13 would clear CVE-2023-5841 and # CVE-2025-64181 but not the 2026 batch. # # The library arrives as a dependency of libmagickcore-6.q16-6-extra and of # libjxl-tools. Removing it means dropping the EXR coder, which takes .jxl # support with it because they share libmagickcore-6.q16-6-extra. That is a # product decision about two accepted upload formats, not a hardening one, so # it is filed rather than done. Re-check when Debian or upstream ships a fix. CVE-2023-5841 CVE-2025-12495 CVE-2025-12839 CVE-2025-12840 CVE-2025-64181 CVE-2026-27622 CVE-2026-34379 CVE-2026-34543 CVE-2026-34544 CVE-2026-34545 CVE-2026-34588 CVE-2026-40244 CVE-2026-40250 CVE-2026-41142 CVE-2026-42216 CVE-2026-42217 # expat 2.5.0. LibreOffice's SAX parser is expat: libexpwraplo.so and # libmergedlo.so both carry a direct DT_NEEDED on libexpat.so.1, and every # office-format upload is XML that reaches it through convertDocument # (packages/doc-engine/src/libreoffice.ts). That covers docx, doc, odt, rtf, # xlsx, xls, ods, pptx, ppt and odp across word-to-pdf, excel-to-pdf, # powerpoint-to-pdf, the three convert-* tools and the file preview. A direct # path from an upload to the vulnerable parser, so it is filed as reachable. # # SVG is not that path. Sharp's libvips is statically self-contained and vendors # its own glib, so sanitizeSvg into Sharp never touches distro expat, and # ImageMagick only picks expat up transitively through fontconfig. # Bookworm is at its ceiling with no backport. CVE-2025-59375 CVE-2026-25210 CVE-2026-45186 CVE-2026-56131 CVE-2026-56407 CVE-2026-56408 # libtiff 4.5.0, through LibreOffice. The image pipeline is not the path: Sharp's # libvips is self-contained, Pillow vendors its own libtiff, and ghostscript is # only ever invoked with -sDEVICE=pdfwrite or pnggray, so its TIFF devices are # unreachable. libreoffice-core lists libtiff6 as a Depends, and converting a # document carrying an embedded TIFF loads /lib/aarch64-linux-gnu/libtiff.so.6 # with attacker bytes. Verified with a hand-built docx under LD_DEBUG=libs. # Nothing for bookworm and no backport. Trixie's 4.7.0 clears four of the five # open advisories; CVE-2026-36849 is ignored there too. CVE-2023-52355 CVE-2026-12912 CVE-2026-36849 # libjxl 0.7.0, decoder side. .jxl is an accepted input, jxl is in # CLI_DECODED_FORMATS, and decodeJxl runs djxl on the user's file before falling # back to ImageMagick (apps/api/src/lib/format-decoders.ts), which puts an # attacker's bitstream into libjxl.so.0.7. The encoder side is not exposed: # encodeJxl always feeds cjxl a Sharp-produced PNG. Bookworm ships 0.7.0 with no # backport, and while trixie's 0.11.2 clears this one, the package cannot be # dropped without also dropping the EXR coder they share. CVE-2025-70103 # harfbuzz 6.0.0, quadratic blowup on a crafted font. Two live paths, both # confirmed with LD_DEBUG=libs: a LibreOffice conversion initialises # libharfbuzz.so.0, and WeasyPrint's html-to-pdf and markdown-to-pdf reach it # through pango. The second supplies the font as well as the document: # doc_html_pdf.py blocks remote references but deliberately passes data: URLs to # the default fetcher, so a @font-face carrying a base64 payload in user HTML is # fetched, parsed and subsetted. Bookworm and bookworm-proposed-updates are both # at 6.0.0. Fixed in trixie's 10.2.0. CVE-2023-25193 # python3.11, the distro interpreter. /opt/venv is a venv over /usr/bin/python3 # and /data/ai/venv is a copy of it, so this interpreter runs every AI sidecar # script against user uploads. There is no second interpreter in the image. The # individual defects sit in stdlib modules the sidecars do not obviously call, # but the process is squarely on the upload path, so these are filed here rather # than argued away. Bookworm ceiling, no backport. CVE-2025-69534 CVE-2026-11940 CVE-2026-15308 CVE-2026-3644 CVE-2026-7210 # libxml2 2.9.14, use-after-free on crafted XML, denial of service. Linked into # convert, tesseract and LibreOffice, all of which run on user-supplied files. # No confirmed path from an upload to the affected parser (SVG goes through # Sharp, not ImageMagick's MSVG coder) but it is not ruled out either, so it is # filed as reachable rather than argued away. Debian has deferred the fix. CVE-2026-6653 # --------------------------------------------------------------------------- # A fix exists and we are not taking it. Not the same as unfixable. # --------------------------------------------------------------------------- # curl 7.88.1. bookworm-backports carries 8.14.1-2+deb13u2~bpo13+1 and the # dry-run install is clean, so "no fix in any channel we can consume" would be a # false claim here. We are declining it for this release: a major version jump # on a stable base, pulling in four new packages (libnghttp3, libngtcp2 and # friends), for a library nothing calls with user input. The only runtime curl # invocation is the HEALTHCHECK against http://localhost:1349/api/v1/health. # Outbound HTTP is Node undici (apps/api/src/lib/ssrf.ts) and Python urllib, # never libcurl. # # One caveat that keeps this honest: libmergedlo.so links libcurl-gnutls.so.4 # directly and LibreOffice runs with no network kill switch, so a document # carrying a remote linked image is a plausible route into libcurl's response # handling. Not empirically confirmed. If it is confirmed, take the backport # instead of extending this entry. Re-check next release. CVE-2026-12064 CVE-2026-6276 CVE-2026-8286 CVE-2026-8927 CVE-2026-8932 # --------------------------------------------------------------------------- # Present in a process that handles user input, but the vulnerable code is not # on any path user input can take. # --------------------------------------------------------------------------- # perl 5.36, all via libimage-exiftool-perl. exiftool runs on uploads through # format-decoders.ts, info.ts and edit-metadata.ts, so perl itself is in the # path; these specific defects are not. # CVE-2026-8376 heap overflow compiling regexes, 32-bit builds only. Both # shipped architectures are 64-bit. # CVE-2026-42496 Archive::Tar path traversal. Nothing in the image runs it. # CVE-2026-57433 Storable signed integer overflow, needs untrusted Storable # input to deserialize. Nothing deserializes Storable. # CVE-2026-13221 silently incorrect regex results. A correctness bug, not a # memory-safety one, and NVD's 9.1 does not reflect that. # The 2026-42497, -48962, -57432 and -9538 set is the same shape: defects in # modules exiftool never loads. It is invoked only with -b, -JpgFromRaw, # -PreviewImage and metadata reads, never as a general perl host. CVE-2026-8376 CVE-2026-42496 CVE-2026-57433 CVE-2026-13221 CVE-2026-42497 CVE-2026-48962 CVE-2026-57432 CVE-2026-9538 # glib 2.74. CVE-2026-58016 is the integer underflow in # g_dbus_node_info_new_for_xml and needs attacker-controlled D-Bus introspection # XML. The container runs no broker: the dbus package is not installed, there is # no dbus-daemon, gdbus or /run/dbus socket, the gio modules directory is empty, # and neither gvfs nor dconf-service is present. The 2026-5801x set is the same # GDBus and GVariant family and dies on the same fact. # # Note that libglib2.0-data ships 308 paths under /usr/share and zero shared # objects, so half the rows Trivy reports against this source package carry no # code at all. GLib's string and GObject code does run, through pango, # gdk-pixbuf, ImageMagick, LibreOffice and tesseract, so a future advisory # landing outside GDBus needs its own line rather than this one. CVE-2026-58016 CVE-2026-58010 CVE-2026-58011 CVE-2026-58012 CVE-2026-58013 CVE-2026-58014 CVE-2026-58015 # sqlite 3.40, integer overflow. Needs attacker-controlled SQL. The app is on # Postgres; libsqlite3 is here as a python3 and LibreOffice dependency. CVE-2025-7458 # libssh2 1.10.0. In the image only because Debian's libcurl4 and # libcurl3-gnutls link it for SCP and SFTP, and those are its only reverse # dependencies. Nothing invokes curl with an scp:// or sftp:// URL: the one # runtime curl call is the healthcheck against http://localhost, and # user-supplied URLs go through Node's undici, never libcurl. The vulnerable # transport is never negotiated. No backport. CVE-2026-55199 CVE-2026-55200 CVE-2026-7598 # libcups2 2.4.2. Present twice over, as a Playwright chromium dependency and as # a libreoffice-core and libgs10 one. Both linkers are on the upload path but # neither prints: ghostscript is only ever called with -sDEVICE=pdfwrite or # pnggray under -dSAFER, never the cups device, and LibreOffice runs # --headless --convert-to. Only the client library is installed, with no # cups-daemon and no lp, lpstat or ipptool, so nothing ever opens an IPP # connection. No backport. CVE-2026-34980 # libldap 2.5.13. Consumers are libcurl4, libcurl3-gnutls, libpq5, # postgresql-17, libreoffice-core and dirmngr. Reachable only if something dials # ldap:// or ldaps://. The database URL is a plain postgres:// with no # pg_service LDAP lookup, headless LibreOffice never opens an address book, curl # is only called on http://localhost, and no LDAP client tools are installed # (ldapsearch and ldapwhoami absent, /etc/ldap/ldap.conf has no active # directives). No backport. CVE-2023-2953 # Base-system packages that no application code path touches. gzip has no # installed reverse dependencies at all and the app decompresses in-process # (node:zlib in svg-sanitize.ts, the node tar package in feature-status.ts, # Python tarfile in install_feature.py). ncurses serves bash, readline and # procps in a container with no TTY that never feeds user data to a terminal # library. libacl1 is exercised only by coreutils and tar, on paths the app # itself creates under /tmp/workspace and /data. util-linux ships mount, blkid # and the smartcols table formatter, none of which is invoked with user input. # All at the bookworm candidate with no backport. CVE-2026-41992 CVE-2025-69720 CVE-2026-54369 CVE-2026-53615 # --------------------------------------------------------------------------- # Not loaded or not present at all. These inflate the count and nothing else. # --------------------------------------------------------------------------- # zlib1g, integer overflow in minizip's zipOpenNewFileInZip4_6. Debian does not # build minizip into zlib1g: `dpkg -L zlib1g` ships no minizip file. That is # why the status is will_not_fix. The vulnerable function is not in the image. CVE-2023-45853 # libheif1 1.15.1, shadowed. The Dockerfile builds libheif 1.23.1 into # /usr/local/lib and sets LD_LIBRARY_PATH=/usr/local/lib, which the app # propagates to every child process (execFile inherits it, and the Python # dispatcher passes it explicitly in packages/ai/src/bridge.ts). Verified: # LD_DEBUG=libs heif-dec resolves libheif.so.1 to /usr/local/lib and reports # 1.23.1, and ImageMagick's heic.so resolves the same way. The distro package # stays installed only as a transitive dependency of libmagickcore-6.q16-6 and # cannot be purged without removing ImageMagick. # # `convert -list format` prints HEIC (1.15.1) because that string is baked at # ImageMagick build time. It does not reflect the loaded library. # bookworm-backports has 1.19.7, which is older than what we build. CVE-2025-68431 CVE-2026-32740 CVE-2026-32741 CVE-2026-32882 CVE-2026-41071 CVE-2026-47178 # libde265-0 1.0.11, shadowed. This one used to be genuinely reachable: every # .heic upload goes decodeHeic to heif-dec to libde265, which put an attacker's # HEVC bitstream into Debian's 1.0.11 and its twelve open advisories. The # Dockerfile now builds libde265 1.1.1 from source into the same prefix as # libheif and asserts at build time that libheif linked it, so the copy that # receives those bytes is the fixed line. Verified: ldd on # /usr/local/lib/libheif.so resolves libde265.so.0 to /usr/local/lib. The distro # package remains installed as a dependency of the distro libheif1 and cannot be # purged without removing ImageMagick. CVE-2026-33164 # libaom3, heap overflows on frame size change. The only ELF in the image with a # DT_NEEDED on libaom.so.3 is the distro libheif.so.1.15.1, itself shadowed. Our # libheif is configured WITH_AOM_DECODER=OFF, WITH_AOM_ENCODER=OFF and # WITH_DAV1D=OFF, the /usr/local/lib/libheif plugin directory is empty, and # ffmpeg is a self-contained static binary. LD_DEBUG=libs across the HEIC, AVIF, # JXL, EXR and RAW paths never initialises libaom. AVIF still works because # Sharp's libvips decodes it natively, which is the primary path anyway. # CVE-2023-6879 and CVE-2023-39616 are fixed in trixie; the 2026-562xx set is # vulnerable in bookworm, trixie and sid alike. CVE-2023-6879 CVE-2023-39616 CVE-2026-56208 CVE-2026-56209 CVE-2026-56210 CVE-2026-56211