Notifications
Clear all
Topic starter
20/08/2026 5:50 pm
TL;DR: A high-severity flaw in axios CVE-2026-44488 let the fetch adapter ignore configured maxContentLength and maxBodyLength limits, so attacker-controlled bodies could exhaust memory or bandwidth even when teams believed size caps were enforced, according to Corgea. The case shows why adapter parity matters more than documented defaults when HTTP clients sit inside server-side identity and application flows.
NHIMG editorial — based on content published by Corgea: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Axios disclosed CVE-2026-44488 on 4 June 2026.
Questions worth separating out
Q: What breaks when size limits are not enforced across HTTP client adapters?
A: When size limits are inconsistent across adapters, the application loses the boundary it thought would stop oversized requests or responses.
Q: Why do request-size controls matter in server-side NHI workflows?
A: Server-side NHI workflows often proxy uploads, fetch URLs, or relay API calls on behalf of other systems.
Q: How do security teams know whether a library control is really working?
A: They test the exact runtime path, not just the documented setting.
Practitioner guidance
- Validate adapter selection in production Inventory every service that uses axios with finite size limits and confirm whether production resolves to the fetch adapter, the Node.js http adapter, or a fallback path.
- Enforce boundary caps before middleware Add request-size and URL-scheme validation ahead of axios so attacker-controlled bodies are capped before the library can buffer or forward them.
- Test security controls on every code path Create regression tests that verify maxContentLength and maxBodyLength behave the same across adapters, test environments, and bundler targets.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step reproduction of the fetch-adapter bypass across request and response paths
- Patch guidance for upgrading axios and validating the resolved dependency tree
- Code-level remediation notes for teams using adapter: 'fetch' in server-side runtimes
- Detection guidance for memory spikes, oversized forwarded payloads, and risky data: URLs
👉 Read Corgea's analysis of CVE-2026-44488 and axios adapter enforcement gaps →
Axios fetch adapter bypass: are your size limits enforced everywhere?
Explore further
20/08/2026 6:29 pm
Adapter parity is a governance requirement, not a coding detail. Security controls that exist only on one execution path are not real controls, especially in modern JavaScript stacks where fetch, http, and runtime fallbacks can all change behaviour. The practical lesson is that security teams must review enforcement consistency across adapters, not just the documented API surface. That aligns with NIST SP 800-53 control families for access control and system integrity, because the issue is whether the intended guardrail actually survives implementation variance. Practitioners should treat parity testing as part of control validation.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
A question worth separating out:
Q: What should teams do if a transitive dependency uses a vulnerable axios version?
A: Upgrade the parent package or override the dependency until the resolved tree reaches a fixed axios release. Then retest services that process untrusted bodies, user-supplied URLs, or forwarded traffic, because the operational risk comes from exposed execution paths, not only from the package version number.
👉 Read our full editorial: Axios CVE-2026-44488 exposes adapter parity gaps in size limits
