Base Docker images ship git 1:2.39.5-0+deb12u2 (CVE-2025-48384, CISA KEV) — fix is already available upstream, just needs a base-image rebuild

Summary

The front, server (transactor), and rekoni runtime images published under hardcoreeng/* currently ship a version of git affected by CVE-2025-48384 (incomplete carriage-return sanitization in .gitmodules path handling, allowing arbitrary file write / RCE via git clone --recurse-submodules against a crafted repository with a symlinked .git/hooks path). This CVE was added to CISA's Known Exploited Vulnerabilities (KEV) catalog on 2025-08-25 as actively exploited in the wild.

What we found

Scanning the currently published images:

Image	git version found	Fixed in
hardcoreeng/front:v0.7.423	1:2.39.5-0+deb12u2	1:2.39.5-0+deb12u3
hardcoreeng/transactor:v0.7.423	1:2.39.5-0+deb12u2	1:2.39.5-0+deb12u3
hardcoreeng/rekoni-service:v0.7.423	1:2.39.5-0+deb12u1	1:2.39.5-0+deb12u3

The same vulnerable versions are present identically in v0.7.432, the newest tag currently published (checked directly via image inspection) — there is no newer released version that already fixes this.

Root cause

dev/base-image/base.Dockerfile, dev/base-image/front.Dockerfile, and dev/base-image/rekoni.Dockerfile all build FROM node:22 (the full/non-slim Debian 12 "bookworm" Node image), which inherits git, git-man, and other buildpack-deps tooling. These three Dockerfiles are unchanged between v0.7.423, v0.7.432, and current main — no fix has landed. The last time the hardcoreeng/base / front-base / rekoni-base images were rebuilt and re-tagged appears to be around 2025-09-16 (v20250916, introduced in #9854/#9855/#9874), roughly a year before this report; nothing since has bumped that pin.

The other 10 published component images (account, calendar, collaborator, fulltext, github, gmail, hulykvs, stats, telegram, workspace) build FROM hardcoreeng/base-slim, which is based on node:22-slim and never had git installed in the first place — those are unaffected.

The fix is trivial and already available — no waiting on Debian

• Debian's security tracker lists CVE-2025-48384 as fixed for bookworm at 1:2.39.5-0+deb12u3, already shipped in the regular bookworm package suite (not stuck behind a future point release).
• We confirmed a fresh docker pull node:22 today already includes git 1:2.39.5-0+deb12u3 — the patched version — because Docker's official Node image tracks Debian's bookworm archive on an ongoing basis.
• In other words: no Dockerfile code change is required. Simply rebuilding hardcoreeng/base, hardcoreeng/front-base, and hardcoreeng/rekoni-base from dev/base-image/*.Dockerfile against a fresh node:22 pull today, re-tagging (e.g. v20260825 or similar), bumping the version pin referenced in pods/server/Dockerfile, pods/front/Dockerfile, and services/rekoni/Dockerfile, and rebuilding/republishing those three app images would resolve this.
• We also test-checked that force-upgrading just the git/git-man packages inside the current front, transactor, and rekoni-service images (apt-get install -y --only-upgrade git) is a clean, self-contained bump with zero additional installs/removals and no dependency conflicts — so even a narrower one-line patch layer on top of the existing images would be low-risk if a full base-image rebuild isn't convenient right away.

Ask

Could the base images be rebuilt against current Debian package indices and republished (with a corresponding patch release of front, transactor/server, and rekoni-service)? Given how stale the v20250916 base-image pin now is, it might also be worth adding a periodic (e.g. monthly) rebuild of the dev/base-image/* images to CI so base OS packages don't drift this far again.

Happy to open a PR bumping the base-image tag references if that's useful — let me know.

---

Note: none of the three affected services (front, transactor, rekoni) were found to invoke git clone/checkout against externally-supplied repository content in their source — git is present only as an inherited base-image artifact, not something the application code calls. This report is about image hygiene / CVE-scanner noise, not a claim of an active exploit path in Huly itself.