[Snyk] Security upgrade axios from 1.14.0 to 1.15.0

[maidul98]

Snyk has created this PR to fix 1 vulnerabilities in the npm dependencies of this project.

Snyk changed the following file(s):

• backend/package.json

Vulnerabilities that will be fixed with an upgrade:

	Issue
	HTTP Response Splitting SNYK-JS-AXIOS-15969258

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• Max score is 1000. Note that the real score may have changed since the PR was raised.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

[maidul98]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6847cee1f4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

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 👍 / 👎.

[claude]

🔴 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