Conversation
…8.20.8), - OS packages :- apt-get upgrade patches all available Debian CVEs, - npm bundled (tar, cross-spawn, glob, minimatch) :- Patched inside /usr/local/lib/node_modules/npm/node_modules/, - axios :- Upgraded 1.9.0 → 1.13.6 in package.json, - form-data, jws, flatted, validator, minimatch, undici, tar:- Forced via yarn resolutions, - glob@10.4.5 in @tsoa/cli :- Patched in-place in Dockerfile, - ngrok binary :- Removed from production image (devDependency with vulnerable Go binary), - tar@6.2.1 in app/node_modules :- Removed (only used by node-pre-gyp at install time, not runtime), - File permissions :- chown -R node:node /app + USER node for non-root execution Remaining (no fix available upstream): - zlib1g CRITICAL (CVE-2023-45853) — Debian hasn't released a patch - libc6/libc-bin HIGH (CVE-2026-0861) — status affected, no fixed version yet Signed-off-by: DeepDN <nemadedeepak1111@gmail.com>
📝 WalkthroughWalkthroughThe Dockerfile now uses flexible Node base images with OS-level security updates and manual npm package patching to remediate vulnerabilities. The package.json concurrently bumps axios and expands resolutions to enforce specific versions of transitive dependencies for consistency. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (1)
package.json (1)
69-69: Scope the newresolutionsto the affected parents.The direct
axiosbump is fine, but these unscoped overrides also force newer majors for packages liketar,minimatch, andundiciacross the whole install. Yarn Classic supports selective nested selectors inresolutionsand warns when an override is incompatible with the original request, so it is safer to target the vulnerable parent paths instead of overriding the entire tree. (classic.yarnpkg.com)Also applies to: 117-127
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@package.json` at line 69, The package.json currently pins dependencies globally via top-level "resolutions" which forces newer majors (e.g., tar, minimatch, undici) across the entire tree; narrow those overrides to the specific parent packages that depend on vulnerable versions instead of global selectors. Update the "resolutions" entries to use selective nested selectors that target the affected parents (for example the package names that require tar/minimatch/undici) rather than wildcard or root-level overrides, and ensure the direct "axios" bump stays as-is; apply the same selective-scoping approach to the other entries mentioned (around the block corresponding to lines 117-127) so only the vulnerable dependency chains are constrained.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@Dockerfile`:
- Around line 30-33: The Dockerfile currently uses recursive copy commands
(e.g., the cp -r node_modules/tar $NPM_MODS/, cp -r node_modules/cross-spawn
$NPM_MODS/, cp -r node_modules/glob $NPM_MODS/, cp -r node_modules/minimatch
$NPM_MODS/) which merge into existing target folders and can leave old
vulnerable files behind; change these steps to replace the target directories
atomically by removing the destination first (or moving the source into place)
before copying or by using a single mv or rm -rf $NPM_MODS/<package> && cp -r
node_modules/<package> $NPM_MODS/ pattern for each package (also apply the same
replacement behavior to the similar commands around lines noted 49-50) so the
destination contains only the new package contents.
- Around line 43-52: The Dockerfile currently copies the full builder
node_modules and only removes ngrok/tar, leaving all devDependencies in the
runtime image; change the final image to install only production packages (or
explicitly prune dev deps) instead of copying builder node_modules. Update the
Dockerfile to, in the final stage, either copy package.json/package-lock.json
and run npm ci --omit=dev (or npm prune --production) inside the runtime stage,
or use a multistage approach where builder installs dev deps and outputs built
artifacts while the final stage runs npm ci --omit=dev and then copies built
artifacts; ensure the existing chown -R node:node /app is preserved and remove
the ad-hoc cp/rm steps that try to patch `@tsoa/cli` after copying full
node_modules.
- Line 2: Base image uses Node 18 which reached EOL; update the Dockerfile base
image to a supported LTS. Edit the Dockerfile line "FROM node:18 AS builder"
(and any similar occurrences like "FROM node:22-22" if present) to a supported
LTS tag such as "node:24" (or "node:22" / "node:20" if you prefer maintenance
LTS), ensure any associated tooling or package-lock files remain compatible,
rebuild and run tests to confirm no runtime or dependency breakage, and update
any CI configs that reference the old image tag.
---
Nitpick comments:
In `@package.json`:
- Line 69: The package.json currently pins dependencies globally via top-level
"resolutions" which forces newer majors (e.g., tar, minimatch, undici) across
the entire tree; narrow those overrides to the specific parent packages that
depend on vulnerable versions instead of global selectors. Update the
"resolutions" entries to use selective nested selectors that target the affected
parents (for example the package names that require tar/minimatch/undici) rather
than wildcard or root-level overrides, and ensure the direct "axios" bump stays
as-is; apply the same selective-scoping approach to the other entries mentioned
(around the block corresponding to lines 117-127) so only the vulnerable
dependency chains are constrained.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: f7b22026-25aa-4b17-b05a-2405bc9e5a31
⛔ Files ignored due to path filters (1)
yarn.lockis excluded by!**/yarn.lock,!**/*.lock
📒 Files selected for processing (2)
Dockerfilepackage.json
| @@ -1,5 +1,5 @@ | |||
| # Stage 1: Builder stage | |||
| FROM node:18.19.0 AS builder | |||
| FROM node:18 AS builder | |||
There was a problem hiding this comment.
❓ Verification inconclusive
Node.js 18 end of life EOL date 2025
Node.js 18 reached end-of-life (EOL) on April 30, 2025. It no longer receives updates or security patches from the official Node.js project. As of March 24, 2026, it is past EOL. Commercial extended support is available through partners like HeroDevs (Never-Ending Support) for security patches.
Citations:
- 1: https://nodejs.org/en/about/eol
- 2: Release plan - v18.x Maintenance LTS nodejs/Release#737
- 3: https://nodejs.org/en/about/previous-releases
- 4: https://nodejs.org/en/about/releases
- 5: https://github.com/nodejs/Release/blob/main/schedule.json
Node.js LTS versions supported March 2026
As of March 24, 2026, the Node.js LTS versions that are supported (Active LTS or Maintenance LTS) are v24 (Active LTS, codename Krypton), v22 (Maintenance LTS, codename Jod), and v20 (Maintenance LTS, codename Iron). These are receiving security updates, as confirmed by the March 24, 2026 security releases announcement covering 24.x, 22.x, and 20.x. v25 is Current (not yet LTS), and older even versions like v18 are End-of-Life.
Citations:
- 1: https://nodejs.org/en/about/releases
- 2: https://nodejs.org/en/blog/vulnerability/march-2026-security-releases
- 3: https://nodejs.org/en/about/previous-releases
- 4: https://github.com/nodejs/Release
Move off Node 18; it reached EOL on April 30, 2025.
Node's release schedule shows that v18 reached end-of-life on April 30, 2025, and no longer receives security updates. For a vulnerability-remediation PR, using an EOL runtime leaves the application outside upstream patch support. Move this image to a currently supported LTS release: v24 (Active LTS), v22 (Maintenance LTS), or v20 (Maintenance LTS). (nodejs.org)
Also applies to: 22-22
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile` at line 2, Base image uses Node 18 which reached EOL; update the
Dockerfile base image to a supported LTS. Edit the Dockerfile line "FROM node:18
AS builder" (and any similar occurrences like "FROM node:22-22" if present) to a
supported LTS tag such as "node:24" (or "node:22" / "node:20" if you prefer
maintenance LTS), ensure any associated tooling or package-lock files remain
compatible, rebuild and run tests to confirm no runtime or dependency breakage,
and update any CI configs that reference the old image tag.
| cp -r node_modules/tar $NPM_MODS/ && \ | ||
| cp -r node_modules/cross-spawn $NPM_MODS/ && \ | ||
| cp -r node_modules/glob $NPM_MODS/ && \ | ||
| cp -r node_modules/minimatch $NPM_MODS/ && \ |
There was a problem hiding this comment.
Replace the package directories instead of merging into them.
These cp -r calls merge into the existing package folders rather than replacing them. Files that existed only in the vulnerable version can be left behind, so the result may still be a mixed tree instead of a clean patch.
🔧 Proposed fix
cd /tmp && npm install tar@7.5.11 cross-spawn@7.0.6 glob@10.5.0 minimatch@9.0.7 2>/dev/null && \
NPM_MODS=/usr/local/lib/node_modules/npm/node_modules && \
+ rm -rf "$NPM_MODS/tar" "$NPM_MODS/cross-spawn" "$NPM_MODS/glob" "$NPM_MODS/minimatch" && \
cp -r node_modules/tar $NPM_MODS/ && \
cp -r node_modules/cross-spawn $NPM_MODS/ && \
cp -r node_modules/glob $NPM_MODS/ && \
cp -r node_modules/minimatch $NPM_MODS/ && \
...
- cp -r node_modules/glob /app/node_modules/@tsoa/cli/node_modules/ && \
+ rm -rf /app/node_modules/@tsoa/cli/node_modules/glob && \
+ cp -r node_modules/glob /app/node_modules/@tsoa/cli/node_modules/ && \Also applies to: 49-50
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile` around lines 30 - 33, The Dockerfile currently uses recursive
copy commands (e.g., the cp -r node_modules/tar $NPM_MODS/, cp -r
node_modules/cross-spawn $NPM_MODS/, cp -r node_modules/glob $NPM_MODS/, cp -r
node_modules/minimatch $NPM_MODS/) which merge into existing target folders and
can leave old vulnerable files behind; change these steps to replace the target
directories atomically by removing the destination first (or moving the source
into place) before copying or by using a single mv or rm -rf $NPM_MODS/<package>
&& cp -r node_modules/<package> $NPM_MODS/ pattern for each package (also apply
the same replacement behavior to the similar commands around lines noted 49-50)
so the destination contains only the new package contents.
| # Remove build-time-only packages that contain vulnerabilities and aren't needed at runtime: | ||
| # - ngrok: devDependency with vulnerable Go binary | ||
| # - tar: only used by node-pre-gyp during native module installation (already done at build time) | ||
| # Patch glob inside @tsoa/cli to fix CVE-2025-64756 | ||
| RUN rm -rf /app/node_modules/ngrok \ | ||
| /app/node_modules/tar && \ | ||
| cd /tmp && npm install glob@10.5.0 2>/dev/null && \ | ||
| cp -r node_modules/glob /app/node_modules/@tsoa/cli/node_modules/ && \ | ||
| rm -rf /tmp/node_modules /tmp/package*.json && \ | ||
| chown -R node:node /app |
There was a problem hiding this comment.
This still leaves the rest of the dev toolchain in the production image.
Because Line 40 copies the full builder node_modules, pruning only ngrok and tar still leaves the rest of devDependencies in the runtime image. That keeps unnecessary packages—and their scan surface—inside production. Prefer a clean production-only install or an explicit prune step after the copy.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@Dockerfile` around lines 43 - 52, The Dockerfile currently copies the full
builder node_modules and only removes ngrok/tar, leaving all devDependencies in
the runtime image; change the final image to install only production packages
(or explicitly prune dev deps) instead of copying builder node_modules. Update
the Dockerfile to, in the final stage, either copy
package.json/package-lock.json and run npm ci --omit=dev (or npm prune
--production) inside the runtime stage, or use a multistage approach where
builder installs dev deps and outputs built artifacts while the final stage runs
npm ci --omit=dev and then copies built artifacts; ensure the existing chown -R
node:node /app is preserved and remove the ad-hoc cp/rm steps that try to patch
`@tsoa/cli` after copying full node_modules.
…8.20.8), - OS packages :- apt-get upgrade patches all available Debian CVEs, - npm bundled (tar, cross-spawn, glob, minimatch) :- Patched inside /usr/local/lib/node_modules/npm/node_modules/, - axios :- Upgraded 1.9.0 → 1.13.6 in package.json, - form-data, jws, flatted, validator, minimatch, undici, tar:- Forced via yarn resolutions, - glob@10.4.5 in @tsoa/cli :- Patched in-place in Dockerfile, - ngrok binary :- Removed from production image (devDependency with vulnerable Go binary), - tar@6.2.1 in app/node_modules :- Removed (only used by node-pre-gyp at install time, not runtime), - File permissions :- chown -R node:node /app + USER node for non-root execution Remaining (no fix available upstream): - zlib1g CRITICAL (CVE-2023-45853) — Debian hasn't released a patch - libc6/libc-bin HIGH (CVE-2026-0861) — status affected, no fixed version yet Signed-off-by: DeepDN <nemadedeepak1111@gmail.com>
|
1 participant
What was fixed:
Remaining (no fix available upstream):
Summary by CodeRabbit
Release Notes
Bug Fixes
Chores