Skip to content

[Snyk] Security upgrade axios from 1.14.0 to 1.15.0 #6010

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
maidul98 wants to merge 1 commit into
base: main
Choose a base branch
from
+1 −1
Open

[Snyk] Security upgrade axios from 1.14.0 to 1.15.0 #6010

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion backend/package.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -198,7 +198,7 @@
"argon2": "^0.31.2",
"asn1js": "^3.0.6",
"aws-sdk": "^2.1553.0",
"axios": "^1.12.0",
"axios": "^1.15.0",

Check failure on line 201 in backend/package.json

View check run for this annotation

Claude / Claude Code Review

package-lock.json not updated: axios vulnerability still pinned at 1.14.0 

The PR updates `axios` to `^1.15.0` in `package.json` but does not regenerate `backend/package-lock.json`, which still resolves axios to the vulnerable `1.14.0`. Since CI pipelines and Docker builds use `npm ci` (which installs strictly from the lockfile), the security fix will not take effect until the lockfile is regenerated via `npm install` and committed.
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector Bot Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Regenerate backend lockfile for axios bump

Update backend/package-lock.json alongside this dependency bump: backend/package.json now requests axios@^1.15.0, but the checked-in lockfile still records axios as ^1.12.0 at the root and resolves node_modules/axios to 1.14.0 (backend/package-lock.json:79 and backend/package-lock.json:13232). For lockfile-based install paths (for example npm ci in backend/Dockerfile:23 and backend/Dockerfile:78), this means the security upgrade is not reliably captured in the committed dependency graph and can leave the vulnerable version in build artifacts or force non-reproducible installs.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown

@claude claude Bot Apr 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔴 The PR updates axios to ^1.15.0 in package.json but does not regenerate backend/package-lock.json, which still resolves axios to the vulnerable 1.14.0. Since CI pipelines and Docker builds use npm ci (which installs strictly from the lockfile), the security fix will not take effect until the lockfile is regenerated via npm install and committed.

Extended reasoning...

What the bug is and how it manifests

This PR was opened by Snyk to fix CVE SNYK-JS-AXIOS-15969258 (HTTP Response Splitting, high severity) by upgrading axios from 1.14.0 to 1.15.0. The fix only modifies backend/package.json, changing the version constraint from ^1.12.0 to ^1.15.0. However, backend/package-lock.json — the authoritative source of truth for reproducible installs — was not regenerated and committed alongside this change.

The specific code path that triggers it

The lockfile (lockfileVersion 3) has two relevant stale entries: (1) the root dependencies section still lists "axios": "^1.12.0" rather than the new ^1.15.0, and (2) the node_modules/axios entry resolves to exactly version 1.14.0 with the corresponding 1.14.0 tarball URL. These two entries together mean the lockfile is internally consistent — but anchored to the wrong, vulnerable version.

Why existing code doesn't prevent it

npm ci — the standard install command used in CI/CD pipelines and Docker builds throughout this repository — ignores package.json version ranges entirely and installs whatever the lockfile specifies. It will fail if the lockfile is absent but will not upgrade packages to satisfy updated package.json ranges. Furthermore, the Snyk check in the PR timeline passed because Snyk evaluated the updated package.json constraint, not the actual resolved lockfile version that will be installed.

What the impact would be

Every reproducible build — Docker images built from backend/Dockerfile, Dockerfile.standalone-infisical, Dockerfile.fips.standalone-infisical, and any CI workflow that runs npm ci — will continue installing axios 1.14.0. The HTTP Response Splitting vulnerability (SNYK-JS-AXIOS-15969258) therefore remains exploitable in all deployed artifacts, defeating the entire purpose of this security PR.

How to fix it

Run npm install from the backend/ directory (which will resolve axios to ≥1.15.0 per the updated constraint and update the lockfile accordingly), then commit the regenerated backend/package-lock.json alongside this PR.

Step-by-step proof

  1. PR changes package.json line 201: "axios": "^1.12.0" → "axios": "^1.15.0"
  2. package-lock.json node_modules/axios entry (line ~13231): "version": "1.14.0", "resolved": "https://registry.npmjs.org/axios/-/axios-1.14.0.tgz" — unchanged
  3. Docker build runs: RUN npm ci → npm reads lockfile, installs axios@1.14.0 exactly
  4. Installed version 1.14.0 is still affected by SNYK-JS-AXIOS-15969258
  5. Result: the deployed service is still vulnerable, despite Snyk marking the PR as a fix

"axios-ntlm": "^1.4.4",
"axios-retry": "^4.0.0",
"bcrypt": "^5.1.1",
Expand Down
Loading