Immich•2mo ago

Stale, vulnerable base image being used?

Hi, I noticed that current releases' images have a bazillion vulnerabilities. I looked a little closer and did a dev build which is using a base image that is built on a stale and unpatched debian 13:

│ ghcr.io/immich-app/base-server-dev:202508191104@sha256:0608857ef682099c458f0fb3- │  debian  │      6602       │    -    │
│ 19afdcaf09462bbb5670b6dcd3642029f12eee1c (debian 13.0)                           │          │                 │         │

(trivy) I rebuilt the base image myself and all the vulns are gone. Is something stuck in your CI/CD so it's not building vs a recent patched base?

31 Replies

Immich•2mo ago

:wave: Hey @badcatwillum, Thanks for reaching out to us. Please carefully read this message and follow the recommended actions. This will help us be more effective in our support effort and leave more time for building Immich :immich:. References - Container Logs: docker compose logs docs - Container Status: docker ps -a docs - Reverse Proxy: https://immich.app/docs/administration/reverse-proxy - Code Formatting https://support.discord.com/hc/en-us/articles/210298617-Markdown-Text-101-Chat-Formatting-Bold-Italic-Underline#h_01GY0DAKGXDEHE263BCAYEGFJA Checklist I have... 1. :ballot_box_with_check: verified I'm on the latest release(note that mobile app releases may take some time). 2. :ballot_box_with_check: read applicable release notes. 3. :ballot_box_with_check: reviewed the FAQs for known issues. 4. :ballot_box_with_check: reviewed Github for known issues. 5. :ballot_box_with_check: tried accessing Immich via local ip (without a custom reverse proxy). 6. :ballot_box_with_check: uploaded the relevant information (see below). 7. :ballot_box_with_check: tried an incognito window, disabled extensions, cleared mobile app cache, logged out and back in, different browsers, etc. as applicable (an item can be marked as "complete" by reacting with the appropriate number) Information In order to be able to effectively help you, we need you to provide clear information to show what the problem is. The exact details needed vary per case, but here is a list of things to consider: - Your docker-compose.yml and .env files. - Logs from all the containers and their status (see above). - All the troubleshooting steps you've tried so far. - Any recent changes you've made to Immich or your system. - Details about your system (both software/OS and hardware). - Details about your storage (filesystems, type of disks, output of commands like fdisk -l and df -h). - The version of the Immich server, mobile app, and other relevant pieces. - Any other information that you think might be relevant. Please paste files and logs with proper code formatting, and especially avoid blurry screenshots. Without the right information we can't work out what the problem is. Help us help you ;) If this ticket can be closed you can use the /close command, and re-open it later if needed.

badcatwillumOP•2mo ago

My trivy sees 422 vulns in the current immich-server:release image. Seeing as you've got real horrors in the dev base image like the liblzma xz backdoor (CVE-2024-3094 that nearly gave me a heartattack last year), I worry that you're at risk of supply chain attacks. I know that an idiot with a scanner just screaming is annoying, and I would offer to fix vulns, but they seem to be fixed upstream and I don't know your CI well enough to say why the fixes aren't being included in releases.

Mraedis•2mo ago

Feel free to make a report and PM it to me/an admin and I'll see what's going on 🙂 I had assumed the pipeline pulled in updates but I've never looked at it myself 👀

bo0tzz•2mo ago

The base image we use is node:22.18.0-bookworm-slim and we definitely get updates for that, as recently as 2 weeks ago Scanners like this often pull in everything and the kitchen sink, with little to no bearing on whether they're actually even remotely relevant Like the flagged xz version, I don't know where that is coming from in this case but it might very well be something like an entirely unused 'system' package in the base image that is not involved in anything

Mraedis•2mo ago

https://hub.docker.com/layers/library/node/22.18.0-bookworm-slim/images/sha256-0d130e2ee18e88e1561375276daced6bff032539200173f2daf48c2e33f38ff5 they even list the vulnerabilities

bo0tzz•2mo ago

Just an arbitrary selection out of the highest sev findings in the Immich image

curl: heap based buffer overflow in the SOCKS5 proxy

Not used at all

libexpat: Integer Overflow or Wraparound

Not used

gnome: heap memory corruption on gdk-pixbuf

That's a desktop env lmao

krb5: GSS message token handling

Kerberos auth stuff; not used I also notice there are a lot of duplicates, like there's a set of some 10 krb5 issues and that set is repeated 6 times or so That'll quickly inflate the numbers lmao

badcatwillumOP•2mo ago

Scanners like this often pull in everything and the kitchen sink, with little to no bearing on whether they're actually even remotely relevant

I'd look beyond the numbers and look at the high and critical vulns affecting Immich components, for example CVE-2025-8714, SQL execution on restore in postgres.

bo0tzz•2mo ago

If you see any we'd appreciate hearing about it, yes

badcatwillumOP•2mo ago

I wonder if there's a more minimal node image you could use that would reduce the number of false positives?

bo0tzz•2mo ago

Not quite relevant as our recommended restore process doesn't run via the psql in the Immich image

