fix: update Axios lockfile for security advisories

[natansil]

Summary

• raise the direct Axios dependency range from ^1.17.0 to ^1.18.1 so published SDK consumers cannot resolve a vulnerable Axios release
• update the lockfile resolution from Axios 1.17.0 to 1.18.1
• avoid unrelated dependency, source, formatting, and workflow changes

Context

The production dependency audit currently fails on both:

• PR run: https://github.com/base44/javascript-sdk/actions/runs/29830541107/job/88633948306?pr=236
• main run: https://github.com/base44/javascript-sdk/actions/runs/29828398144

npm audit --omit=dev --audit-level=high reports multiple high-severity advisories against the directly installed axios@1.17.0. Axios 1.18.0 contains the fixes, but it is not available from the npm registry; 1.18.1 is the smallest available patched release.

Dependency change

• Dependency: axios (direct production dependency)
• Old declared range: ^1.17.0
• New declared range: ^1.18.1
• Old resolved version: 1.17.0
• New resolved version: 1.18.1

Updating the declared lower bound is necessary because consumers of the published SDK do not use this repository's lockfile.

Validation

• npm ci — passed in the Security Audit, Unit Tests, and Lint workflows
• npm audit --omit=dev --audit-level=high — passed; found 0 vulnerabilities
• npm run test:unit — passed
• npm run lint — passed
• npm run build (tsc) — passed in the preview workflow
• git diff --check — passed
• final dependency/lockfile diff review — passed; only the Axios declaration and Axios lockfile metadata changed

Checks: https://github.com/base44/javascript-sdk/pull/237/checks

Remaining audit findings

The report-only full npm audit still reports 2 high-severity dev-only findings:

• brace-expansion (GHSA-3jxr-9vmj-r5cp)
• js-yaml (GHSA-52cp-r559-cp3m)

They do not affect npm audit --omit=dev and are intentionally outside this focused production Axios remediation.

[claude]

Claude finished @natansil's task —— View job

---

Code Review — PR #237 (Axios lockfile security update)

• Read package.json to verify declared Axios range
• Review the package-lock.json diff
• Assess security, correctness, and scope
• Post review feedback

---

Verdict: LGTM ✅ — This is a clean, minimal, and correct security remediation.

What the change does

The only modification is in package-lock.json:1779, bumping the resolved axios version, tarball URL, and integrity hash:

"node_modules/axios": {
-  "version": "1.17.0",
-  "resolved": ".../axios-1.17.0.tgz",
-  "integrity": "sha512-J8SwNxprqqpbfene...",
+  "version": "1.18.1",
+  "resolved": ".../axios-1.18.1.tgz",
+  "integrity": "sha512-3nTvFlvpn9Zu/Rk...",

Correctness ✅

• package.json:29 declares "axios": "^1.17.0", which per semver admits 1.18.1. No package.json change is needed, and correctly none was made.
• There is exactly one axios entry in the lockfile (verified — no nested/duplicate installs), so this single update fully covers the dependency tree.
• The integrity hash and resolved URL were updated alongside the version, keeping the lockfile internally consistent. Good.

Security ✅

• Bumping to a patched release is the appropriate fix for the reported high-severity advisories. Choosing 1.18.1 (smallest available patched release, since 1.18.0 isn't published) is a sensible, conservative choice.
• The dependencies block for axios (follow-redirects: ^1.16.0, etc.) is unchanged in range, which is expected.

Scope ✅

• Correctly lockfile-only. No source, formatting, or workflow changes — keeps the diff auditable and low-risk.

Suggestions / follow-ups (non-blocking)

1. Verify integrity hash authenticity. Since the PR body notes the local registry served stale metadata and npm ci didn't complete locally, it's worth confirming the CI npm ci / audit jobs pass green before merge — that validates the new integrity hash resolves against the real registry. This is the main thing I'd gate the merge on given the validation was marked "pending" in the description.
2. Dev-only findings. The remaining brace-expansion / js-yaml advisories are dev-dependencies and correctly out of scope for a production-audit fix. Reasonable to defer; consider a separate follow-up PR or letting Dependabot handle them.
3. Consider npm audit signatures in CI (if not already) to catch tampered integrity hashes in future lockfile-only PRs.

No bugs, no performance concerns, and no test coverage changes needed for a lockfile-only bump. Nice, focused PR.
• Branch: agent/fix-axios-vulnerabilities

[github-actions]

🚀 Package Preview Available!

---

Install this PR's preview build with npm:

npm i @base44-preview/sdk@0.8.39-pr.237.30e00b4

Prefer not to change any import paths? Install using npm alias so your code still imports @base44/sdk:

npm i "@base44/sdk@npm:@base44-preview/sdk@0.8.39-pr.237.30e00b4"

Or add it to your package.json dependencies:

{
  "dependencies": {
    "@base44/sdk": "npm:@base44-preview/sdk@0.8.39-pr.237.30e00b4"
  }
}

• 📦 Preview Package: @base44-preview/sdk@0.8.39-pr.237.30e00b4
• 🔗 View this commit on GitHub

---

_{Preview published to npm registry — try new features instantly!}

[claude]

Claude finished @natansil's task —— View job

---

Code Review — PR #237 (Axios security update)

• Read package.json
• Review package-lock.json diff
• Assess security, correctness, scope
• Post review feedback

---

Verdict: LGTM ✅ — Clean, minimal, correct security remediation.

Changes

• package.json:29 — axios range raised ^1.17.0 → ^1.18.1
• package-lock.json — root dep range + the single axios node (version, resolved, integrity) bumped 1.17.0 → 1.18.1

Total: +5/-5 across the two files. This aligns exactly with the PR description.

Correctness ✅

• Both the manifest range and lockfile are updated consistently. Raising the declared lower bound is the right call — published SDK consumers don't inherit this repo's lockfile, so bumping only the lockfile would leave downstream installs able to resolve the vulnerable 1.17.0.
• Verified there is exactly one axios entry in the lockfile (package-lock.json:1778), so no nested/duplicate installs remain on the old version.
• integrity and resolved were updated alongside version, keeping the lockfile internally consistent.
• 1.18.1 satisfies the new ^1.18.1 range, and the transitive follow-redirects: ^1.16.0 range is unchanged (expected).

Security ✅

• Bumping to a patched release is the appropriate fix for the reported high-severity advisories against axios@1.17.0. Selecting 1.18.1 (smallest available patched release since 1.18.0 isn't published) is a sensible, conservative choice.

Scope ✅

• Only dependency metadata touched — no source, formatting, or workflow changes. Keeps the diff auditable and low-risk.

Follow-ups (non-blocking)

1. Gate merge on green CI. The main thing worth confirming is that the CI npm ci + npm audit --omit=dev --audit-level=high jobs pass — that validates the new integrity hash resolves against the real registry and that the production audit is clean.
2. Dev-only findings (brace-expansion GHSA-3jxr-9vmj-r5cp, js-yaml GHSA-52cp-r559-cp3m) are correctly out of scope for a production-audit fix. Reasonable to defer to a separate PR / Dependabot.
3. Consider adding npm audit signatures to CI to catch tampered integrity hashes in future lockfile-only PRs.

No bugs, no performance concerns, and no test coverage changes needed for a dependency bump. Nicely focused PR.

View job • Branch: agent/fix-axios-vulnerabilities