azure-kusto-data@7.1.0 pins vulnerable axios@1.4.0

[YousefHadder]

Describe the bug
azure-kusto-data@7.1.0 pins its axios dependency to 1.4.0, which is flagged by GitHub dependency review for multiple known vulnerabilities.

This appears to be a regression from azure-kusto-data@7.0.4, which depended on axios using the range ^1.8.4. In 7.1.0, the package metadata now lists:

{
  "axios": "1.4.0"
}

Because this is an exact transitive dependency, downstream consumers cannot update to azure-kusto-data@7.1.0 without introducing vulnerable axios@1.4.0, unless they use package-manager overrides.

To Reproduce
Steps to reproduce the behavior:

1. Create or update a Node project that depends on azure-kusto-data@7.1.0.

2. Install dependencies with npm.

3. Inspect the installed dependency tree:

   npm ls axios
   npm view azure-kusto-data@7.1.0 dependencies --json

4. Run GitHub dependency review or another advisory scanner against the resulting lockfile.

Observed result: azure-kusto-data@7.1.0 installs axios@1.4.0, which is flagged for multiple advisories.

Examples reported by GitHub dependency review:

• GHSA-8hc4-vh64-cxmj — Server-Side Request Forgery in axios
• GHSA-jr5f-v2jv-69x6 — SSRF / credential leakage via absolute URL
• GHSA-4hjh-wcwx-xvwj — DoS through lack of data size check
• GHSA-43fc-jf86-j433 — DoS via __proto__ key in mergeConfig
• GHSA-wf5p-g6vw-rhxx — CSRF vulnerability
• GHSA-fvcv-3m26-pcqx — cloud metadata exfiltration via header injection chain
• GHSA-3p68-rc4w-qgx5 — NO_PROXY hostname normalization bypass leading to SSRF

Expected behavior
azure-kusto-data should depend on a patched axios version/range, ideally similar to or newer than the previous ^1.8.4 range used by azure-kusto-data@7.0.4.

For example, azure-kusto-data@7.1.x could depend on a patched axios range rather than the vulnerable exact version:

{
  "axios": "^1.8.4"
}

or another currently supported patched version.

Screenshots
N/A

Setup (please complete the following information):

• SDK Version: azure-kusto-data@7.1.0
• node version: N/A / reproducible from package metadata
• typescript version: N/A

Browser Setup (please complete the following information):

• framework: N/A
• server env: npm
• browser name/version: N/A

Desktop (please complete the following information):

• OS: N/A
• Version: N/A

Additional context
Package metadata comparison:

npm view azure-kusto-data@7.1.0 dependencies --json

shows:

{
  "axios": "1.4.0"
}

while:

npm view azure-kusto-data@7.0.4 dependencies --json

shows:

{
  "axios": "^1.8.4"
}

This blocks Dependabot updates for downstream repositories that enforce GitHub dependency review, because upgrading from azure-kusto-data@7.0.4 to 7.1.0 introduces vulnerable axios@1.4.0 into package-lock.json.

[kevin-boutin]

Please fix as this exposes critical vulnerabilities. The patched version of axios is 1.7.4

[JoostLambregts]

In general, I think libraries should not pin to a specific version. It is up to library maintainers to specify a supported range, and up to consumers to pin to a version using package-lock.json. When you pin to a specific version, and a vulnerability is discovered in that version, you leave your consumers with no good solution.

The best option though in my opinion is to get rid of the axios dependency entirely and switch to fetch. Node supports fetch natively since v18, and you already only support node >= 20.