GHSA-qj83-cq47-w5f8
MEDIUMGHSA-qj83-cq47-w5f8 is a medium-severity (CVSS 5.9) Uncontrolled Resource Consumption vulnerability in axios. O3 Security confirms whether GHSA-qj83-cq47-w5f8 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Axios HTTP/2 Session Cleanup State Corruption Vulnerability
Blast Radius
axiosReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Axios HTTP/2 session cleanup logic contains a state corruption bug that allows a malicious server to crash the client process through concurrent session closures. This denial-of-service vulnerability affects axios versions prior to 1.13.2 when HTTP/2 is enabled.
Details
The vulnerability exists in the Http2Sessions.getSession() method in lib/adapters/http.js. The session cleanup logic contains a control flow error when removing sessions from the sessions array.
Vulnerable Code:
while (i--) {
if (entries[i][0] === session) {
entries.splice(i, 1);
if (len === 1) {
delete this.sessions[authority];
return;
}
}
}
Root Cause:
After calling entries.splice(i, 1) to remove a session, the original code only returned early if len === 1. For arrays with multiple entries, the iteration continued after modifying the array, causing undefined behavior and potential crashes when accessing shifted array indices.
Fixed Code:
while (i--) {
if (entries[i][0] === session) {
if (len === 1) {
delete this.sessions[authority];
} else {
entries.splice(i, 1);
}
return;
}
}
The fix restructures the control flow to immediately return after removing a session, regardless of whether the array is being emptied or just having one element removed. This prevents continued iteration over a modified array and eliminates the state corruption vulnerability.
Affected Component:
lib/adapters/http.js- Http2Sessions class, session cleanup in connection close handler
PoC
- Set up a malicious HTTP/2 server that accepts multiple concurrent connections from an axios client
- Establish multiple concurrent HTTP/2 sessions with the axios client
- Close all sessions simultaneously with precise timing
- The flawed cleanup logic attempts to iterate over and modify the sessions array concurrently
- This causes the client to access invalid memory locations, resulting in a process crash
Prerequisites:
- Client must use axios with HTTP/2 enabled
- Client must connect to attacker-controlled HTTP/2 server
- Multiple concurrent HTTP/2 sessions must be established
- Server must close all sessions simultaneously with precise timing
Impact
Who is impacted:
- Applications using axios with HTTP/2 enabled
- Applications connecting to untrusted or attacker-controlled HTTP/2 servers
- Node.js applications using axios for HTTP/2 requests
Impact Details:
- Denial of Service: Malicious server can crash the axios client process by accepting and closing multiple concurrent HTTP/2 connections simultaneously
- Availability Impact: Complete loss of availability for the client process through crash (though service may auto-restart)
- Scope: Impact is limited to the single client process making the requests; does not escape to affect other components or systems
- No Confidentiality or Integrity Impact: Vulnerability only causes process crash, no information disclosure or data modification
CVSS Score: 5.9 (Medium) CVSS Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE Classifications:
- CWE-400: Uncontrolled Resource Consumption
- CWE-662: Improper Synchronization
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | axios | ≥ 1.13.0&&< 1.13.2 | 1.13.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for axios. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update axios to 1.13.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-qj83-cq47-w5f8 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-qj83-cq47-w5f8 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-qj83-cq47-w5f8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-qj83-cq47-w5f8 in your dependencies?
O3 detects GHSA-qj83-cq47-w5f8 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.