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.

[imc67]

@girish a concrete follow-up to the layer discussion above, because I ran into a case where the "shared base gets old" effect matters more than the usual medium CVEs.

Ubuntu fixed a critical Ghostscript bug on 21 September (CVE-2026-39919, CVSS 9.8, a crafted PDF with a JPEG 2000 image can run code; USN-8791-1, fixed in 10.06.0~dfsg-3ubuntu1.1 on 26.04). On my servers the fix is in some images and not in others, also in images that were built weeks after the fix:

Image (build date)	Ghostscript
Nextcloud (16 Oct), Paperless-ngx (19 Oct), LAMP	10.06.0~dfsg-3ubuntu1.1 (fixed)
WordPress Developer (7 Oct), FreeScout (17 Oct), EspoCRM, HumHub, LimeSurvey, Matomo	10.06.0~dfsg-3ubuntu1
Roundcube, YOURLS, AdGuard Home (24.04)	10.02.1~dfsg1-0ubuntu7.8 (fix is 7.9)

The difference seems to be the shared PHP layer (the sury PHP_SERIES step with Imagick), which in these images was built on 20 September, one day before the fix. Apps that install Ghostscript again in their own layer (Nextcloud does apt-get install ghostscript ...) get the current version; apps that rely on the shared layer keep the old one, even when the app itself is rebuilt later.

For most of these apps it doesn't matter much, because they never feed a PDF to ImageMagick. WordPress is the exception: the policy.xml in the image allows PDF (the restrictive lines are in commented-out examples), and WordPress renders a preview for every PDF uploaded to the media library. I checked it in the container: a PDF read through Imagick goes straight to Ghostscript. So anyone with upload rights on a site (author and up) can reach it. Not anonymous, but on a platform with many editors that's still a real path.

This fits nicely with what you said about sharing layers: refreshing that one shared PHP layer when Ubuntu ships a fix for something in it would fix all of these apps at once, without each app needing its own upgrade step. Is there a cadence or trigger for rebuilding those shared layers, or is it tied to app releases for now?

For anyone who wants to close the WordPress path in the meantime: returning an empty array from the fallback_intermediate_image_sizes filter stops WordPress from rendering PDF previews, so uploads never reach Ghostscript (you only lose the PDF thumbnail in the media library).

[huehner]

Hi @imc67 ,
that concrete case (ghostscript in images on top of php-base) should get indirectly fixed by the php fixes being in progress right now.
I see new php-base docker images are already uploaded https://hub.docker.com/r/cloudron/php-base (with phpXX-20261021)
As that did trigger a new docker build for php-base it should have also picked up the updated ghostscript in that image.
I didn't check inside as busy with the php updates elsewhere if i'm not mistaken that would be in there.
It still requires to bump + rebuild all the app images using php-base to use that but that will likely happen anway to get the php fixes into them.

For your general question what i've seen so far i.e. moving things from 5.1.0 -> 6.0.0 base-image that change alone didn't trigger active upload of all apps. But it was published next time the app was updated itself later.

Using roundcube example. In the packaging git repo the dump to newer php-base was pushed a while ago but not yet published as an app update. Yesterday roundcube app itself got updates which then gets rolled out including the base image change.

For your question on general timing on updates for those shared layers that only people from cloudron can answer. I'm just another random user here

But let's wait on that as just today they will be super busy with the php updates and probably answering lots and lots of duplicate questions on that.

[imc67]

@huehner thanks, I checked it: cloudron/php-base:8.5-20261021 indeed ships ghostscript 10.06.0~dfsg-3ubuntu1.1, which is the fixed version for CVE-2026-39919 on resolute (the 20260920 image had ubuntu1). So the PHP rebuilds take care of this one as a side effect. Agreed, the general timing question can wait until the PHP dust has settled.