security: outdated axios 1.15.0 + joi 17.8.3 pins expose consumers to 4 known CVEs

[knofte]

Summary

The current pins in flutterwave-node-v3@1.3.2 package.json are:

"axios": "1.15.0",
"joi": "17.8.3"

Both pinned to a single exact version rather than a semver range, which means every project that installs this SDK inherits the vulnerabilities of those specific versions with no way to opt into a patched release without an npm overrides hack.

CVEs consumers currently inherit

axios 1.15.0 → three high-severity advisories

• GHSA-4hjh-wcwx-xvwj — shouldBypassProxy doesn't recognize IPv4-mapped IPv6 addresses, allowing NO_PROXY bypass
• GHSA-4hjh-wcwx-xvwj — ReDoS via Cookie Name Injection
• Allocation of Resources Without Limits or Throttling in Axios

Fixed in axios ≥ 1.12.2 (and later patches).

joi 17.8.3 → one moderate

• joi has an uncaught RangeError on deeply nested input through recursive link() schemas — DoS vector for anyone using joi.link() on user input.

Fixed in joi ≥ 17.13.3.

Impact on consumers

We (SnappyHour) are a production consumer of flutterwave-node-v3 for our Kenya M-Pesa payment flow. We currently work around these by overriding transitive versions in our top-level package.json:

"overrides": {
  "@sendgrid/client": "8.1.6",
  "axios": "^1.12.2"
}

This works but has drawbacks:

• Every downstream consumer has to know to do this
• Overrides can silently break if the SDK ever starts relying on a specific axios API removed in a later version
• Newer consumers not aware of the CVEs run vulnerable in production

Suggested fix

Loosen the pins to a semver range that permits patched versions:

"axios": "^1.15.0",
"joi": "^17.8.3"

Or, if there's a reason for the exact pin (I couldn't find one in the repo), bump the exact versions to the latest patched releases (axios@1.13.x LTS, joi@17.15.x).

Either change is non-breaking for existing consumers (semver-compatible upgrade) and unblocks CVE resolution for everyone.

Verification

mkdir /tmp/fw-audit && cd /tmp/fw-audit
npm init -y
npm install flutterwave-node-v3@1.3.2
npm audit

Should show the four CVEs above.

Happy to open a PR with the pin loosening if that would help. Thanks for maintaining the SDK 🙏

—
Filed 2026-07-07 on behalf of a production consumer.

[knofte]

Update 2026-07-07 — thanks for shipping 1.4.1

Two corrections to my original post:

1. Bad version guidance (my mistake)

I wrote 'Fixed in axios ≥ 1.12.2' when your 1.3.2 pin was already 1.15.0. That reads as a downgrade recommendation — nonsensical. Apologies for the confusion.

The correct patched-axios lineage covering the three CVEs I listed is axios ≥ 1.15.2 for the earlier ones and ≥ 1.16.x for the full set. Your 1.4.1 pinning to ^1.17.0 cleanly covers all of them.

2. axios half is resolved in your 1.4.1 🎉

Just upgraded our consumer to flutterwave-node-v3@1.4.1 (released 2026-06-17). Transitive axios now resolves to 1.18.1, and our root package.json overrides block for axios is no longer strictly needed. Thank you.

3. joi 17.8.3 exact pin — still open

Leaving this issue open since the joi side isn't yet addressed. Your 1.4.1 still pins joi: "17.8.3" exactly, and that version has GHSA-q7cg-457f-vx79 — uncaught RangeError on deeply nested link() schemas. Fixed in joi ≥ 17.13.4.

If joi: "^17.8.3" would work for your API surface, that's a one-character change unlocking the patch for downstream. Happy to open the PR if useful.

---

Also worth noting for downstream consumers reading later: if you're on flutterwave-node-v3 ^1.3.x, npm install won't jump you to 1.4.x automatically — semver-major stays at 1 but the caret in ^1.3.x sometimes has weird interaction with lockfiles. Explicit npm install flutterwave-node-v3@^1.4.1 picks up the fix.

[knofte]

@corneliusyaovi For your info*