Rebuilding an app doesn't pick up Ubuntu security fixes from the base image — an observation and what I do in my own packages

[imc67]

While building a small vulnerability monitor for my own Cloudron servers, I noticed something about the app images that I found interesting, so I thought I'd share it. To be clear upfront: I'm not reporting anything exploitable. These are containers, apps don't run as root, and most of what I found are medium CVEs in tools an app never even calls. So this is about hygiene (and about what security scanners flag), not an emergency.

What I did: I compared the dpkg package lists of the 41 Cloudron images running on my servers (34 apps plus the addon containers like mail, mysql, postgresql, redis, sftp, turn) with Ubuntu's -security pocket, and looked up the fixed CVEs per package via OSV.

What stood out is that an app's OS layer is exactly as old as its base image, no matter when the app itself was built. For example, an app built on 22 September has the same backlog as the plain cloudron/base:5.1.0 from 7 August, because none of the Dockerfiles I looked at run apt-get upgrade and the base itself isn't refreshed.

Base image	Images on my servers	Source packages behind -security	Fixed CVEs still in the image
cloudron/base:5.0.0 (Feb 2025)	8 apps (OnlyOffice, Jellyfin, Pretix, Taiga, MicroBin, IP2Location, Release Bell, IT Tools)	~105	12 high, ~750 medium
cloudron/base:5.1.0 (Aug 2026)	26 apps + all addon images	~36	0 high, ~160 medium
cloudron/base:6.0.0 (Sep 2026)	7 apps	~5	0 high, 34 medium

So in practice the OS layer follows the release rhythm of the app: an app that doesn't get a new upstream version for a while keeps the base of that moment. The 5.0.0 group still contains the fixes for sudo (CVE-2025-32463), git (CVE-2025-48384) and inetutils (CVE-2026-24061), which are on the CISA KEV list. Inside a container that's mostly theoretical, I know, but it's the first thing a scanner or an auditor points at. The addon images are on 5.1.0, e.g. the postgresql addon has 16.14 while 16.15 is in noble-security.

In my own packages I solved it with two lines in the Dockerfile, so every build pulls in the current security fixes:

FROM cloudron/base:6.0.0@sha256:...
ARG BUILD_DATE=unknown
RUN echo "update base packages (${BUILD_DATE})" \
 && apt-get update \
 && DEBIAN_FRONTEND=noninteractive apt-get upgrade -y \
 && apt-get install -y --no-install-recommends <packages> \
 && rm -rf /var/lib/apt/lists/*

and I always deploy with cloudron update --app <domain> --build-arg BUILD_DATE=$(date +%F). The build argument is only there to break the Docker layer cache, otherwise the upgrade step is reused and does nothing. My monitor tells me when an image falls behind -security, and then I simply rebuild. The trade-off is that builds are a bit less reproducible, which I'm fine with for my own apps.

I also noticed that on master several apps already move to date-tagged bases like node-base:24-20260920 and python-base:3.14-20260920, which looks like it's heading in this direction. Is the idea to rebuild those regularly (and then the apps on top)? If so, this more or less solves itself, and I'm curious how you plan to handle it.

Happy to share the scripts if anyone wants to check their own server.

[girish]

The way docker is... the builds are not "reproducible" . Meaning, you and I build with the same instructions, it will give us different images. This breaks the "sharing" between app images. I don't have a solution, just wanted to point that out.

[imc67]

Good point, I hadn't thought about the layer sharing. I measured it: an apt-get upgrade on top of cloudron/base:5.1.0 today is 136 packages and a 677 MB extra layer per image, so with 30 apps that really adds up. On top of 6.0.0 (5 days old) it's only 16 packages and 28 MB.

So for my 7 own apps the per-app upgrade is fine, but for the whole catalog it clearly belongs in the base rather than in every app. If the dated bases (like node-base:24-20260920) get refreshed regularly and apps pick up the latest one when they're rebuilt, the sharing stays intact and the backlog never grows big. The numbers above also show that the older the base gets, the bigger both the security backlog and the upgrade layer become.