fix(backend): Attempt at fixing critical deps

[cozminu]

Changes proposed in this pull request

Clearing the critical and high advisories. Everything here is a lockfile or override change except the last few commits, which touch the prod Dockerfiles.

• bad77efa5 bump @babel/core, protobufjs, yaml, webpack, tmp, tar, undici. Covers the seven security PRs that still needed work: chore(deps): update dependency @babel/core to v7.29.6 [security] #3954, chore(deps): update dependency protobufjs to ^7.6.5 [security] #3952, chore(deps): update dependency yaml to v2.8.3 [security] #3902, chore(deps): update dependency webpack to v5.104.1 [security] #3826, chore(deps): update dependency tmp to v0.2.7 [security] #3953, chore(deps): update dependency tar to >=7.5.20 [security] #3867, chore(deps): update dependency undici@>=6.0.0 to ^6.25.0 [security] #3849. tmp is scoped to >=0.2.0 here so the 0.0.33 copy under inquirer doesn't get dragged across a major.
• f5ccf8827 handlebars, shell-quote, websocket-driver. Clears the last three criticals, all within-major.
• a22fb7fc4 babel systemjs transform, devalue, fast-uri, flatted, postcss, svgo, next. Single-major highs, one override key each.
• 2bed11910 range-scoped bumps for brace-expansion, immutable, js-yaml, minimatch, rollup, tar-fs, vite, ws. Each major line gets its own bounded key rather than one unscoped override. Several of these packages already have a clean newer major in the tree (minimatch 10, tar-fs 3, rollup 4, vite 7.3.6) that an unscoped override would have downgraded.
• 9a4595857 astro 6.4.6, axios 1.18.0. Both are declared deps, so the package.json files move alongside the override instead of drifting from it. astro stays on ~6.4.x, since its remaining advisories only patch in 7.x.
• 25cf61916 sharp 0.35.0, plus a jaeger propagator override scoped to 2.x. sharp ships native binaries, so CI linux is the real test here, not local darwin.
• 3f3081459 suppress GHSA-45rx-2jwx-cxfr through pnpm.auditConfig.ignoreGhsas instead of chasing an otel v2 migration. I tried the migration and backed out; the reasoning is in the commit message. This one gets undone by 930c7726c and d44848a99, see Context.
• aeccbfaa9 relay-compiler 13, to drop immutable 3. immutable 3.8.3 has two highs and no patched 3.x, so the only way out is moving the thing that depends on it. relay-operation-optimizer 7.0.0 asks for relay-compiler ^12, but its own latest (7.1.8) asks for ^13.0.2 on the same optimizer major, so the API it uses didn't move. Codegen output is unchanged.
• ada1ae50b @vanilla-extract/integration 8, to drop vite 4. vite 4.5.14 comes in under integration 6.2.1 via remix's classic compiler in mock-ASE. There's no vite it could move to inside a range 6.x accepts, and vite 5 is out of support so GHSA-fx2h has no 5.x patch. integration v8 has no vite dependency at all, so vite just leaves. Caveat: v8 renamed createCompiler to compile and remix 2.17.5 still calls createCompiler, but that's only reached from the .css.ts / .vanilla.css onLoad handlers, and the plugin bails out earlier anyway unless the app declares @vanilla-extract/css. mock-ASE does neither. It does become a landmine if mock-ASE ever adopts vanilla-extract.
• 1dc9895bd unscope the tmp override so it catches 0.0.33. external-editor is at its latest (3.1.0) and still pins tmp ^0.0.33, so the >=0.2.0 selector never reached that copy and there's no upstream fix to wait for. external-editor only calls tmp.tmpNameSync, which 0.2.7 still exports with the same signature, and the path is inquirer's editor prompt inside graphql-codegen, which never runs interactively here.
• 75a5d9c35 drop npm from the prod runner images. This is the one that actually fixed the scan jobs, details below.
• 930c7726c collapse @opentelemetry/propagator-jaeger onto 2.10.0.
• 3f7a50719 record why bumping the base image isn't an alternative to the npm removal.
• d44848a99 delete the scanner suppressions that are now dead.

