CVSS Assessment

CVSS v3.1 Calculator

Summary

All Dockerfiles use mutable version tags (node:22-bookworm, debian:bookworm-slim, ubuntu:24.04) instead of SHA-pinned digests, allowing supply chain attacks where a compromised upstream image is silently pulled into production builds.

Affected Code

Production Dockerfiles:

File: Dockerfile:1

FROM node:22-bookworm

File: Dockerfile.sandbox:1

FROM debian:bookworm-slim

File: Dockerfile.sandbox-browser:1

FROM debian:bookworm-slim

Test/CI Dockerfiles:

File: scripts/docker/cleanup-smoke/Dockerfile:1

FROM node:22-bookworm-slim

File: scripts/docker/install-sh-e2e/Dockerfile:1

FROM node:22-bookworm-slim

File: scripts/docker/install-sh-nonroot/Dockerfile:1

FROM ubuntu:24.04

File: scripts/docker/install-sh-smoke/Dockerfile:1

FROM node:22-bookworm-slim

File: scripts/e2e/Dockerfile:1

FROM node:22-bookworm

File: scripts/e2e/Dockerfile.qr-import:1

FROM node:22-bookworm

Attack Surface

How is this reached?

• Network (HTTP/WebSocket endpoint, API call)
• Adjacent Network (same LAN, requires network proximity)
• Local (local file, CLI argument, environment variable)
• Physical (requires physical access to machine)

Authentication required?

• None (unauthenticated/public access)
• Low (any authenticated user)
• High (admin/privileged user only)

Entry point: Docker image pull during CI/CD build or local development

Exploit Conditions

Complexity:

• Low (no special conditions, works reliably)
• High (requires race condition, specific config, or timing)

User interaction:

• None (automatic, no victim action needed)
• Required (victim must click, visit, or perform action)

Prerequisites: Attacker must compromise Docker Hub/upstream registry or execute a man-in-the-middle attack during image pull

Impact Assessment

Scope:

• Unchanged (impact limited to vulnerable component)
• Changed (can affect other components, escape sandbox)

What can an attacker do?

Steps to Reproduce

1. Observe all 9 Dockerfiles use mutable tags (e.g., FROM node:22-bookworm)
2. Note that each build may pull a different image if the tag is updated upstream
3. If Docker Hub or an intermediate registry is compromised, a malicious image could be pulled without detection
4. The CI workflow (.github/workflows/docker-release.yml) rebuilds on every push to main, pulling fresh base images
5. Dependabot is configured (.github/dependabot.yml) but does NOT include package-ecosystem: docker, so there's no automated digest update mechanism

Recommended Fix

Pin all base images to immutable SHA256 digests:

# Production Dockerfiles
FROM node:22-bookworm@sha256:<digest>
FROM debian:bookworm-slim@sha256:<digest>

# Test/CI Dockerfiles
FROM node:22-bookworm-slim@sha256:<digest>
FROM ubuntu:24.04@sha256:<digest>

Add Docker ecosystem to Dependabot configuration (.github/dependabot.yml):

  # Docker base images
  - package-ecosystem: docker
    directory: /
    schedule:
      interval: weekly
    groups:
      docker-images:
        patterns:
          - "*"

Alternatively, use Renovate or docker-lock for automated digest updates.

To obtain current digests:

docker pull node:22-bookworm && docker inspect --format='{{index .RepoDigests 0}}' node:22-bookworm
docker pull debian:bookworm-slim && docker inspect --format='{{index .RepoDigests 0}}' debian:bookworm-slim
docker pull ubuntu:24.04 && docker inspect --format='{{index .RepoDigests 0}}' ubuntu:24.04
docker pull node:22-bookworm-slim && docker inspect --format='{{index .RepoDigests 0}}' node:22-bookworm-slim

References

• CWE: CWE-1104 - Use of Unmaintained Third Party Components