[carjessu-trm]

Why

INC-3583: the eMudhra (emSign) intermediate CA private key was compromised. Node.js bundles its own CA store, so only the Node security releases fix Node processes: v22.23.4 / v24.22.1 / v26.12.1 include nodejs/node#66871 (reject chains containing blocked public keys) and NSS 3.131.1. Tracking: Linear PSE-1636. Node 25 is EOL and gets no fix.

What changed

• Dockerfile: ARG BASE_IMAGE=node:25-alpine -> node:24.22.1-alpine@sha256:6a1c190e…. This is the Node 25 (EOL) -> 24.22.1 (Active LTS) move for the default image.
• .github/workflows/ci-cd.yml and release.yml caged builds: platformatic/node-caged:25-alpine -> platformatic/node-caged:26.12.1-alpine@sha256:fe8ec905…. node-caged publishes no 24.x tags (24-alpine and 24.22.1-alpine both 404); only 25.x and 26.x exist. 26.12.1 is the patched option that keeps the caged variant. I confirmed v26.12.1 from the binary in the amd64 image, since the image sets no NODE_VERSION.
• .github/workflows/release.yml: setup-node lts/* -> '24.22.1'.
• package.json engines.node: "25" -> "24.22.1 || 26.12.1". pnpm fails the install when the root project's engines.node doesn't match, so it has to cover both base images. CI's falcondev-it/.github/actions/pnpm-install also reads it through node-version-file: package.json, so lint, type-check and unit tests run on one of these two patched versions. Upstream moved engines from 24 to 25 only when it added the caged variant (f77794b), and nothing in the code uses a Node 25-only API.
• node:24.22.1-alpine is the Docker Hub multi-arch index digest; I verified NODE_VERSION=24.22.1 on amd64, arm64 and s390x.

Why exact versions

Floating tags resolve to older cached patches on our runners, and a digest pin stays on whatever Node it was built with.

Validation

• Checked the engines range with semver: 24.22.1 and 26.12.1 pass; 24.21.0, 25.9.0 and 22.23.4 fail. package.json parses. No local build; CI on this PR runs lint, type-check and unit tests.
• After merge to dev: ci-cd.yml publishes ghcr.io/trmlabs/github-actions-cache-server:dev and :dev-caged. Nothing deploys those images.

Deploy impact: this PR does not patch the running cache server

The github-runners cluster runs upstream's image. trm-infra github-runners/terraform/gcp-us-central1/trm-github-runners/10-arc/main.tf (helm_release.actions_cache_server) installs oci://ghcr.io/falcondev-oss/charts/github-actions-cache-server 1.0.2 with image.tag = "9.4.7". The repository is the chart default, ghcr.io/falcondev-oss/github-actions-cache-server, and that image runs Node 25.9.0. This fork's change only helps once we build our own image and point image.repository and image.tag there. Caveats:

• No upstream image is patched yet: 9.4.7 and 9.8.0 run Node 25.9.0, and upstream dev runs 26.10.0. Upstream standardized on Node 26 in build: standardize on Node 26 falcondev-oss/github-actions-cache-server#272 (2026-10-01), but no release includes it.
• This fork's dev is at v9.4.2, behind the deployed 9.4.7. An image built from it would drop the 9.4.4 stale-entry fix and the 9.4.7 scope-fallback fix (fix: fall back to next scope when no restore keys falcondev-oss/github-actions-cache-server#229) that main.tf pins for. Sync the fork with upstream before switching the cluster to it.

Not in this PR

• Syncing the fork with upstream, and the trm-infra change to switch helm_release.actions_cache_server to a patched image. Upstream is moving to Node 26; aligning this fork's default image on 26.12.1 instead of 24.22.1 would reduce drift if we sync.

[stepsecurity-app]

Security Policy Alert: Runner Label Policy Violation

This workflow run has been blocked by StepSecurity's runner label policy because it uses runner labels that are not allowed by your organization's policy.

Disallowed Runner Labels:

• ubuntu-latest

To fix this issue, please modify the runs-on field in your workflow to use only allowed runner labels. Contact your organization administrator if you need further assistance.

For more information, see StepSecurity's Runner Label Policy documentation.