fix: remove babel-traverse@6 (CVE-2023-45133) by replacing cross-var

[Copilot]

babel-traverse@6.26.0 (CVE-2023-45133, GHSA-67hx-6x53-jw92, critical) was a transitive devDependency via cross-var@1.1.0 → babel-register → babel-core → babel-traverse@6. Babel 6 is EOL with no patched version; the only fix is eliminating the dependency chain.

Changes

• scripts/cross-var.js — minimal drop-in replacement for cross-var using only Node.js built-ins (child_process.spawnSync). Substitutes $VAR_NAME patterns in arguments from process.env, providing identical cross-platform behavior.
• package.json — removed cross-var from devDependencies; replaced all 18 invocations in npm scripts with node scripts/cross-var.js.
• package-lock.json — regenerated; babel-traverse no longer present.

Reachability Assessment

Not actively exploitable (high confidence). The vulnerable path.evaluate() / path.evaluateTruthy() APIs are only triggered by Babel compilation plugins (@babel/plugin-transform-runtime, @babel/preset-env, polyfill providers). This project compiles via tsc and esbuild — Babel is never invoked as a compilation pipeline. cross-var only used Babel to transpile its own internals, never touching user code. Risk is theoretical; fix eliminates the dependency entirely.

Original prompt

---

This section details the Dependabot vulnerability alert you should resolve

<alert_title>Babel vulnerable to arbitrary code execution when compiling specifically crafted malicious code</alert_title>
<alert_description>### Impact

Using Babel to compile code that was specifically crafted by an attacker can lead to arbitrary code execution during compilation, when using plugins that rely on the path.evaluate()or path.evaluateTruthy() internal Babel methods.

Known affected plugins are:

• @babel/plugin-transform-runtime
• @babel/preset-env when using its useBuiltIns option
• Any "polyfill provider" plugin that depends on @babel/helper-define-polyfill-provider, such as babel-plugin-polyfill-corejs3, babel-plugin-polyfill-corejs2, babel-plugin-polyfill-es-shims, babel-plugin-polyfill-regenerator

No other plugins under the @babel/ namespace are impacted, but third-party plugins might be.

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/traverse@7.23.2.

