v0.40.6

[Robustness] reject unsafe LTS alias names from a mirror's index.tab
A mirror-supplied LTS codename (field 10 of index.tab) was used verbatim as an alias filename, so a hostile codename such as `../../../.bashrc` could make nvm_make_alias write outside $NVM_DIR/alias - with the default layout, into shell startup files. Constrain remote codenames to safe filename characters at ingestion in nvm_ls_remote_index_tab, and reject any `..` path component in nvm_make_alias as a backstop for every caller.
2026-08-25 00:00:22 +08:00 · 2026-07-15 14:09:54 -07:00 · 2026-07-15 13:46:52 -07:00 · 2026-07-15 13:44:04 -07:00 · 2026-07-14 23:18:07 -07:00 · 2026-07-14 23:17:01 -07:00
11 changed files with 331 additions and 35 deletions
@@ -107,3 +107,35 @@ Additionally, the maintainer of a third-party dependency might introduce a vulne
 **Recommendation**: Third-party libraries should be kept up-to-date, applying patches to address publicly known vulnerabilities in a timely fashion.
 Monitoring and logging capabilities should also be in place to detect and respond to potential attacks.
 SLSA compliance may also be considered for further supply chain security hardening.
+
+## Trust boundary: mirror payloads vs. mirror metadata
+
+`nvm` fetches two very different kinds of data from a Node.js/io.js mirror (`nodejs.org`/`iojs.org` by default, or whatever `$NVM_NODEJS_ORG_MIRROR` and `$NVM_IOJS_ORG_MIRROR` point at), and they sit on opposite sides of a trust boundary:
+
+  - **Payloads** — the Node.js/io.js binaries and source tarballs that `nvm install` downloads, unpacks, compiles (for source installs), and runs.
+  - **Metadata** — everything `nvm` parses *about* those payloads rather than executing: the `index.tab` version list (including each release's LTS codename), and the `SHASUMS`/`SHASUMS256` checksum files.
+
+Conflating the two leads to mis-scoped reports, so the project draws the line explicitly.
+
+### Payloads are trusted, by construction
+
+The entire purpose of `nvm` is to download a mirror's build of Node.js and run it.
+A mirror that serves a backdoored binary has arbitrary code execution the moment you `nvm install` and invoke `node`, and no validation inside `nvm` can prevent that - you have chosen to execute that code.
+Installing from source (`nvm install -s`) is if anything more direct: the mirror-supplied source tarball is unpacked and its `configure`/`make` build runs arbitrary code on your machine *at install time*, before `node` is ever invoked.
+Checksum verification protects **integrity** (a corrupted or truncated download, or a network intermediary that cannot also forge the same-origin `SHASUMS`), not **authenticity** against the mirror itself, since the checksums come from the same origin as the payload.
+Selecting a mirror is therefore equivalent to selecting whom you trust for arbitrary code execution in your account.
+A malicious payload from the configured mirror is consequently **out of scope**: no privilege boundary is crossed, so there is no privilege to escalate.
+
+### Metadata is not trusted
+
+Parsing a version list is a pure data operation.
+A user who runs `nvm ls-remote` to browse available versions - and installs nothing - has not opted into running any code from the mirror.
+Metadata can also be attacker-controlled with no mirror misconfiguration at all, via a compromised mirror/CDN or a man-in-the-middle of the channel (see *Threat ID 3*), so it is treated as hostile input.
+The invariant `nvm` maintains is:
+
+> Mirror-supplied metadata must never reach a shell/command evaluator, an `awk`/`sed` program body, or an unvalidated filesystem path (see *Threat ID 2*).
+
+This is why version strings from `index.tab` are passed to the downloader as literal `argv` elements rather than re-parsed by the shell ([CVE-2026-10796](https://github.com/advisories/GHSA-3c52-35h2-gfmm), [CVE-2026-1665](https://github.com/advisories/GHSA-4fc5-r4vr-8rp7)); why checksum comparisons pass the mirror's values as `awk -v` **data** and never as program text; and why LTS codenames are constrained to safe alias filenames before naming a file under `$NVM_DIR/alias/lts`, so a hostile codename such as `../../../.bashrc` cannot traverse out of the alias directory.
+
+The point is not that metadata is "more dangerous" than a payload — a trusted payload can obviously do anything.
+It is that metadata carries **no** implied grant of code execution, so any code-execution or arbitrary-write primitive reachable purely by parsing it is a defect worth removing on its own merits, independent of how much the payload channel is trusted.
@@ -0,0 +1,193 @@
+name: 'Tests: alpine'
+
+on: [push, pull_request]
+
+permissions:
+  contents: read
+
+jobs:
+  fast:
+    permissions:
+      contents: read
+
+    # Native runners per arch (no QEMU): arm64 uses the ubuntu-24.04-arm image.
+    name: 'fast ${{ matrix.arch }} (alpine ${{ matrix.alpine }}, ${{ matrix.shell }})'
+    runs-on: ${{ matrix.arch == 'arm64' && 'ubuntu-24.04-arm' || 'ubuntu-latest' }}
+
+    strategy:
+      fail-fast: false
+      matrix:
+        alpine:
+          - '3.15'
+          - '3.19'
+          - '3'
+        arch:
+          - x64
+          - arm64
+        shell:
+          - sh
+          - bash
+          - dash
+          - zsh
+          # - ksh (#574)
+
+    steps:
+      - name: Harden Runner
+        uses: step-security/harden-runner@v2
+        with:
+          allowed-endpoints:
+            github.com:443
+            registry.npmjs.org:443
+            raw.githubusercontent.com:443
+            nodejs.org:443
+            iojs.org:443
+            unofficial-builds.nodejs.org:443
+            dl-cdn.alpinelinux.org:443
+            dl-cdn.alpinelinux.org:80
+            registry-1.docker.io:443
+            auth.docker.io:443
+            production.cloudflare.docker.com:443
+            production.cloudfront.docker.com:443
+      - uses: actions/checkout@v6
+        id: checkout
+        continue-on-error: true
+        with:
+          submodules: true
+      - name: 'nvmrc submodule fallback (forks without their own nvmrc)'
+        if: steps.checkout.outcome == 'failure'
+        shell: bash
+        run: |
+          git submodule set-url test/fixtures/nvmrc https://github.com/nvm-sh/nvmrc.git
+          git submodule sync --recursive
+          git submodule update --init --recursive
+      - uses: ljharb/actions/node/install@main
+        name: 'npm install (on host; node_modules is mounted into the container)'
+        with:
+          node-version: 'lts/*'
+          skip-ls-check: true
+      - run: npm ls urchin
+      - name: 'Run fast tests on Alpine ${{ matrix.alpine }} (${{ matrix.arch }})'
+        run: |
+          for i in 1 2 3 4 5; do
+            docker pull alpine:${{ matrix.alpine }} && break
+            echo "docker pull failed, attempt $i/5"; sleep $((i * 5))
+          done
+          docker run --rm \
+            -v "${{ github.workspace }}:/workspace" \
+            -w /workspace \
+            -e "TEST_SHELL=${{ matrix.shell }}" \
+            -e "TERM=xterm-256color" \
+            -e "GITHUB_ACTIONS=true" \
+            alpine:${{ matrix.alpine }} \
+            sh -c '
+              set -ex
+              cat /etc/alpine-release; uname -m
+              for i in 1 2 3 4 5; do
+                apk add --no-cache \
+                  make bash zsh dash \
+                  grep sed gawk coreutils util-linux findutils ncurses \
+                  curl wget ca-certificates openssl tar xz gzip git \
+                  sudo su-exec libstdc++ libgcc && break
+                echo "apk add failed, attempt $i/5"; sleep $((i * 5))
+              done
+              # Mirror the ubuntu runner: run the suite as a non-root user with
+              # passwordless sudo and a PTY so the permission/terminal tests
+              # behave the same. The user takes the mounted checkout uid so
+              # files stay host-owned (no chown; post-checkout cleanup works).
+              # No node is installed, so no active version skews the output.
+              HOST_UID="$(stat -c %u /workspace)"
+              adduser -D -u "$HOST_UID" tester 2>/dev/null || adduser -D tester
+              echo "tester ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/tester
+              chmod 0440 /etc/sudoers.d/tester
+              export NVM_DIR=/workspace HOME=/home/tester
+              unset NVM_BIN NVM_INC NVM_CD_FLAGS
+              su-exec tester script -q -e -c "make TEST_SUITE=fast SHELL=$TEST_SHELL URCHIN=/workspace/node_modules/.bin/urchin test-$TEST_SHELL" /dev/null
+            '
+
+  musl-binary:
+    permissions:
+      contents: read
+
+    # Regression lock, same-era diagonal only: modern musl node needs a newer
+    # libstdc++ than old Alpine ships, and arm64-musl exists only from
+    # v20.20.1/v22.21.1/v24.9.0 (built on modern Alpine), so arm64 pins modern Alpine.
+    name: 'musl-binary ${{ matrix.arch }} (alpine ${{ matrix.alpine }}, node ${{ matrix.node }})'
+    runs-on: ${{ matrix.arch == 'arm64' && 'ubuntu-24.04-arm' || 'ubuntu-latest' }}
+
+    strategy:
+      fail-fast: false
+      matrix:
+        include:
+          - { arch: x64, alpine: '3.10', node: v8.17.0 }
+          - { arch: x64, alpine: '3.10', node: v10.24.1 }
+          - { arch: x64, alpine: '3.12', node: v12.22.12 }
+          - { arch: x64, alpine: '3.15', node: v14.21.3 }
+          - { arch: x64, alpine: '3.16', node: v16.20.2 }
+          - { arch: x64, alpine: '3.18', node: v18.20.4 }
+          - { arch: x64, alpine: '3.20', node: v20.18.1 }
+          - { arch: x64, alpine: '3', node: v22.12.0 }
+          - { arch: arm64, alpine: '3.20', node: v20.20.1 }
+          - { arch: arm64, alpine: '3', node: v22.21.1 }
+          - { arch: arm64, alpine: '3', node: v24.9.0 }
+
+    steps:
+      - name: Harden Runner
+        uses: step-security/harden-runner@v2
+        with:
+          allowed-endpoints:
+            github.com:443
+            registry.npmjs.org:443
+            unofficial-builds.nodejs.org:443
+            dl-cdn.alpinelinux.org:443
+            dl-cdn.alpinelinux.org:80
+            registry-1.docker.io:443
+            auth.docker.io:443
+            production.cloudflare.docker.com:443
+            production.cloudfront.docker.com:443
+      - uses: actions/checkout@v6
+        with:
+          submodules: false
+      - name: 'Install node ${{ matrix.node }} from a musl binary on Alpine ${{ matrix.alpine }}'
+        run: |
+          for i in 1 2 3 4 5; do
+            docker pull alpine:${{ matrix.alpine }} && break
+            echo "docker pull failed, attempt $i/5"; sleep $((i * 5))
+          done
+          docker run --rm \
+            -v "${{ github.workspace }}:/workspace" \
+            -w /workspace \
+            -e "NODE_VERSION=${{ matrix.node }}" \
+            -e "TERM=xterm-256color" \
+            alpine:${{ matrix.alpine }} \
+            sh -c '
+              set -ex
+              cat /etc/alpine-release; uname -m
+              # libstdc++/libgcc are load-bearing: the unofficial musl node
+              # binary dynamically links them. No build toolchain: -b forbids
+              # the source fallback, so a missing binary is a hard failure.
+              for i in 1 2 3 4 5; do
+                apk add --no-cache \
+                  bash ca-certificates curl wget tar xz gzip \
+                  grep sed coreutils libstdc++ libgcc && break
+                echo "apk add failed, attempt $i/5"; sleep $((i * 5))
+              done
+              export NVM_DIR=/workspace
+              unset NVM_BIN NVM_INC NVM_CD_FLAGS
+              # The default nodejs.org mirror serves no -musl artifacts; this one does.
+              export NVM_NODEJS_ORG_MIRROR=https://unofficial-builds.nodejs.org/download/release
+              . /workspace/nvm.sh --no-use
+              nvm install -b --skip-default-packages "$NODE_VERSION"
+              nvm use "$NODE_VERSION"
+              [ "$(node -v)" = "$NODE_VERSION" ] || { echo "version mismatch: $(node -v)"; exit 1; }
+              node -e "process.exit(0)"
+              ldd "$(command -v node)" | grep -qi musl
+            '
+
+  all:
+    permissions:
+      contents: none
+    name: 'all alpine tests'
+    needs: [fast, musl-binary]
+    runs-on: ubuntu-latest
+    steps:
+      - run: true
@@ -6,7 +6,7 @@
 </a>


-# Node Version Manager [![Tests](https://github.com/nvm-sh/nvm/actions/workflows/tests-fast.yml/badge.svg?branch=master)][3] [![nvm version](https://img.shields.io/badge/version-v0.40.5-yellow.svg)][4] [![CII Best Practices](https://bestpractices.dev/projects/684/badge)](https://bestpractices.dev/projects/684)
+# Node Version Manager [![Tests](https://github.com/nvm-sh/nvm/actions/workflows/tests-fast.yml/badge.svg?branch=master)][3] [![nvm version](https://img.shields.io/badge/version-v0.40.6-yellow.svg)][4] [![CII Best Practices](https://bestpractices.dev/projects/684/badge)](https://bestpractices.dev/projects/684)

 <!-- To update this table of contents, ensure you have run `npm install` then `npm run doctoc` -->
 <!-- START doctoc generated TOC please keep comment here to allow auto update -->
@@ -106,10 +106,10 @@ nvm is a version manager for [node.js](https://nodejs.org/en/), designed to be i

 To **install** or **update** nvm, you should run the [install script][2]. To do that, you may either download and run the script manually, or use the following cURL or Wget command:
 ```sh
-curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
 ```
 ```sh
-wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+wget -qO- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
 ```

 Running either of the above commands downloads a script and runs it. The script clones the nvm repository to `~/.nvm`, and attempts to add the source lines from the snippet below to the correct profile file (`~/.bashrc`, `~/.bash_profile`, `~/.zshrc`, or `~/.profile`). If you find the install script is updating the wrong profile file, set the `$PROFILE` env var to the profile file’s path, and then rerun the installation script.
@@ -136,7 +136,7 @@ Eg: `curl ... | NVM_DIR="path/to/nvm"`. Ensure that the `NVM_DIR` does not conta

 - The installer can use `git`, `curl`, or `wget` to download `nvm`, whichever is available.

- You can instruct the installer to not edit your shell config (for example if you already get completions via a [zsh nvm plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm)) by setting `PROFILE=/dev/null` before running the `install.sh` script. Here's an example one-line command to do that: `PROFILE=/dev/null bash -c 'curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash'`
+- You can instruct the installer to not edit your shell config (for example if you already get completions via a [zsh nvm plugin](https://github.com/ohmyzsh/ohmyzsh/tree/master/plugins/nvm)) by setting `PROFILE=/dev/null` before running the `install.sh` script. Here's an example one-line command to do that: `PROFILE=/dev/null bash -c 'curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash'`

 #### Installing in Docker

@@ -152,7 +152,7 @@ RUN touch "${BASH_ENV}"
 RUN echo '. "${BASH_ENV}"' >> ~/.bashrc

 # Download and install nvm
-RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | PROFILE="${BASH_ENV}" bash
+RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | PROFILE="${BASH_ENV}" bash
 RUN echo node > .nvmrc
 RUN nvm install
 ```
@@ -170,7 +170,7 @@ ARG NODE_VERSION=20
 RUN apt update && apt install curl -y

 # install nvm
-RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+RUN curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash

 # set env
 ENV NVM_DIR=/root/.nvm
@@ -196,7 +196,7 @@ After creation of the image you can start container interactively and run comman
 docker run --rm -it nvmimage

 root@0a6b5a237c14:/# nvm -v
-0.40.5
+0.40.6

 root@0a6b5a237c14:/# node -v
 v19.9.0
@@ -259,7 +259,7 @@ You can use a task:
 ```yaml
 - name: Install nvm
  ansible.builtin.shell: >
-    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+    curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
  args:
    creates: "{{ ansible_env.HOME }}/.nvm/nvm.sh"
 ```
@@ -321,7 +321,7 @@ If you have `git` installed (requires git v1.7.10+):

 1. clone this repo in the root of your user profile
    - `cd ~/` from anywhere then `git clone https://github.com/nvm-sh/nvm.git .nvm`
-1. `cd ~/.nvm` and check out the latest version with `git checkout v0.40.5`
+1. `cd ~/.nvm` and check out the latest version with `git checkout v0.40.6`
 1. activate `nvm` by sourcing it from your shell: `. ./nvm.sh`

 Now add these lines to your `~/.bashrc`, `~/.profile`, or `~/.zshrc` file to have it automatically sourced upon login:
@@ -958,13 +958,13 @@ If installing nvm on Alpine Linux *is* still what you want or need to do, you sh
 ### Alpine Linux 3.13+
 ```sh
 apk add -U curl bash ca-certificates openssl ncurses coreutils python3 make gcc g++ libgcc linux-headers grep util-linux binutils findutils
-curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
 ```

 ### Alpine Linux 3.5 - 3.12
 ```sh
 apk add -U curl bash ca-certificates openssl ncurses coreutils python2 make gcc g++ libgcc linux-headers grep util-linux binutils findutils
-curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
 ```

 _Note: Alpine 3.5 can only install NodeJS versions up to v6.9.5, Alpine 3.6 can only install versions up to v6.10.3, Alpine 3.7 installs versions up to v8.9.3, Alpine 3.8 installs versions up to v8.14.0, Alpine 3.9 installs versions up to v10.19.0, Alpine 3.10 installs versions up to v10.24.1, Alpine 3.11 installs versions up to v12.22.6, Alpine 3.12 installs versions up to v12.22.12, Alpine 3.13 & 3.14 install versions up to v14.20.0, Alpine 3.15 & 3.16 install versions up to v16.16.0 (**These are all versions on the main branch**). Alpine 3.5 - 3.12 required the package `python2` to build NodeJS, as they are older versions to build. Alpine 3.13+ requires `python3` to successfully build newer NodeJS versions, but you can use `python2` with Alpine 3.13+ if you need to build versions of node supported in Alpine 3.5 - 3.15, you just need to specify what version of NodeJS you need to install in the package install script._
@@ -1064,9 +1064,9 @@ You have to make sure that the user directory name in `$HOME` and the user direc
 To change the user directory and/or account name follow the instructions [here](https://support.apple.com/en-us/HT201548)

 [1]: https://github.com/nvm-sh/nvm.git
-[2]: https://github.com/nvm-sh/nvm/blob/v0.40.5/install.sh
+[2]: https://github.com/nvm-sh/nvm/blob/v0.40.6/install.sh
 [3]: https://github.com/nvm-sh/nvm/actions/workflows/tests-fast.yml
-[4]: https://github.com/nvm-sh/nvm/releases/tag/v0.40.5
+[4]: https://github.com/nvm-sh/nvm/releases/tag/v0.40.6
 [Urchin]: https://git.sdf.org/tlevine/urchin
 [Fish]: https://fishshell.com

@@ -1124,7 +1124,7 @@ Here's what you will need to do:
  If one of these broken versions is installed on your system, the above step will likely still succeed even if you didn't include the `--shared-zlib` flag.
  However, later, when you attempt to `npm install` something using your old version of node.js, you will see `incorrect data check` errors.
  If you want to avoid the possible hassle of dealing with this, include that flag.
-  For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-90.40.576)
+  For more details, see [this issue](https://github.com/nodejs/node/issues/39313) and [this comment](https://github.com/nodejs/node/issues/39313#issuecomment-90.40.676)

 - Exit back to your native shell.

@@ -1151,7 +1151,7 @@ Now you should be able to use node as usual.
 If you've encountered this error on WSL-2:

  ```sh
-  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.5/install.sh | bash
+  curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.6/install.sh | bash
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                  Dload  Upload  Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:00:09 --:--:--     0curl: (6) Could not resolve host: raw.githubusercontent.com
@@ -1186,7 +1186,7 @@ Currently, the sole maintainer is [@ljharb](https://github.com/ljharb) - more ma

 ## Project Support

-Only the latest version (v0.40.5 at this time) is supported.
+Only the latest version (v0.40.6 at this time) is supported.

 ## Enterprise Support

@@ -45,7 +45,7 @@ nvm_install_dir() {
 }

 nvm_latest_version() {
-  nvm_echo "v0.40.5"
+  nvm_echo "v0.40.6"
 }

 nvm_profile_is_bash_or_zsh() {
@@ -11,7 +11,7 @@
 { # this ensures the entire script is downloaded #

 # shellcheck disable=SC3028
-NVM_SCRIPT_SOURCE="$_"
+NVM_SCRIPT_SOURCE="${_:-}"

 nvm_is_zsh() {
  [ -n "${ZSH_VERSION-}" ]
@@ -1283,6 +1283,13 @@ nvm_make_alias() {
    nvm_err "an alias target version is required"
    return 2
  fi
+  # slashes are legal (eg `lts/iron`), but a `..` component would escape the alias dir
+  case "/${ALIAS}/" in
+    */../*)
+      nvm_err "invalid alias name: ${ALIAS}"
+      return 3
+    ;;
+  esac
  nvm_echo "${VERSION}" | tee "$(nvm_alias_path)/${ALIAS}" >/dev/null
 }

@@ -1797,6 +1804,7 @@ nvm_ls_remote_index_tab() {
  command mkdir -p "$(nvm_alias_path)/lts"
  { command awk '{
        if ($10 ~ /^\-?$/) { next }
+        if (tolower($10) !~ /^[a-z0-9][a-z0-9._-]*$/) { next }
        if ($10 && !a[tolower($10)]++) {
          if (alias) { print alias, version }
          alias_name = "lts/" tolower($10)
@@ -2251,10 +2259,12 @@ nvm_get_arch() {
    HOST_ARCH=armv7l
  fi

-  if [ -f "/etc/alpine-release" ]; then
-    # Alpine Linux uses musl libc; only x64-musl binaries are available
+  if [ -f "/etc/alpine-release" ] && [ "_${NVM_OS}" = "_linux" ]; then
+    # Alpine Linux uses musl libc; map to musl variants where available
+    # See https://unofficial-builds.nodejs.org/download/release/
    case "${NVM_ARCH}" in
      x64) NVM_ARCH=x64-musl ;;
+      arm64) NVM_ARCH=arm64-musl ;;
    esac
  fi

@@ -4727,7 +4737,7 @@ nvm() {
      NVM_VERSION_ONLY=true NVM_LTS="${NVM_LTS-}" nvm_remote_version "${PATTERN:-node}"
    ;;
    "--version" | "-v")
-      nvm_echo '0.40.5'
+      nvm_echo '0.40.6'
    ;;
    "unload")
      nvm deactivate >/dev/null 2>&1
@@ -1,6 +1,6 @@
 {
  "name": "nvm",
-  "version": "0.40.5",
+  "version": "0.40.6",
  "description": "Node Version Manager - Simple bash script to manage multiple active node.js versions",
  "directories": {
    "test": "test"
@@ -90,8 +90,13 @@ run_test amd64 smartos x64 no_pkg_info
 run_test x86 osx x86
 run_test amd64 osx x64

-run_test arm64 smartos x64
-run_test armv8l smartos x64
+# These smartos cases have no arch-specific uname mock, so nvm_get_os falls
+# through to the real host; on Alpine that host is linux and picks up the musl
+# suffix, which these non-musl assertions do not expect. Skip them there.
+if [ ! -f "/etc/alpine-release" ]; then
+  run_test arm64 smartos x64
+  run_test armv8l smartos x64
+fi

 run_test loongarch64 linux loong64

@@ -15,8 +15,8 @@ die () { cleanup; echo "$@" ; exit 1; }
 MOCKS_DIR="$(pwd)/../../mocks"
 export PATH=".:${PATH}"

-# On Alpine (where /etc/alpine-release exists), x64 should get -musl suffix
-# and arm64 should NOT get -musl suffix.
+# On Alpine (where /etc/alpine-release exists), both x64 and arm64 should get
+# the -musl suffix, since unofficial-builds publishes musl binaries for both.
 # On non-Alpine, neither should get -musl.

 if [ -f "/etc/alpine-release" ]; then
@@ -26,11 +26,11 @@ if [ -f "/etc/alpine-release" ]; then
  rm -f ./uname
  [ "_${OUTPUT}" = "_x64-musl" ] || die "x64 on Alpine should be x64-musl, got ${OUTPUT}"

-  # aarch64 on Alpine should produce arm64, NOT arm64-musl
+  # aarch64 on Alpine should produce arm64-musl
  ln -sf "${MOCKS_DIR}/uname_linux_aarch64" ./uname
  OUTPUT="$(nvm_get_arch)"
  rm -f ./uname
-  [ "_${OUTPUT}" = "_arm64" ] || die "aarch64 on Alpine should be arm64 (no musl suffix), got ${OUTPUT}"
+  [ "_${OUTPUT}" = "_arm64-musl" ] || die "aarch64 on Alpine should be arm64-musl, got ${OUTPUT}"
 else
  # x64 on non-Alpine should produce x64 (no musl suffix)
  ln -sf "${MOCKS_DIR}/uname_linux_x86_64" ./uname
@@ -57,15 +57,23 @@ setup_chroot() {
  sudo mknod "${chroot_dir}/dev/null" c 1 3
 }

-setup_chroot "${CHROOT_WITH_ALPINE}"
-setup_chroot "${CHROOT_WITHOUT_ALPINE}"
+# The chroot fixtures assume a glibc layout (fixed dynamic-linker path under
+# /lib64, coreutils binaries). On musl Alpine that setup does not apply, and
+# nvm_get_arch's musl mapping is already covered by the "nvm_get_arch alpine"
+# test, so skip the chroot checks there and still run the ls-remote checks.
+if [ -f "/etc/alpine-release" ]; then
+  echo "on Alpine; skipping chroot arch checks (covered by 'nvm_get_arch alpine')"
+else
+  setup_chroot "${CHROOT_WITH_ALPINE}"
+  setup_chroot "${CHROOT_WITHOUT_ALPINE}"

-# Run tests in chroot environments
-ARCH_WITH_ALPINE=$(sudo chroot "${CHROOT_WITH_ALPINE}" /bin/sh -c ". ./nvm.sh && nvm_get_arch")
-[ "${ARCH_WITH_ALPINE}" = "x64-musl" ] || die "Expected x64-musl for alpine environment but got ${ARCH_WITH_ALPINE}"
+  # Run tests in chroot environments
+  ARCH_WITH_ALPINE=$(sudo chroot "${CHROOT_WITH_ALPINE}" /bin/sh -c ". ./nvm.sh && nvm_get_arch")
+  [ "${ARCH_WITH_ALPINE}" = "x64-musl" ] || die "Expected x64-musl for alpine environment but got ${ARCH_WITH_ALPINE}"

-ARCH_WITHOUT_ALPINE=$(sudo chroot "${CHROOT_WITHOUT_ALPINE}" /bin/sh -c ". ./nvm.sh && nvm_get_arch")
-[ "${ARCH_WITHOUT_ALPINE}" != "x64-musl" ] || die "Did not expect x64-musl for non-alpine environment"
+  ARCH_WITHOUT_ALPINE=$(sudo chroot "${CHROOT_WITHOUT_ALPINE}" /bin/sh -c ". ./nvm.sh && nvm_get_arch")
+  [ "${ARCH_WITHOUT_ALPINE}" != "x64-musl" ] || die "Did not expect x64-musl for non-alpine environment"
+fi

 # Run tests for nvm ls-remote
 test_default_ls_remote() {
@@ -14,6 +14,14 @@ die () { >&2 echo "$@" ; cleanup ; exit 1; }
 : nvm.sh
 \. ../../../nvm.sh

+# v0.12.18 predates musl binaries and the expected output hardcodes the glibc
+# x64 tarball URL, so on Alpine nvm would request a nonexistent -musl build.
+# The progress-bar behavior is not OS-specific, so skip below the musl floor.
+if [ -f "/etc/alpine-release" ]; then
+  echo 'on Alpine; skipping (v0.12.18 has no musl binary)'
+  exit 0
+fi
+
 cleanup

 OUTPUT="$(TERM=dumb 2>&1 nvm install --no-progress v0.12.18)"
@@ -0,0 +1,40 @@
+#!/bin/sh
+
+WORK="$PWD/ls_remote-traversal-work.$$"
+export HOME="$WORK/home"
+export NVM_DIR="$HOME/.nvm"
+BASHRC="$HOME/.bashrc"
+
+cleanup() {
+  unset -f die cleanup nvm_download
+  rm -rf "$WORK"
+}
+die () { echo "$@" ; cleanup ; exit 1; }
+
+mkdir -p "$NVM_DIR/alias"
+
+: nvm.sh
+\. ../../../nvm.sh
+
+# a malicious/compromised mirror: the LTS codename field ($10) carries path
+# traversal, and the version field ($1) carries a command-substitution payload;
+# a valid codename (Iron) is included to prove real aliases still get written
+nvm_download() {
+  printf 'version\tdate\tfiles\tnpm\tv8\tuv\tzlib\topenssl\tmodules\tlts\tsecurity\n'
+  printf '$(>%s/pwned)\t2026-01-01\tlinux-x64\t-\t-\t-\t-\t-\t-\t../../../.bashrc\t-\n' "$WORK"
+  printf 'v20.0.0\t2026-01-01\tlinux-x64\t-\t-\t-\t-\t-\t-\tIron\t-\n'
+}
+
+nvm_ls_remote >/dev/null 2>&1 || true
+
+[ ! -e "$BASHRC" ] || die "path traversal wrote outside the alias dir: $BASHRC was created"
+[ ! -e "$WORK/pwned" ] || die "mirror-supplied payload landed: $WORK/pwned was created"
+[ -f "$NVM_DIR/alias/lts/iron" ] || die "valid LTS alias lts/iron was not created"
+
+nvm_make_alias 'lts/../../../escape' 'v1.0.0' 2>/dev/null && die 'nvm_make_alias accepted a traversing alias name'
+[ ! -e "$NVM_DIR/../escape" ] || die 'nvm_make_alias wrote outside the alias dir'
+nvm_make_alias 'lts/carbon' 'v8.0.0' >/dev/null 2>&1 || die 'nvm_make_alias rejected a valid alias name'
+[ -f "$NVM_DIR/alias/lts/carbon" ] || die 'nvm_make_alias did not create a valid alias'
+
+cleanup
+echo "nvm_ls_remote LTS codename traversal: passed"
Author	SHA1	Message	Date
Jordan Harband	b6cf55f6ad	v0.40.6	2026-07-15 14:09:54 -07:00
Jordan Harband	9275c5badd	[Robustness] reject unsafe LTS alias names from a mirror's index.tab A mirror-supplied LTS codename (field 10 of index.tab) was used verbatim as an alias filename, so a hostile codename such as `../../../.bashrc` could make nvm_make_alias write outside $NVM_DIR/alias - with the default layout, into shell startup files. Constrain remote codenames to safe filename characters at ingestion in nvm_ls_remote_index_tab, and reject any `..` path component in nvm_make_alias as a backstop for every caller.	2026-07-15 13:46:52 -07:00
Jordan Harband	882ed79ece	[Docs] threat model: document the mirror payload/metadata trust boundary Payloads (binaries, plus source tarballs that nvm compiles and runs at install time) are trusted by construction, since nvm exists to build and run them; parsed metadata (index.tab, SHASUMS, LTS codenames) is not, and must never reach a command evaluator, an awk/sed program body, or an unvalidated filesystem path. This records why the existing version-string and checksum hardening exists, and scopes a malicious payload from a configured mirror as out of scope: no privilege boundary is crossed.	2026-07-15 13:44:04 -07:00
Jordan Harband	d83da5d75b	[actions] add `tests-alpine`: a green fast suite and a musl-binary regression matrix The full suite cannot run on Alpine: the install-based suites pin ancient Node (0.10.x, io.js) that has no musl binary and cannot source-compile on musl. Run the fast unit suite instead (mirroring the ubuntu runner: non-root via su-exec, passwordless sudo, a PTY, no system node), plus a binary-only regression matrix that installs every (Alpine, Node) pair with a real unofficial musl binary via `nvm install -b`: x64 back to node 8.17.0 on old Alpine, arm64 at the v20.20.1/v22.21.1/v24.9.0 floors on modern Alpine.	2026-07-14 23:18:07 -07:00
Jordan Harband	438009f54e	[Tests] make the fast suite pass on Alpine `nvm_get_arch`: skip the smartos arm64/armv8l cases, which have no uname mock and fall through to the real host (adding a musl suffix on Alpine). `nvm_get_arch_unofficial`: skip the glibc chroot (fixed /lib64 loader, sudo); the musl mapping is already covered by the `nvm_get_arch alpine` test. `nvm_install_no_progress_bar`: skip below the musl floor, since v0.12.18 has no musl binary and hardcodes the glibc tarball URL.	2026-07-14 23:17:01 -07:00
Jordan Harband	f1e7a84cb5	[Robustness] avoid a `set -u` error when `$_` is unset Sourcing nvm.sh under `set -u` on a POSIX shell that leaves `$_` unset (e.g. busybox ash or dash on Alpine, where the parent shell does not export it) aborted at `NVM_SCRIPT_SOURCE="$_"`. Default to empty; the only consumer already falls back to `$0`.	2026-07-14 23:16:39 -07:00
Jordan Harband	86c937436d	[Robustness] `nvm_get_arch`: only apply the Alpine musl suffix when the OS is linux The `/etc/alpine-release` check applied the -musl suffix regardless of the resolved OS. In practice Alpine is always linux, so this is behavior-neutral, but it also makes the `nvm_get_arch` unit test hermetic: its mocked smartos/osx cases no longer pick up a real host's Alpine marker.	2026-07-14 23:10:33 -07:00
Jesse ZhuandJordan Harband	ce157c1171	[Fix] support arm64-musl on Alpine Linux Node.js unofficial-builds publishes linux-arm64-musl binaries since v20.20.1 / v22.21.1 / v24+. Map NVM_ARCH=arm64 to arm64-musl on Alpine so `nvm install` resolves to the correct tarball instead of the glibc-linked arm64 build that won't run against musl. [Tests] `nvm_get_arch`: expect arm64-musl on Alpine Co-authored-by: Jesse Zhu <jesse@itjesse.com> Co-authored-by: Jordan Harband <ljharb@gmail.com>	2026-05-23 01:35:12 +09:00