[GHSA-rm8p-cx58-hcvx] Axios has Transitive Critical Vulnerability via form-data — Predictable Boundary Values (CVE-2025-7783)

[mhassan1]

Updates

• Affected products

Comments
I'm confused by this advisory. I understand that form-data has a critical vulnerability, but I don't understand why that translates to an advisory for axios, or why this advisory is only for axios@1.10.0 (and not other versions). The dependency in axios@1.10.0 is "form-data": "^4.0.0" (note the caret), and axios doesn't bundle the vulnerable form-data code, so there's no vulnerability in axios.

If I follow the PoC in this advisory (npm install axios@1.10.0 --save-exact), I end up with form-data@4.0.4, which is not vulnerable.

I think this advisory should be withdrawn.

[github]

Hi there @jasonsaayman! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[izzygld]

Appreciate the response — and totally get the confusion. This isn’t about Axios bundling vulnerable code or being directly exploitable, but about real-world impact due to how package resolution actually plays out in practice.

Yes, Axios uses "form-data": "^4.0.0", and technically that can resolve to 4.0.4 — but that assumes a fresh install, an up-to-date lockfile, no caching, and a little bit of luck. In practice:
• Projects using axios@1.10.0 with older lockfiles do resolve to form-data@4.0.0
• Snyk flags this as a critical vulnerability in any project using axios@1.10.0
• This leads to failing CI pipelines, blocked GitHub Action deploys, and teams scrambling to debug “why is our build suddenly red?”

So while Axios itself isn’t “vulnerable code,” it does expose a critical transitive vulnerability, and Snyk treats it as such. And when CI/CD workflows break in large orgs, it’s not a hypothetical problem — it’s Monday morning chaos.

The reason the advisory is scoped to 1.10.0 is because 1.11.0 and above explicitly resolve to safe form-data versions, so the problem doesn’t apply there. If anything, this advisory serves as a very targeted heads-up for teams stuck on 1.10.0 and wondering why their security scan suddenly flipped a table.

To be fair — maybe the advisory could’ve been worded more clearly to reflect that Axios isn’t the root cause. But suggesting full withdrawal is like saying “npm always behaves predictably.” We all know better. 😉

[mhassan1]