Context

The override bumps cleared pnpm audit, but the Grype and Trivy jobs kept failing, and several rounds of bumping them further changed nothing. The reason is that the packages they were failing on weren't ours.

Trivy's file paths gave it away: every finding sat under /usr/local/lib/node_modules/npm. node:24-alpine3.23 ships npm 11.17.0, which bundles tar 7.5.16, brace-expansion 5.0.6, ip-address 10.2.0 and undici 6.26.0. I checked those versions in the base image by hand and they match the scanner output exactly. That's 5 highs plus a critical in all five images. Our lockfile already resolves tar 7.5.22, brace-expansion 5.0.9 and undici 6.28.0, but a pnpm override can't reach a copy of npm baked into the runner image, so none of the bumps were ever going to help.

The runner stages only exec node (frontend goes through node_modules/.bin/remix-serve), corepack isn't enabled there, and nothing in localenv or helm shells out to npm inside these containers. So npm is dead weight and removing it takes out the whole class of finding rather than this month's batch of it.

I did check whether a newer base tag would be a cleaner fix than deleting npm in five Dockerfiles, and it isn't an option today. Every node:24 alpine tag (3.22, 3.23, 3.24, and the floating 24-alpine) is node 24.19.0 with npm 11.17.0 and identical bundled versions. Going further up doesn't help either: the newest published node image, node:alpine at 26.7.0, ships npm 11.19.0, which is still brace-expansion 5.0.7 and ip-address 10.2.0. Both are still vulnerable to the highs that fail us, since GHSA-rgw5 wants 5.0.9, GHSA-mh99 wants 5.0.8 and GHSA-mwp4 wants ip-address 10.3.1. So no base image at any node version passes the high cutoff right now, and engines pins us to node 24 regardless.

Backend had one more high that was genuinely ours: @opentelemetry/propagator-jaeger 1.25.1, CVE-2026-59892. The suppression in 3f3081459 only went into pnpm.auditConfig.ignoreGhsas, which covers pnpm audit and nothing else, so Trivy kept failing on it. It turns out this didn't need the otel v2 migration I backed away from: the backend already installs propagator-jaeger 2.10.0 via sdk-node 0.217.0, right next to the 1.25.1 that sdk-trace-node 1.25.1 pulls in. Both were already in the tree. Widening the override (it was scoped to @>=2.0.0 and so matched nothing) collapses them onto 2.10.0. sdk-trace-node 1.x only constructs JaegerPropagator and registers it as a TextMapPropagator, so the v1/v2 core split underneath doesn't matter here.

With that fixed, three suppressions were left pointing at nothing, so d44848a99 removes them. The ignoreGhsas entry can't match since propagator-jaeger 1.25.1 is gone from the tree. .grype.yaml and .trivyignore both carried CVE-2026-12151, plus GHSA-vxpw-j846-p89q on the grype side, and neither ID shows up in any of the five images at any severity. Running grype with the config still loaded now reports zero matches ignored, where CI was logging 6 before. I deleted the two files rather than leave them empty, following the pruning #3947 did.

How this was verified

• Built all five prod images locally and scanned each with both Grype and Trivy at the settings CI uses. All ten runs exit 0, with no ignore config present at all. npm no longer appears anywhere in the scanned path list.
• Also scanned every image across all severities with no ignore config, to confirm the suppressed IDs really are dead rather than just below the cutoff.
• For the propagator swap: NodeTracerProvider.register() with the v2 propagator works, and an uber-trace-id round-trips through extract/inject with trace id, span id and flags intact. All 34 backend telemetry tests pass.
• pnpm audit is down to 8 low and 23 moderate, no highs or criticals, and unchanged by dropping the ignoreGhsas entry.

I only scanned amd64 locally. CI covers arm64 as well.

