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.
Summary
The
front,server(transactor), andrekoniruntime images published underhardcoreeng/*currently ship a version ofgitaffected by CVE-2025-48384 (incomplete carriage-return sanitization in.gitmodulespath handling, allowing arbitrary file write / RCE viagit clone --recurse-submodulesagainst a crafted repository with a symlinked.git/hookspath). 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:
hardcoreeng/front:v0.7.4231:2.39.5-0+deb12u21:2.39.5-0+deb12u3hardcoreeng/transactor:v0.7.4231:2.39.5-0+deb12u21:2.39.5-0+deb12u3hardcoreeng/rekoni-service:v0.7.4231:2.39.5-0+deb12u11:2.39.5-0+deb12u3The 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, anddev/base-image/rekoni.Dockerfileall buildFROM node:22(the full/non-slim Debian 12 "bookworm" Node image), which inheritsgit,git-man, and otherbuildpack-depstooling. These three Dockerfiles are unchanged betweenv0.7.423,v0.7.432, and currentmain— no fix has landed. The last time thehardcoreeng/base/front-base/rekoni-baseimages 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) buildFROM hardcoreeng/base-slim, which is based onnode:22-slimand never hadgitinstalled in the first place — those are unaffected.The fix is trivial and already available — no waiting on Debian
1:2.39.5-0+deb12u3, already shipped in the regularbookwormpackage suite (not stuck behind a future point release).docker pull node:22today already includesgit 1:2.39.5-0+deb12u3— the patched version — because Docker's official Node image tracks Debian's bookworm archive on an ongoing basis.hardcoreeng/base,hardcoreeng/front-base, andhardcoreeng/rekoni-basefromdev/base-image/*.Dockerfileagainst a freshnode:22pull today, re-tagging (e.g.v20260825or similar), bumping the version pin referenced inpods/server/Dockerfile,pods/front/Dockerfile, andservices/rekoni/Dockerfile, and rebuilding/republishing those three app images would resolve this.git/git-manpackages inside the currentfront,transactor, andrekoni-serviceimages (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, andrekoni-service)? Given how stale thev20250916base-image pin now is, it might also be worth adding a periodic (e.g. monthly) rebuild of thedev/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.