Babel 6 does not receive security fixes anymore (see Babel's security policy), hence there is no patch planned for babel-traverse@6.

Workarounds

• Upgrade @babel/traverse to v7.23.2 or higher. You can do this by deleting it from your package manager's lockfile and re-installing the dependencies. @babel/core >=7.23.2 will automatically pull in a non-vulnerable version.
• If you cannot upgrade @babel/traverse and are using one of the affected packages mentioned above, upgrade them to their latest version to avoid triggering the vulnerable code path in affected @babel/traverse versions:
  • @babel/plugin-transform-runtime v7.23.2
  • @babel/preset-env v7.23.2
  • @babel/helper-define-polyfill-provider v0.4.3
  • babel-plugin-polyfill-corejs2 v0.4.6
  • babel-plugin-polyfill-corejs3 v0.8.5
  • babel-plugin-polyfill-es-shims v0.10.0
  • babel-plugin-polyfill-regenerator v0.5.3</alert_description>

critical
GHSA-67hx-6x53-jw92, CVE-2023-45133
babel-traverse
npm
<vulnerable_versions>6.26.0</vulnerable_versions>
<patched_version></patched_version>
<manifest_path>package-lock.json</manifest_path>

https://github.com/babel/babel/security/advisories/GHSA-67hx-6x53-jw92 https://nvd.nist.gov/vuln/detail/CVE-2023-45133 https://github.com/babel/babel/pull/16033 https://github.com/babel/babel/commit/b13376b346946e3f62fc0848c1d2a23223314c82 https://github.com/babel/babel/releases/tag/v7.23.2 https://github.com/babel/babel/releases/tag/v8.0.0-alpha.4 https://www.debian.org/security/2023/dsa-5528 https://lists.debian.org/debian-lts-announce/2023/10/msg00026.html https://babeljs.io/blog/2023/10/16/cve-2023-45133 https://github.com/advisories/GHSA-67hx-6x53-jw92

<agent_instructions>please go through the issues mentioned here, identify all issues, and assess whether they can be fixed.
Recommend the necessary changes.
If it is not a breaking change, let's log the issue.
Please verify all test cases and validate the runs.
</agent_instructions>

<task_instructions>Resolve this alert by updating the affected package to a non-vulnerable version. Prefer the lowest non-vulnerable version (see the patched_version field above) over the latest to minimize breaking changes. Include a Reachability Assessment section in the PR description. Review the alert_description field to understand which APIs, features, or configurations are affected, then search the codebase for usage of those specific items. If the vulnerable code path is reachable, explain how (which files, APIs, or call sites use the affected functionality) and note that the codebase is actively exposed to this vulnerability. If the vulnerable code path is not reachable, explain why (e.g. the affected API is never called, the vulnerable configuration is not used) and note that the update is primarily to satisfy vulnerability scanners rather than to address an active risk. If the advisory is too vague to determine reachability (e.g. 'improper input validation' with no specific API named), state that reachability could not be determined and explain why. Include a confidence level in the reachability assessment (e.g. high confidence if the advisory names a specific API and you confirmed it is or is not called, low confidence if the usage is indirect and hard to trace). If no patched version is available, check the alert_description field for a Workarounds section — the advisory may describe configuration changes or usage patterns that mitigate the vulnerability without a version update. If a workaround is available, apply it and leave a code comment referencing the advisory identif...

• Resolves Azure/Azurite alert Typescript Migration! #62

[jainakanksha-msft]

@copilot

1. if there is any build issue fix that
2. Run though test cases and validate the changes fully if it impacts the code
3. Update the Changelist

[Copilot]

@copilot

1. if there is any build issue fix that
2. Run though test cases and validate the changes fully if it impacts the code
   ...

Done in commit fix: remove deprecated tsconfig options and update ChangeLog:

1. Build issue fixed — removed deprecated moduleResolution: "node" and downlevelIteration: true from tsconfig.json (both removed in TypeScript 7). Build now passes cleanly with tsc (TS 5.9.2).

2. Tests validated — 50 queue @loki tests and blob authentication tests all pass against the updated codebase.

3. ChangeLog updated — added entries under "Upcoming Release" for the cross-var / CVE-2023-45133 security fix and the tsconfig.json cleanup.

[jainakanksha-msft]

@copilot, fix the conflict issues in the PR.

[Copilot]

@copilot, fix the conflict issues in the PR.

Merge conflicts resolved in commit f1e020a:

• ChangeLog.md: both entry sets (cross-var/CVE fix and @typescript-eslint/parser bump) are now included
• package-lock.json: regenerated to incorporate both branches' dependency changes — cross-var/babel-traverse absent, @typescript-eslint/parser 8.65.0 and jsonwebtoken 9.0.3 present

[jainakanksha-msft]

@copilot, are there any other ways to fix this besides a self-maintained script that may not stay up to date over time?
Could you list all the options, along with their pros and cons?

[Copilot]

Pull request overview

This PR removes the vulnerable Babel 6 transitive devDependency chain (cross-var → babel-register → babel-core → babel-traverse@6) by replacing cross-var usage with a small in-repo Node.js script, and updates npm scripts/lockfile accordingly to eliminate babel-traverse@6.

Changes:

• Added scripts/cross-var.js to perform $VAR_NAME expansion using process.env and spawnSync.
• Updated package.json scripts to invoke node scripts/cross-var.js instead of cross-var, and removed cross-var from devDependencies.
• Regenerated package-lock.json to remove cross-var and the Babel 6 subtree; also removed a couple of now-redundant tsconfig.json options and documented the changes in ChangeLog.md.

Reviewed changes

Copilot reviewed 3 out of 5 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
tsconfig.json	Removes explicit options that are redundant with the current module/target settings.
scripts/cross-var.js	Introduces an in-repo replacement for cross-var to expand $VAR_NAME values before spawning a command.
package.json	Drops cross-var dependency and rewrites scripts to use the new Node-based wrapper.
package-lock.json	Removes cross-var and its Babel 6 dependency chain from the lockfile.
ChangeLog.md	Documents the dependency removal and related config cleanup.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@copilot, are there any other ways to fix this besides a self-maintained script that may not stay up to date over time?
Could you list all the options, along with their pros and cons?

Yes. The practical alternatives I see are:

1. Use cross-env-shell (already in this repo)

   • Pros: no new dependency, maintained package, supports $npm_package_version across Windows/Linux/macOS, smallest change from the current scripts.
   • Cons: requires quoting whole inline commands, uses a shell so escaping/quoting is trickier, and long Docker commands become harder to read/debug.

2. Move the affected npm scripts into dedicated Node entrypoints

   • Pros: no extra dependency, uses only built-ins, easiest to unit-test and extend, avoids shell-escaping issues.
   • Cons: more churn than this security fix, more files/logic to maintain than a tiny wrapper.

3. Adopt another maintained package that does cross-platform variable expansion

   • Pros: offloads maintenance to the package author.
   • Cons: adds another dependency to review, could reintroduce a vulnerable transitive chain later, and would still need validation for Windows behavior.

4. Change the workflow so scripts don’t rely on inline $npm_package_version expansion

   • Pros: removes the root need for a cross-platform expander.
   • Cons: larger behavior/workflow change, likely touches CI/release scripts, and is more invasive than the original security fix.

My recommendation would be option 1 (cross-env-shell) if we want to avoid a self-maintained script with minimal churn, or option 2 if we want the most explicit long-term implementation and are okay with a broader refactor.

[jainakanksha-msft]

@copilot, with option 1, I’m wondering whether the current docker script would run into any issues.
Would the docker commands end up being too long?
Do we expect quoting to be a problem?

[Copilot]

@copilot, with option 1, I’m wondering whether the current docker script would run into any issues.
Would the docker commands end up being too long?
Do we expect quoting to be a problem?

I don’t expect command length to be the blocker here. These Docker scripts are only ~260–330 characters even if converted to cross-env-shell, which is comfortably below the usual Windows cmd.exe command-line limit.

The bigger concern is quoting, not length:

• cross-env-shell wants the whole inline command quoted.
• Our current Docker scripts also contain quoted "Dockerfile" / "Dockerfile.Windows" segments.
• That means the scripts would need a little extra escaping, or we should simplify them by dropping those inner quotes since the filenames have no spaces.

So option 1 is still viable, but I’d treat it as:

• Length: low risk
• Quoting/escaping: moderate risk, but manageable

If we switched to cross-env-shell, I’d recommend rewriting the Docker entries to avoid nested quotes where possible so the scripts stay readable and predictable on Windows.

[jainakanksha-msft]

@copilot, Ok, then please go ahead with option 1.

[jainakanksha-msft]

@copilot , Ok, then please go ahead with option 1.

[Copilot]

@copilot, Ok, then please go ahead with option 1.

Addressed in 736ffcc.

Switched the affected npm scripts to cross-env-shell, removed the in-repo scripts/cross-var.js wrapper, and updated the changelog text. I also validated the change by installing dependencies, building successfully, and dry-running the updated Docker scripts with a stubbed docker command to confirm $npm_package_version expansion and chained command behavior.

@copilot , Ok, then please go ahead with option 1.

Addressed in 736ffcc.

Switched the affected npm scripts to cross-env-shell, removed the in-repo scripts/cross-var.js wrapper, and updated the changelog text. I also validated the change by installing dependencies, building successfully, and dry-running the updated Docker scripts with a stubbed docker command to confirm $npm_package_version expansion and chained command behavior.