One thing worth knowing for future scan triage: grype reports monorepo-symlink-test under GHSA-2jcg-qqmg-46q6 as critical. It's a fixture with no fix available, so CI's only-fixed filters it out, but it does show up if you run grype by hand without that flag.

Still outstanding

• @opentelemetry/core 1.22.0 and 1.25.1 are in the tree under GHSA-8988-4f7v-96qf. It's moderate, below the scan cutoff, and clearing it needs the SDK v2 move.
• astro's remaining advisories only patch in 7.x, which is a major and out of scope here.

Separately, and not caused by anything in this PR: telemetry tracing looks broken on main any time ENABLE_TELEMETRY_TRACES=true. The backend has sdk-node 0.217.0 pulling v2-era otlp-transformer alongside the v1-era exporter-trace-otlp-grpc / exporter-metrics-otlp-grpc, and trace export throws on clashing protobufjs globals. Bumping the two grpc exporters to ^0.221.0 fixes that crash but trades it for another, since v1's Span has no instrumentationScope field and the v2-era serializer requires it. Nothing catches this today because service.test.ts mocks the otel packages wholesale and CI never enables telemetry. Worth a look by whoever owns telemetry.

Checklist

• Related issues linked using fixes #number
• Tests added/updated
• Make sure that all checks pass
• Bruno collection updated (if necessary)
• Documentation issue created with user-docs label (if necessary)
• OpenAPI specs updated (if necessary)

[netlify]

✅ Deploy Preview for brilliant-pasca-3e80ec canceled.

Name	Link
🔨 Latest commit	95d17f4
🔍 Latest deploy log	https://app.netlify.com/projects/brilliant-pasca-3e80ec/deploys/6aac7d4d7de4e60007e81a2e

[github-actions]

🚀 Performance Test Results

Test Configuration:

• VUs: 4
• Duration: 1m0s

Test Metrics:

• Requests/s: 40.79
• Iterations/s: 13.59
• Failed Requests: 0.00% (0 of 2452)

📜 Logs

> performance@1.0.0 run-tests:testenv /home/runner/work/rafiki/rafiki/test/performance
> ./scripts/run-tests.sh -e test -k -q --vus 4 --duration 1m

Cloud Nine GraphQL API is up: http://localhost:3101/graphql
Cloud Nine Wallet Address is up: http://localhost:3100/
Happy Life Bank Address is up: http://localhost:4100/
cloud-nine-wallet-test-backend already set
cloud-nine-wallet-test-auth already set
happy-life-bank-test-backend already set
happy-life-bank-test-auth already set
     data_received..................: 885 kB 15 kB/s
     data_sent......................: 1.9 MB 31 kB/s
     http_req_blocked...............: avg=7.07µs   min=2.35µs   med=5.59µs   max=577.41µs p(90)=6.98µs   p(95)=7.87µs  
     http_req_connecting............: avg=292ns    min=0s       med=0s       max=223.17µs p(90)=0s       p(95)=0s      
     http_req_duration..............: avg=97.37ms  min=6.7ms    med=77.22ms  max=442.17ms p(90)=172.31ms p(95)=197.89ms
       { expected_response:true }...: avg=97.37ms  min=6.7ms    med=77.22ms  max=442.17ms p(90)=172.31ms p(95)=197.89ms
     http_req_failed................: 0.00%  ✓ 0         ✗ 2452
     http_req_receiving.............: avg=106.55µs min=27.45µs  med=91.61µs  max=2.09ms   p(90)=136.78µs p(95)=177.32µs
     http_req_sending...............: avg=39.67µs  min=9.4µs    med=27.17µs  max=2ms      p(90)=47.54µs  p(95)=67.75µs 
     http_req_tls_handshaking.......: avg=0s       min=0s       med=0s       max=0s       p(90)=0s       p(95)=0s      
     http_req_waiting...............: avg=97.23ms  min=6.36ms   med=77.04ms  max=441.8ms  p(90)=172.18ms p(95)=197.76ms
     http_reqs......................: 2452   40.788843/s
     iteration_duration.............: avg=294.08ms min=191.65ms med=277.14ms max=950.24ms p(90)=378.6ms  p(95)=409.65ms
     iterations.....................: 817    13.590736/s
     vus............................: 4      min=4       max=4 
     vus_max........................: 4      min=4       max=4 

