fix(core): upgrade axios to 1.12.0 to address CVE-2025-58754

[terrymun]

Current Behavior

Nx is currently using a vulnerable version of axios (<1.12.0) which has a reported high-level vulnerability CVE-2025-58754. This is being flagged by GitHub Advanced Security on a Nx-powered monorepo:

Expected Behavior

Nx should be using a patched version of axios (≥1.12.0) that addresses said vulnerability.

Related Issue(s)

Fixes #

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Updated (UTC)
nx-dev	Ready	Preview	Oct 6, 2025 8:51am

[nx-cloud]

View your CI Pipeline Execution ↗ for commit f6bfe1c

Command	Status	Duration	Result
nx affected --targets=lint,test,test-kt,build,e...	✅ Succeeded	33m 20s	View ↗
nx run-many -t check-imports check-commit check...	✅ Succeeded	2m 29s	View ↗
nx-cloud record -- nx-cloud conformance:check	✅ Succeeded	2s	View ↗
nx-cloud record -- nx format:check	✅ Succeeded	5s	View ↗
nx-cloud record -- nx sync:check	✅ Succeeded	5s	View ↗
nx documentation	✅ Succeeded	1m 28s	View ↗

---

☁️ Nx Cloud last updated this comment at 2025-10-06 10:02:10 UTC

[JamesHenry]

Naturally a DOS vulnerability is not relevant to Nx at all but we can get this merged to help with noise on your end.

[terrymun]

@JamesHenry I totally agree. Just feel like it's always a good idea to address security advisories even though Nx doesn't have a public-facing API so a DOS attack vector is not relevant here.

[JamesHenry]

@terrymun Sorry you need to redo your commit to match the required conventions (you can see what I did to the PR title). We have a precommit hook to catch this so you must have bypassed it?

[terrymun]

@JamesHenry Whoops, my bad! I pushed with --no-verify because of a Git LFS warning that I couldn't get rid of (even after deleting the pre-push hook locally).

[FrozenPandaz]

Changes look good to me.. the CI failures look unrelated other than the commit message? Hopefully it passes once you update your commit 🤞

[terrymun]

@FrozenPandaz @JamesHenry Thanks for the tips. I've fixed the incorrect commit message and pushed. Hope it will pass CI checks now :)

[JamesHenry]

@terrymun If you hit some flake again better to ping us to rerun rather than force push up, because the workflows won't run without our approval anyway

[terrymun]

@JamesHenry Apologies for the force push. The linting tests are still failing tho, and I'm not sure what I can do to fix them.

[JamesHenry]

@terrymun It's not so much that it's a force push, more so that we are just likely to miss it unless you ping us. This lock file change seems to have dragged rspack along and it's causing type errors now. @Coly010 will look into it

[JamesHenry]

@terrymun I believe the rspack issues were addressed, please could you resolve the conflicts (sorry about that)

[netlify]

‼️ Deploy request for nx-docs rejected.

Name	Link
🔨 Latest commit	40a67d4

[JamesHenry]

@terrymun I have rebased and addressed the conflicts for you so that this can proceed

[nx-cloud]

Nx Cloud has identified a possible root cause for your failed CI:

Analysis of PR Intent:
The pull request upgrades axios from version ^1.8.3 to ^1.12.0 across the Nx monorepo to address CVE-2025-58754, a high-severity security vulnerability. The changes update axios dependencies in the root package.json, packages/create-nx-workspace, and packages/nx, along with the corresponding pnpm-lock.yaml updates.

Failure Classification and Reasoning:

1. Rspack Build Failures (examples-angular-rspack-zoneless-csr-i18n:build, examples-angular-rspack-csr-i18n:build):

The error "The 'compilation' argument must be an instance of Compilation. This usually occurs when multiple versions of '@rspack/core' are used" explicitly indicates a dependency version conflict issue. Examining the pnpm-lock.yaml changes reveals that the axios upgrade triggered pnpm to resolve multiple versions of @rspack/core (1.5.0 and 1.5.2) in the dependency tree.

This is classified as 'environment_state' because:

• The error message explicitly states it's caused by multiple @rspack/core versions
• The failure is in build tooling dependency resolution, not application code
• The axios upgrade inadvertently affected transitive dependency resolution
• This is a side effect of the package manager's resolution algorithm
• No code logic was changed that would cause Rspack compilation to fail

The proper fix would be to ensure @rspack/core is pinned to a single version across the workspace, but this is a dependency management issue, not a code issue introduced by the security patch.

2. E2E Test Failure (e2e-angular:e2e-ci--src/cypress-component-tests-app.test.ts):

The error "listen EADDRINUSE: address already in use 127.0.0.1:8080" is a port conflict error where the test attempts to bind to a port that's already occupied.

This is classified as 'flaky_task' because:

• Port conflicts are classic flaky test symptoms related to improper test cleanup or timing
• The error has no logical connection to upgrading axios (an HTTP client library)
• This type of error typically occurs when previous test processes haven't fully terminated
• The failure is environmental/timing-dependent, not deterministic

Conclusion:
No code changes are warranted. The Rspack build failures are caused by dependency resolution side effects that require dependency management fixes, not code fixes. The E2E test failure is a flaky test infrastructure issue unrelated to the security upgrade. The axios security patch itself is valid and necessary.

A code change would likely not resolve this issue, so no action was taken.

View in Nx Cloud ↗

_{⚙️ An Nx Cloud workspace admin can disable these reviews in workspace settings.}

[github-actions]

This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request.