Skip to content

Request for explicit disclosure on Axios supply chain exposure via Serverless installs #13479

@geopaully

Description

@geopaully

During the March 31 Axios supply chain incident, malicious versions (1.14.1 / 0.30.4) were briefly published to npm and executed code at install time.

In serverless@4.33.0, axios was declared as:

"axios": "^1.13.5"

This range allows 1.14.1, which means any fresh install during the exposure window could have resolved to the compromised version.

In addition, common usage patterns (including those shown in Serverless docs and widely used in CI) involve runtime installs such as:

npm i -g serverless

This install path:

  • does not use a lockfile
  • resolves dependencies live from npm
  • is not protected by application package-lock.json

Based on this, it appears that:

  • users performing fresh installs during the incident window were plausibly exposed via transitive dependencies
  • this exposure would not be visible in application-level lockfiles
  • the risk existed specifically in tooling/install paths, not just application dependencies

Recent releases (4.33.1–4.33.3) include:

  • pinning axios
  • adding shrinkwrap / locking transitive dependencies
  • installer hardening

These changes strongly suggest that prior versions allowed floating dependency resolution.

Questions:

  1. Can you confirm whether serverless@4.33.0 installs during the incident window could resolve axios@1.14.1?
  2. Can you clarify which install paths (global install, npx, runtime tarball, etc.) were affected?
  3. Do you consider users who performed fresh installs during that window to have been at risk of executing the malicious postinstall?
  4. Will there be an explicit advisory to users describing this exposure and recommended remediation steps (for example credential rotation)?
  5. What is the officially recommended CI installation pattern going forward to avoid runtime dependency resolution?

This is not about blame. It is about ensuring users understand whether they were exposed and what actions they should take.

Given the nature of the attack (install-time execution and potential credential access), clear communication here is important.

Context

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions