Security: lts/* installs old LTS versions up to 9 days after release

[karlhorky]

Description:

Using the lts/* alias with actions/setup-node installed Node.js v22.13.0 as of 25 Jan 2025, an old version. Node.js v22.13.1 has been out since 21 Jan 2025.

⚠️ Security: Node.js v22.13.1 contains security updates and as such, this can be considered a security problem

      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          check-latest: true

Workflow logs:

Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: false
    token: ***
  ...
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/22.13.0/x64
Environment details
  node: v22.13.0
  npm: 10.9.2
  yarn: 1.22.22

Longer update delays of over 5 days can be seen in #940

Action version:

actions/setup-node@v4

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:

Node.js lts/*

  node: v22.13.0
  npm: 10.9.2
  yarn: 1.22.22

Repro steps:

Use the configuration above and observe the output above

Expected behavior:

Node.js latest LTS (20.11.0) is installed

Actual behavior:

Node.js older LTS (20.10.0) is installed

History:

Originally reported in #940, but closed without resolution, with @aparnajyothi-y saying that it should be handled on the runner side:

@aparnajyothi-y in comment 2247503445: cache eviction should not be handled on the runner side

In speaking with the runner images team, @hemanthmanga mentioned it should not be handled on the runner side:

@hemanthmanga in comment 2263151956: As the runner images team, we believe cache eviction should be handled through tasks, not the runner itself

[mahabaleshwars]

Hi @karlhorky,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.

[gowridurgad]

Hi @karlhorky, Thank you for reporting this issue. Based on your logs, it seems that although you have set check-latest: true in your YAML configuration, the logs show that the workflow is running with check-latest: false. This discrepancy has led to the installation of Node.js v22.13.0, the version cached on the virtual machine (VM), instead of the latest version, v22.13.1. Typically, the VM cache is up-to-date, and in the worst-case scenario, it can be 2-3 days old. When check-latest: true is passed, the action bypasses the VM cache and downloads the latest version directly from versions-manifest.json. Thus, using version: lts/* with check-latest: true should provide the exact behaviour you expect.

We have tested the setup with check-latest: true, and it successfully picks up the latest LTS version. Additionally, with check-latest: false, the action now resolves to the latest LTS version as well, as the VM cache has been updated to include the latest release. For your reference, we have attached a screenshots.

If you have any further questions or need additional support, please feel free to reach out to us.
Screenshot1: check-latest: false

Screenshot2: check-latest: true

[karlhorky]

@gowridurgad Thanks for the answer.

When check-latest: true is passed, the action bypasses the VM cache and downloads the latest version directly from versions-manifest.json

This is incorrect - the bug also occurs with check-latest: true:

      - uses: actions/setup-node@v4
        with:
          node-version: 'lts/*'
          check-latest: true

logs:

Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: true
    token: ***
  ...
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/22.13.0/x64
Environment details
  node: v22.13.0
  npm: 10.9.2
  yarn: 1.22.22

To reproduce this, what you need is a stale, out-of-date cache and a new version that has been released.

it can be 2-3 days old

This is also incorrect - I've observed delay times of up to 5 days.

We have tested the setup with check-latest: true, and it successfully picks up the latest LTS version

Probably your tests are not reproducing the behavior correctly - you will require a stale, out-of-date cache and a new version that has been released in the last days.

If you can provide steps on how we can reproduce such a situation (eg. what steps we need to perform to insert outdated information in hostedtoolcache), I'm sure that we can together easily find a reproduction of this security bug.

[gowridurgad]

Hi @karlhorky, Thank you for your response. When the check-latest: true option is passed, the action ensures it bypasses the VM cache and directly downloads the latest version from the versions-manifest.json. You can find more details in the setup-node documentation. Typically, the versions-manifest.json file is updated within 1–2 working days after a new version is released, provided there are no unforeseen issues or failures. This ensures timely access to new versions for users relying on the check-latest: true option. However, the hosted tool cache updates follow the image update schedule maintained in the runner-images repository. During this time, while the tool cache update is in progress, the check-latest: true option compensates by directly fetching the latest version from the manifest, enabling users to access the most recent version without waiting for the image update.
To illustrate, regarding the recent PR #196 merged on January 22, the following behavior was observed: Before the PR was merged, using the check-latest option on January 21 fetched Node.js version 22.13.0. After the PR was merged, using check-latest on January 23 fetched the latest version 23.13.1 as defined in the updated versions-manifest.json. This highlights the role of check-latest: true in ensuring the latest version is fetched directly, even before the hosted tool cache reflects the change during the image update.
If you have further questions or need assistance, feel free to reach out, and we’ll do our best to assist.

[karlhorky]

To illustrate, regarding the recent PR #196 merged on January 22

This page is 404, did you mean to link something else?

Typically, the versions-manifest.json file is updated within 1–2 working days after a new version is released, provided there are no unforeseen issues or failures.

This has been demonstrated to be incorrect, with delays of up to 4 or 5 days, which is not really timely anymore.

Even 1 or 2 days is problematic.

[karlhorky]

@gowridurgad what about offering a default-fresh option for users (as fast as nvm for new version updates), with the default configuration that is recommended to users?

Eg. currently, the first "Basic" example in the readme is this:

steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
  with:
    node-version: 18
- run: npm ci
- run: npm test

It would be great if the default settings of actions/setup-node would not be 4 or 5 day delay on new updates (or even 1 or 2), but rather: as fast as nvm.

Good defaults out of the box with immediate access to security updates is something that I think is important to users.

[gowridurgad]

Hi @karlhorky, Thank you for pointing out the incorrect link in our previous comment. We’ve updated the comment with the correct link now. Apologies for the oversight.
As a follow-up to our earlier explanation, we would like to provide further clarification on the behaviour of the check-latest option:

After the new version was released, we merged the corresponding PR #197 on the same day. Before the PR was merged, the check-latest: true option fetched Node.js version 20.18.2 as shown in screenshot 1. After the PR merge, it fetched the updated version 20.18.3 as shown in screenshot 2. This shows how the check-latest option dynamically picks up the latest version directly from the versions-manifest.json.

Similarly, after the new version 22.14.0 was released, we merged PR #198 on the same day. Before the PR was merged, the check-latest: true option fetched Node.js version 22.13.1. After the PR merge, it fetched the updated version 22.14.0.

These examples demonstrate that the check-latest option ensures it fetches the most recent version directly from the versions-manifest.json, even before the hosted tool cache reflects the update. This behaviour allows users to access the latest version without delay, regardless of the image update schedule.

Please let me know if you have further questions or need additional details. We're here to help!

Screenshot 1:

Screenshot 2:

[karlhorky]

After the new version was released, we merged the corresponding PR #197 on the same day. Before the PR was merged, the check-latest: true option fetched Node.js version 20.18.2 as shown in screenshot 1. After the PR merge, it fetched the updated version 20.18.3 as shown in screenshot 2. This shows how the check-latest option dynamically picks up the latest version directly from the versions-manifest.json.

Similarly, after the new version 22.14.0 was released, we merged PR #198 on the same day. Before the PR was merged, the check-latest: true option fetched Node.js version 22.13.1. After the PR merge, it fetched the updated version 22.14.0.

These examples demonstrate that the check-latest option ensures it fetches the most recent version directly from the versions-manifest.json, even before the hosted tool cache reflects the update. This behaviour allows users to access the latest version without delay, regardless of the image update schedule.

Ok, then what you're proposing is that with fast enough merging of the PRs by the team, the check-latest: true option does appear to work, at least in those tests provided above. In your tests, did you use a repo that already had a manifest? If not, then this does not prove what you were trying to prove.

What I have observed in the past is that check-latest: true does not update to the latest version, possibly because the PRs were not merged yet, but also possibly because the manifest caching / retrieval system is broken in a subtle way.

Two ideas for making this more bulletproof out of the box for users, regardless of how fast the PRs get merged or whether there is a bug in the manifest system:

1. What about making check-latest: true the default when using an nvm alias?
2. What about getting rid of the manifest + PR merging system (which sometimes fails even with check-latest, as I have observed), and instead downloading the version based on other existing tools like nvm?

Maybe you can agree that users should be able to have a working, updated config out of the box for nvm aliases, with no extra delays introduced by slow PR merging.

[gowridurgad]

Hi @karlhorky, We are marking this issue as blocked for now as we are currently discussing it with our team. Thank you for your patience and understanding.

[MikeMcC399]

lts/* currently uses Node.js 22.13.1

Node.js v22.14.0 was released on Feb 11, 2025, which is now 9 days in the past.

It should be updating much faster than this using default settings:

Run actions/setup-node@v4
  with:
    node-version: lts/*
    always-auth: false
    check-latest: false
    token: ***
Attempt to resolve LTS alias from manifest...
Found in cache @ /opt/hostedtoolcache/node/22.13.1/x64
Environment details
  node: v22.13.1
  npm: 10.9.2
  yarn: 1.22.22

[karlhorky]

@MikeMcC399 thanks for the update!

I've changed the title of the issue to include the "up to 9 days after release" metric.