[BlairCurrey]

There are at least 2 loose ends if we remove npm. interledger/helm-charts and packages/documentation/src/content/docs/admin/admin-user-guide.mdx reference npm in some commands. I think we could simply update both to use node --run instead.

Im unsure to what extent interledger/helm-charts are being used but we should update it either way I guess. Here is one of the places (the other being auth): https://github.com/interledger/helm-charts/blob/main/charts/rafiki-backend/templates/deployment.yaml#L45

[BlairCurrey]

In terms of removing npm in principle, I think it's a good idea. We shouldn't need it at runtime and it only increases the vulnerability surface.

Alternatively we could maybe use a distroless runner but I think that would require some more changes to the docker files and in frontend we use sh which would need a workaround. gcr.io/distroless/nodejs24

[BlairCurrey]

minor thing, but i updated this to fail if npm is still found (if npm at a different path rm silently returns OK).

[mkurapov]

interledger/helm-charts directory is old (we actually should remove this, since we have everything in interledger/charts repository), and updating to use node for the user invitation script in the docs make sense as well, if that is possible.

[BlairCurrey]

--severity is a list, not a floor. we werent scanning for critical vulnerabilities with Trivy

[BlairCurrey]

openssl had a vulnerability. It has been fixed but there is no alpine tag that includes it yet.

I think using distroless could have sidestepped this one as well.

This is a pattern I've seen elsewhere. Such as https://github.com/jupyterhub/configurable-http-proxy/blob/14568e1b426c4818317da567a8f8f4d19a7c28a2/Dockerfile#L11-L13

Trivy's org updates images like this as well: https://github.com/aquasecurity/kube-hunter/blob/bc47f08e88ea2a5fb059bf3b8a8edb1aefb4c6cc/Dockerfile#L10

[BlairCurrey]

This one hurts.

Next is a dependency in our frontend. Our Remix frontend. We have this entirely seperate, large, frontend framework because its a dependency of @ory/integrations. Which we use for 2 utility functions.

This transitive next dependencies is a source of a few critical vulnerabilities and is 152.6MB of the final 455.2MB docker image. So this is kind of absurd.

Seems like we could probably just inline those utility function but Im not sure how likely that would come back to bite us (eg. ory changes integrations and client together, we dont get the integrations change, something doesn't work). I think it's related to CSRF.

And looking at @ory/integrations (https://github.com/ory/integrations) it looks purpose-built for next and also archived... so I'm really not sure we should be using it.

[BlairCurrey]

could probably do this and drop @ory/integration (and next):

  // packages/frontend/app/lib/kratos-ui.ts
  import { UiNodeGroupEnum } from '@ory/client'
  import type { UiNode, UiNodeAttributes, UiNodeInputAttributes } from '@ory/client'

  export function formNodes(nodes: UiNode[], method: UiNodeGroupEnum): UiNode[] {
    return nodes.filter(
      (n) => n.group === method || n.group === UiNodeGroupEnum.Default
    )
  }

  export function isInputNode(
    attrs: UiNodeAttributes
  ): attrs is UiNodeInputAttributes & { node_type: 'input' } {
    return attrs.node_type === 'input'
  }

[BlairCurrey]

removed next.

i also noticed the checkAuthAndRedirect in all the loaders could now be done centrally in the new remix version (which is actually react router v7 -- remix was merged into that). That's a whole other can of worms though - I left a code comment.

219fcbd#diff-57b68df4807ecdfd319935e4b00ab56a223f5bae7559b62c65d42b717a6e05a1R30-R32