badcatwillumOP•2mo ago

gdk-pixbuf is an image library, it may be used by image processing tools outside the desktop (I haven't looked more closely at which tools you're using, but the gnome project has been very good at pushing their libs down the stack) a different base image is used in the dev build - see server/Dockerfile - and that has even more vulns. So there's a risk of running something when working with that dev build image that pwns your workstations.

Mraedis•2mo ago

We basically use a bunch of very much non-standard image processing libraries; libvips, libsharp, jellyfin-ffmpeg for instance I'm not seeing this different base image for dev?

badcatwillumOP•2mo ago

When I rebuilt the base-server image used in server/Dockerfile, it cleaned up the vulns, do you know why it's not rebuilt in the CI? FROM ghcr.io/immich-app/base-server-dev:202508191104@sha256:0608857ef682099c458f0fb319afdcaf09462bbb5670b6dcd3642029f12eee1c AS dev line 2 of server/Dockerfile (in main)

Mraedis•2mo ago

ah the specific sha tag

badcatwillumOP•2mo ago

yup since it's tagged with a date from a week ago I guess it's being rebuilt sometimes but I haven't figured out why a week old image has 6600 trivy vuln hits.

We basically use a bunch of very much non-standard image processing libraries; libvips, libsharp, jellyfin-ffmpeg for instance

And I guess you're building some of these libs yourself in the base image build to enable features that aren't in the upstream packages

Mraedis•2mo ago

Not sure about that 🙂

badcatwillumOP•2mo ago

😉

bo0tzz•2mo ago

That's correct yes

badcatwillumOP•2mo ago

So the 'release' base image is based on node:22.18.0-bookworm, but in immich-app/server/Dockerfile you're using ghcr.io/immich-app/base-server-dev - is that a modified base image with dev/debug tools?

Daniel•2mo ago

https://github.com/immich-app/base-images/blob/main/.github/workflows/build-server-base.yml#L48-L57 https://github.com/immich-app/base-images/blob/main/server/Dockerfile

Immich•2mo ago

        target: ["dev", "prod"]
    permissions:
      contents: read
      actions: read
      packages: write
    with:
      image: base-server-${{ matrix.target }}
      context: server
      dockerfile: server/Dockerfile
      target: ${{ matrix.target }}

        target: ["dev", "prod"]
    permissions:
      contents: read
      actions: read
      packages: write
    with:
      image: base-server-${{ matrix.target }}
      context: server
      dockerfile: server/Dockerfile
      target: ${{ matrix.target }}

badcatwillumOP•2mo ago

Ic. Does build_and_push run all the time? Sorry if I'm asking dumb questions that could be answered by looking at the GH actions/workflows - I'm more of a gitlab CI guy looks like it runs on any push to main, if i'm reading this correctly Seems it ran on a merge to main yesterday

Daniel•2mo ago

that pawns your workstation

I would love to hear how that'd play out tbh. A dev instance isn't supposed to be exposed to the internet (besides the fact that 99% of the vulnerabilities, if not more, flagged are bs and don't apply)

badcatwillumOP•2mo ago

From server/dockerfile:

d38ab93484 (renovate[bot]   2025-08-19 09:11:49 -0400   2) FROM ghcr.io/immich-app/base-server-dev:202508191104@sha256:0608857ef682099c458f0fb319afdcaf09462bbb5670b6dcd3642029f12eee1c AS dev

I would love to hear how that'd play out tbh

99% of supply chain attacks read like crazy-eyed headcanon until they bite you. Did you follow the liblzma/xz attack last year?

Daniel•2mo ago

Yes, those were machines exposed to the internet

badcatwillumOP•2mo ago

checking my understanding - are you not using those -dev images when developing immich on your workstations (eg via docker-compose.dev.yaml)? That would have internet access, no? Anyhow I'm not asking all these questions just to ride you for having hypothetical vulnerabilities - if I can find a way to fix them I will contribute .

smileBeda•2mo ago

Even if this seems to be a no issue, I feel it would be better not to discuss potential Vulns in public. This is the first step of reporting vulns: responsible disclosure, no matter what. Immich has a security policy and it says

Please report security issues to security@immich.app

I suggest to remove this thread or it’s contents.

Mraedis•2mo ago

They're publically listed in dockerhub, no need to be all secretive

Daniel•2mo ago

Yep, all these vulnerabilities have already been disclosed

smileBeda•2mo ago

I do understand that. I still think it would be better if this sort of would be held less publicly. I’m working with Wordpress a lot and when we see a plugin uses an already disclosed and patched library we don’t tell them in public. That makes that plugin vulnerable for until it’s fixed. We tell them in an email and if no reaction happens the mods of the platform lock the plugin until it’s fixed. It’s just somehow the safer and better way to avoid unwanted stuff.

bo0tzz•2mo ago

This applies to clear exploits & problems in Immich code for sure, but not really to a trivial scanner run like this

Gaming

Programming

Stale, vulnerable base image being used?

Did you find this page helpful?