@izzygld I understand the reasoning, but I don't think I've ever seen an advisory like this. I think it sets a precedent that all vulnerabilities in transitive dependencies should trigger advisories in all dependent packages, which would create a huge amount of noise; currently, form-data has 11K+ direct dependents (which doesn't include its indirect dependents), and we wouldn't want to create advisories for all of those.

Currently, Snyk shows no issue with axios@1.10.0: https://snyk.io/advisor/npm-package/axios.

My point about only including axios@1.10.0 is that, assuming this advisory is valid, it should include every axios version that depends on "form-data": "^4.0.0", which goes all the way back to axios@0.30.0 and earlier.

Developers should already know how to bump transitive dependency versions in their lockfiles. If they don't, the advisory system is not the way to teach them that.

[ljharb]

A vulnerability in a transitive dependency, when it's depended on with a semver range that leads to a fixed version, is not a vulnerability in the thing.

In other words, this is objectively not a vulnerability in axios, only in form-data. There should not be an advisory on anything that depends on form-data, as long as it uses a semver range that includes the fixed version.

[izzygld]

You are 100% correct semantically:

A vulnerability in a transitive dependency, when depended on via a semver range that includes the patched version, is not technically a vulnerability in the parent package.

Yes — Axios is not itself vulnerable. It doesn’t introduce the vulnerability, and it declares the right semver range. That part’s totally fair.

⸻

❌ But in practical security and tooling workflows, that’s not enough.

If a project installs axios@1.10.0, there are many real-world scenarios where it does resolve to the vulnerable form-data@4.0.0, even though the range includes the patch:
• Lockfiles from before the patch (e.g., package-lock.json, yarn.lock, pnpm-lock.yaml)
• CI/CD pipelines restoring cached dependencies
• Offline or proxy registries pinned to older mirrors
• GitHub Action environments using older lockfiles
• Local devs running npm ci on a branch created before the patch

In these situations, Axios effectively pulls in vulnerable behavior. And users — even security-conscious ones — are caught off guard.

⸻

🚨 And the consequence isn’t theoretical:
• Snyk flags projects using axios@1.10.0 (with vulnerable lockfiles) as high severity
• CI pipelines fail — not just warning, but full breakage
• Teams are blocked, sometimes for hours, trying to trace the root cause
• Devs don’t realize axios is indirectly pulling vulnerable behavior because “we didn’t change anything” and “the lockfile passed last week”

So while semver ranges theoretically cover the fix, that doesn’t mean all installations actually get the fixed version. In real-world usage, transitive vulnerabilities leak upward in a way that absolutely impacts the parent package’s users.

⸻

🧠 Why an advisory is still valuable

We’re not saying Axios is broken. We’re saying:
• axios@1.10.0 and earlier can install a critically vulnerable transitive dependency, and that’s non-obvious.
• The problem disappears in axios@1.11.0, which updated the dependency range and effectively patches the issue in practice.
• Calling that out in an advisory gives downstream teams clear remediation: “Upgrade to axios@1.11.0 or manually bump form-data.”

That’s not noise — that’s clarity.

⸻

🔄 Suggested path forward

I’m not married to the advisory as written. If the concern is about over-scoping or setting a bad precedent:
• ✅ Let’s update the advisory title/wording to clarify this is a transitive exposure, not a direct Axios vulnerability.
• ✅ Let’s broaden the version range to earlier Axios versions using form-data@^4.0.0, as suggested.
• ✅ Let’s avoid withdrawing entirely, as that would ignore real breakage for real teams.

⸻

TL;DR

The issue isn’t in Axios, but it affects Axios users. And the fix is simple: move forward to a version that can’t resolve to form-data@4.0.0.

Thanks again for the thoughtful back-and-forth. Happy to collaborate on adjusting the advisory language and scope, but I do believe the intent — and the impact — are valid.

[ljharb]

The CVE system (and GHSA) is about semantics, not practicality. Marking axios as vulnerable is misinformation that isn't necessary. If an application has axios in its graph and NOT a vulnerable version of form-data, that notification is harmful, costly noise that should not exist.

Thus, only the form-data notification should exist.

[mhassan1]

Upgrade to axios@1.11.0 or manually bump form-data.

@izzygld The problem with this is that manually bumping form-data, itself, won't resolve the axios advisory. Users who want to just bump form-data but not upgrade axios will need to dismiss the axios advisory, manually, which will make security teams uncomfortable.

Other ways we can clear up confusion after withdrawing this advisory:

• enhance the form-data advisory to make it clear that axios depends on form-data (although, again, this feels like a slippery slope, since so many packages depend on axios)
• add information to the axios repository (e.g. in a pinned issue) about its dependency on form-data and how users can resolve the form-data vulnerability

[ljharb]

Nobody needs to care if their axios could depend on a uvlnerable version of form-data. Any tooling that warns on the axios advisory will already be warning, or not warning, based on the presence of the vulnerability - which, in practice, is all that matters. What does NOT matter is the theoretical possibility of depending on it/resolving to it in the future.

[orien]

We’re not saying Axios is broken. We’re saying:
• axios@1.10.0 and earlier can install a critically vulnerable transitive dependency, and that’s non-obvious.

By raising a security advisory on Axios. You are saying Axios has a security vulnerability. That’s exactly the message you are broadcasting.

[bobvandevijver]

This advisory is indeed completely unnecessary and not how security advisories are meant to be.

Calling that out in an advisory gives downstream teams clear remediation: “Upgrade to axios@1.11.0 or manually bump form-data.”

This statement is not true, specifically the or part. You cannot solve the axios dependency by upgrading form-data only. Already upgraded form-data this Monday, and now all my pipelines are failing on something that isn't an issue.

Let’s avoid withdrawing entirely, as that would ignore real breakage for real teams.

False again, because if the vulnerability scanner picks up this one, it should already have picked up the form-data one.

This feels like a way to just pump up the "amount of advisories I've created" stat 👎🏻

[orien]

TL;DR

The issue isn’t in Axios, but it affects Axios users. And the fix is simple: move forward to a version that can’t resolve to form-data@4.0.0.

Yes, the release of version 1.11.0 is a responsible action that benefits the community. This action should be sufficient. The security advisory is unnecessary.

[vijeyanidhi]

@izzygld

Since you are marking axios 1.10.0 as vulnerable now, do you plan to mark the packages using axios also as vulnerable using the logic in #5849 (comment) ?

and if you do, it is going to create a lots of un necessary advisories.

The current vulnerability scanners are configured to pick up CVE advisories from different places, scan the bom/lock file and then if there is any vulnerability flag that package.

and when the first form data advisory was out, the scanners would have picked up and forced the devs to use the resolutions/overrides to increase the form data version to get past the CVE.

now this new advisory is basically forcing the scanners to ignore the resolutions/overrides done and even if the pipeline installed axios 1.10.0, it would be using form data 4.0.4

and all of the scenarios listed in #5849 (comment) would be covered because the scanners will be using the lockfile or the bom file to scan and will pick up the form data version and fail the pipeline.

[jasonsaayman]

Hi 👋

Thanks for all the comments. I initially thought it would be a good idea to alert users to bump to 1.11.0 and that made sense to me at the time but I can appreciate how it may have not been the best course of action.

I agree marking a package vulnerable because one of the dependancies are vulnerable can lead to a lot of CVE noise and can be super un-helpful. Is there any way to revoke the CVE at this point?

[pnappa]

We need to be extremely careful with signal:noise ratios in security - this issue is currently ringing the klaxons on codebases which already have the form-data pinned to ^4.0.4. This now requires additional effort on the part of the security team to clear the warnings for a non-affected codebase.

For posterity, I don't recommend using an exact value pin in the overrides for pnpm, as has been suggested earlier in the thread - I'd recommend in the package.json:

  "pnpm": {
    "overrides": {
      "form-data@>=4.0.0 <4.0.4": ">=4.0.4"
    }
  }

Otherwise you could end up with incorrectly forced dependencies installed.

---

As an aside, @izzygld, are you using AI to compose your replies here? The reply here: #5849 (comment) is full of inaccuracies, LLMisms, and restating previously mentioned things - I think it would be good to disclose whether you used an AI tool to converse here.

[izzygld]

Yeah fair enough — I think this got a bit out of hand tbh 😅

And yep, I do use AI to help write sometimes, mainly to clean up or translate since English isn’t my first language. Appreciate you flagging that though.

Thanks also for the tip on the overrides — that’s really helpful.

[mhassan1]

@jasonsaayman I don't think there has been a CVE created, at this point; at least the advisory isn't associated with one.

I think the best course of action would be to withdraw the security advisory from GitHub.

[jasonsaayman]

seems there is a CVE number CVE-2025-54371 however this has been rejected, which is pretty interesting, also it seems at least i cannot withdraw based on the tooling from GitHub

[advisory-database]

Hi @mhassan1! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!

[taladrane]

Hi all 👋 thank you for the thoughtful discussion on this issue. @jasonsaayman the Advisory Database team has withdrawn the advisory. Please let us know if you need anything else!