Remediation run

Container runs as root

Vulnerability
Container runs as root (CWE-250: Execution with Unnecessary Privileges)
Location
Dockerfile:14
Target
BaseCobalt’s vulnerable-app fixture: a Node.js application with a Dockerfile, maintained for testing remediation runs.
Outcome
Original finding resolved. Fix ready for review.

The run

$ basecobalt fix ct-f663e3

✓ Finding reproduced           current source
✓ Repository investigated      3 files
✓ Baseline validation passed   test · build
✓ Patch applied                +2 −0
✓ Validation passed            PASS → PASS
✓ Security rescan passed       0 new findings

Output shortened for readability; steps and results are as recorded.

Why the issue existed

The Dockerfile never switched to an unprivileged user, so the application process ran as root inside the container.

Patch

Dockerfile

  EXPOSE 3000+ RUN chown -R node:node /app/uploads+ USER node  CMD ["node", "server/index.js"]

Validation

The project’s test and build passed before the patch and again after it (PASS → PASS).

Security rescan

The security rescan reported 0 new findings, and the original finding no longer fired.

Outcome

Original finding resolved. Fix ready for review.

Background: why this class of issue matters

Editorial context on the vulnerability class; not run output.

When a containerized process runs as root, any vulnerability in the application (a path traversal, a command injection, an unsafe file upload) executes with root privileges inside the container. That makes it easier to modify the image’s files, read mounted secrets, and attempt a container escape.

Official Node.js images ship an unprivileged user named node. Switching to it with a USER instruction is the conventional fix. The patch also has to hand ownership of any directory the app writes to, here the uploads directory, to that user, or the application will fail at runtime once it loses root.

That second line is why validation matters for a two-line fix: dropping privileges without the chown would clear the finding but could break file uploads.

For the full sequence behind this run, see the vulnerability remediation process.