Snyk test report

Allocation of Resources Without Limits or Throttling

---

Overview

zod is a TypeScript-first schema declaration and validation library with static type inference

Affected versions of this package are vulnerable to Allocation of Resources Without Limits or Throttling via the handleArrayResult parse logic in $ZodArray, which accumulates every validation issue for each failing element in a large array with no cap or early termination. An attacker can submit a large array to an application using an array schema without a length constraint, causing the process to allocate excessive issue objects and crash due to out-of-memory conditions.

Remediation

Upgrade zod to version 4.6.6 or higher.

References

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

---

Denial of Service (DoS)

---

Overview

std/crypto/tls is a Go standard library package std/crypto/tls

Affected versions of this package are vulnerable to Denial of Service (DoS).

Go Vulnerability Report:
Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade std/crypto/tls to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Uncontrolled Recursion

---

Overview

std/encoding/asn1 is a Go standard library package std/encoding/asn1

Affected versions of this package are vulnerable to Uncontrolled Recursion.

Go Vulnerability Report:
Enforce a recursion limit in Unmarshal to prevent stack exhaustion when parsing deeply-nested, recursive structures.

Remediation

Upgrade std/encoding/asn1 to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Uncontrolled Recursion

---

Overview

std/encoding/xml is a Go standard library package std/encoding/xml

Affected versions of this package are vulnerable to Uncontrolled Recursion.

Go Vulnerability Report:
Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.

Remediation

Upgrade std/encoding/xml to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Uncaught Exception

---

Overview

std/net is a Go standard library package std/net

Affected versions of this package are vulnerable to Uncaught Exception.

Go Vulnerability Report:
Parsing an invalid SVCB or HTTPS RR can panic when the size of a parameter value overflows the message buffer.

Remediation

Upgrade std/net to version 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Denial of Service (DoS)

---

Overview

std/net/http is a Go standard library package std/net/http

Affected versions of this package are vulnerable to Denial of Service (DoS).

Go Vulnerability Report:
When a server is configured to support unencrypted HTTP/2, it reads a few bytes from each new connection to see if they contain the HTTP/2 client preface. ReadHeaderTimeout is unexpectedly not being applied when doing this.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade std/net/http to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Denial of Service (DoS)

---

Overview

std/net/url is a Go standard library package std/net/url

Affected versions of this package are vulnerable to Denial of Service (DoS).

Go Vulnerability Report:
Previously, resolving relative paths containing parent directory ('..') segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead.Now, path resolution operates on a byte buffer using index-based backtracking for '..' segments, eliminating the quadratic time complexity and significantly reducing memory allocations.

Details

Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its intended and legitimate users.

Unlike other vulnerabilities, DoS attacks usually do not aim at breaching security. Rather, they are focused on making websites and services unavailable to genuine users resulting in downtime.

One popular Denial of Service vulnerability is DDoS (a Distributed Denial of Service), an attack that attempts to clog network pipes to the system by generating a large volume of traffic from many machines.

When it comes to open source libraries, DoS vulnerabilities allow attackers to trigger such a crash or crippling of the service by using a flaw either in the application code or from the use of open source libraries.

Two common types of DoS vulnerabilities:

• High CPU/Memory Consumption- An attacker sending crafted requests that could cause the system to take a disproportionate amount of time to process. For example, commons-fileupload:commons-fileupload.

• Crash - An attacker sending crafted requests that could cause the system to crash. For Example, npm ws package

Remediation

Upgrade std/net/url to version 1.25.13, 1.26.6, 1.27.0-rc.3 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Symlink Attack

---

Overview

std/os is a Go standard library package std/os

Affected versions of this package are vulnerable to Symlink Attack.

Go Vulnerability Report:
On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component of the a path is a symbolic link and the path ends in /.For example, 'root.Open("symlink/")' will open "symlink" even when "symlink" is a symbolic link pointing outside of the root.

Remediation

Upgrade std/os to version 1.25.12, 1.26.5, 1.27.0-rc.2 or higher.

References

• Go Advisory
• Go Code Review
• Go Issue
• Google Groups Forum

---

Use After Free

---

Overview

sharp is a High performance Node.js image processing, the fastest module to resize JPEG, PNG, WebP, GIF, AVIF and TIFF images

Affected versions of this package are vulnerable to Use After Free in entity_insert() and the entity map held on XmlState, which is shared between the outer parse and a recursive XInclude, so inserting an entity whose name already exists replaces the first entry and its Drop implementation calls xmlFreeNode() while the outer xmlCtxtParseEntity() is still using that 144 byte xmlEntity. An attacker can corrupt process memory by supplying an SVG document whose xi:include pulls in another document redefining an entity that is already active. This requires the application to parse attacker supplied SVG with XInclude processing reached, and the entity names must collide across the outer document and the included one.

Remediation

Upgrade sharp to version 0.35.5 or higher.

References

• GitHub Advisory
• GitHub Commit
• GitLab Work Item
• Red Hat Bugzilla Bug
• RustSec Advisory
• PoC in GitHub

---

Heap-based Buffer Overflow

---

Overview

sharp is a High performance Node.js image processing, the fastest module to resize JPEG, PNG, WebP, GIF, AVIF and TIFF images

Affected versions of this package are vulnerable to Heap-based Buffer Overflow in the VipsForeignLoadHeif process. An attacker can execute arbitrary code by providing specially crafted AVIF images as input.

Workaround

This vulnerability can be mitigated by blocking the decoding of AVIF images using the configuration sharp.block({ operation: ["VipsForeignLoadHeif"] }); and by ensuring the Node.js executable is compiled as a Position Independent Executable (PIE).

Remediation

Upgrade sharp to version 0.35.4 or higher.

References

• GitHub Release
• Maintainer's Advisory

---

Uncaught Exception

---

Overview

qs is a querystring parser that supports nesting and arrays, with a depth limit.

Affected versions of this package are vulnerable to Uncaught Exception via stringify when arrayFormat: 'comma' is used with array elements that have a non-callable toString property. Such elements - as produced by JSON.parse, or by qs.parse under allowPrototypes or plainObjects (which yields null-prototype objects) - cause Array.prototype.join or utils.encode to throw a TypeError: Cannot convert object to primitive value, crashing the process.

Note: This is only exploitable if the arrayFormat: 'comma' option is explicitly set.

Remediation

Upgrade qs to version 6.16.1 or higher.

References

• GitHub Advisory
• GitHub Commit

---

CVE-2026-45447

---

NVD Description

Note: Versions mentioned in the description apply only to the upstream nodejs package and not the nodejs package as distributed by Ubuntu. See How to fix? for Ubuntu:22.04 relevant fixed versions and status.

Issue summary: A specially crafted PKCS#7 or S/MIME signed message could trigger a use-after-free during PKCS#7 signature verification.

Impact summary: A use-after-free may result in process crashes, heap corruption, or potentially remote code execution.

When processing a PKCS#7 or S/MIME signed message, if the SignedData digestAlgorithms field is present as an empty ASN.1 SET, OpenSSL may incorrectly free a caller-owned BIO during PKCS7_verify(). A subsequent use of the BIO by the calling application results in a use-after-free condition.

In the common case this occurs when the application later calls BIO_free() on the BIO originally passed to PKCS7_verify(). Depending on allocator behavior and application-specific BIO usage patterns, this may result in a crash or other memory corruption. In some application contexts this may potentially be exploitable for remote code execution.

Applications that process PKCS#7 or S/MIME signed messages using OpenSSL PKCS#7 APIs may be affected. Applications using the CMS APIs for this processing are not affected.

The FIPS modules in 4.0, 3.6, 3.5, 3.4, and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.

Remediation

There is no fixed version for Ubuntu:22.04 nodejs.

References

• http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-45447
• https://github.com/openssl/security/commit/3aad5eb7af4de4ee0633c30a8541a54d9bbde63c
• https://github.com/openssl/security/commit/7d4a980c62258c5910cc883936e0c8dbab4d75a8
• https://github.com/openssl/security/commit/9dfd688ad2290fc5075cacbc9bf0c9a93eefed54
• https://github.com/openssl/security/commit/a541ae8bfe849a30cc885e8780715c0f488e496c
• https://github.com/openssl/security/commit/c505d7559da5d5f9f2c3913c6883a5562ce7273e
• https://github.com/openssl/openssl/commit/3aad5eb7af4de4ee0633c30a8541a54d9bbde63c
• https://github.com/openssl/openssl/commit/7d4a980c62258c5910cc883936e0c8dbab4d75a8
• https://github.com/openssl/openssl/commit/9dfd688ad2290fc5075cacbc9bf0c9a93eefed54
• https://github.com/openssl/openssl/commit/a541ae8bfe849a30cc885e8780715c0f488e496c
• https://github.com/openssl/openssl/commit/c505d7559da5d5f9f2c3913c6883a5562ce7273e
• https://openssl-library.org/news/secadv/20260609.txt
• https://access.redhat.com/errata/RHSA-2026:25237
• https://access.redhat.com/errata/RHSA-2026:25239
• https://access.redhat.com/errata/RHSA-2026:26275
• https://access.redhat.com/errata/RHSA-2026:26319
• https://access.redhat.com/errata/RHSA-2026:29197
• https://access.redhat.com/errata/RHSA-2026:34102
• https://access.redhat.com/errata/RHSA-2026:35869
• https://access.redhat.com/errata/RHSA-2026:36215
• https://access.redhat.com/errata/RHSA-2026:36217
• https://access.redhat.com/errata/RHSA-2026:39009
• https://access.redhat.com/errata/RHSA-2026:39012
• https://access.redhat.com/errata/RHSA-2026:39981
• https://access.redhat.com/security/cve/CVE-2026-45447
• https://bugzilla.redhat.com/show_bug.cgi?id=2481898
• https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-45447.json
• https://access.redhat.com/errata/RHSA-2026:44438
• https://access.redhat.com/errata/RHSA-2026:47735
• https://access.redhat.com/errata/RHSA-2026:47737
• https://access.redhat.com/errata/RHSA-2026:58563
• https://access.redhat.com/errata/RHSA-2026:58981
• https://access.redhat.com/errata/RHSA-2026:59831
• https://access.redhat.com/errata/RHSA-2026:66524

---

CVE-2026-84782

---

NVD Description

Note: Versions mentioned in the description apply only to the upstream nodejs package and not the nodejs package as distributed by Ubuntu. See How to fix? for Ubuntu:22.04 relevant fixed versions and status.

Issue summary: The DTLS retransmission logic does not correctly handle a handshake message write that is suspended part-way through. The retransmitted message can be read past the message buffer and the retransmission overwrites the internal state the suspended write needs to resume correctly.

Impact summary: The retransmitted message can disclose a heap memory to the peer as plaintext handshake data or cause a crash and a Denial of Service when the read reaches an unmapped memory region.

CWE: CWE-125: Out-of-bounds Read

Description: DTLS handshake messages can be written out in multiple fragments, and a write can suspend mid-message (returning WANT_WRITE) if the underlying transport temporarily cannot accept more data. While such a write is suspended, the DTLS retransmission timer may independently fire and ask the retransmission logic to resend an earlier, already-acknowledged-as-sent message from its retransmit queue.

The retransmission logic reused the same internal buffer and position tracking as the message that was still being written, without resetting the position back to the start of the message being retransmitted. As a result the retransmission was read starting from wherever the suspended write had left off, producing a mislabelled message whose body was leftover bytes from the other, larger message still in flight - content that was never meant to be sent at that point, and which could run past the end of the allocated buffer.

Separately, even when the retransmission is positioned correctly, allowing it to run to completion while another write is suspended overwrites the same shared bookkeeping that the suspended write depends on to resume. When the application later resumes the suspended write (via a subsequent SSL_read(), SSL_write(), SSL_accept(), or SSL_connect() call), it finds that bookkeeping in a state inconsistent with the message and aborts the process in a debugging build.

The fix resets the retransmission's read position to the start of the message before resending, and skips retransmission entirely whenever a handshake write is still suspended, deferring to the next call that resumes it instead.

FIPS impact: no The affected code is outside the FIPS module boundary.

Remediation

There is no fixed version for Ubuntu:22.04 nodejs.

References

• http://people.ubuntu.com/~ubuntu-security/cve/CVE-2026-84782
• https://github.com/openssl/openssl/commit/906cf0ef1c85ca40ce69163e9086d6d3fe292943
• https://github.com/openssl/openssl/commit/9f6b34422af7eb5dac61322e33dac1ae989fa628
• https://github.com/openssl/openssl/commit/a383dafdd754eb5b22bf45e37e1bff9d07277a58
• https://github.com/openssl/openssl/commit/d951e02ede8f6a6ff8150546db44b34f0518192c
• https://openssl-library.org/news/secadv/20260929.txt

---

Directory Traversal

---

Overview

extract-zip is an unzip a zip file into a directory using 100% javascript

Affected versions of this package are vulnerable to Directory Traversal via the extraction process. An attacker can access or modify arbitrary files by crafting a malicious zip archive containing symlinks that point outside the intended extraction directory.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
        

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
        2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys
        

Remediation

There is no fixed version for extract-zip.

References

• Advisory
• GitHub Advisory

---

Directory Traversal

---

Overview

extract-zip is an unzip a zip file into a directory using 100% javascript

Affected versions of this package are vulnerable to Directory Traversal through the archive extraction logic in index.js. An attacker can write a file outside the destination directory by supplying an archive with two entries that reuse the same path: a symlink pointing outside the extraction root, followed by a regular file for that same name. During extraction, the code only checked the parent directory of each entry and then wrote the file through the existing final path component, so the second entry followed the planted symlink and overwrote the symlink target. This can corrupt or replace files writable by the process running extract-zip.

Details

A Directory Traversal attack (also known as path traversal) aims to access files and directories that are stored outside the intended folder. By manipulating files with "dot-dot-slash (../)" sequences and its variations, or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system, including application source code, configuration, and other critical system files.

Directory Traversal vulnerabilities can be generally divided into two types:

• Information Disclosure: Allows the attacker to gain information about the folder structure or read the contents of sensitive files on the system.

st is a module for serving static files on web pages, and contains a vulnerability of this type. In our example, we will serve files from the public route.

If an attacker requests the following URL from our server, it will in turn leak the sensitive private key of the root user.

curl http://localhost:8080/public/%2e%2e/%2e%2e/%2e%2e/%2e%2e/%2e%2e/root/.ssh/id_rsa
        

Note %2e is the URL encoded version of . (dot).

• Writing arbitrary files: Allows the attacker to create or replace existing files. This type of vulnerability is also known as Zip-Slip.

One way to achieve this is by using a malicious zip archive that holds path traversal filenames. When each filename in the zip archive gets concatenated to the target extraction folder, without validation, the final path ends up outside of the target folder. If an executable or a configuration file is overwritten with a file containing malicious code, the problem can turn into an arbitrary code execution issue quite easily.

The following is an example of a zip archive with one benign file and one malicious file. Extracting the malicious file will result in traversing out of the target folder, ending up in /root/.ssh/ overwriting the authorized_keys file:

2018-04-15 22:04:29 .....           19           19  good.txt
        2018-04-15 22:04:42 .....           20           20  ../../../../../../root/.ssh/authorized_keys
        

Remediation

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

References

• GitHub Commit
• GitHub PR

---

Regular Expression Denial of Service (ReDoS)

---

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) via improper validation of runtime options in resolveConfig and related helpers, where an attacker-controlled or malformed configuration value can trigger a crash in the request processing pipeline. The hardening of option handling across fetch.js, http.js, dispatchRequest.js, and supporting helpers indicates that unsanitized option objects could be passed through to the underlying fetch or HTTP adapter in a way that causes an unhandled runtime error, crashing the process and denying service to other users.

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.

String	Number of C's	Number of steps
ACCCX	3	38
ACCCCX	4	71
ACCCCCX	5	136
ACCCCCCCCCCCCCCX	14	65,553

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 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Improper Validation of Specified Quantity in Input

---

Overview

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

Affected versions of this package are vulnerable to Improper Validation of Specified Quantity in Input via unsafe runtime option handling in the fetch and HTTP adapters, where user-supplied fetchOptions are merged into the resolved request options without sanitization or allowlist enforcement. An attacker who can influence request configuration can supply option values that override Axios-owned fields (such as signal, method, headers, or body) or inject unexpected fetch option keys, causing the request pipeline to crash and producing a denial of service.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Improper Validation of Specified Quantity in Input

---

Overview

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

Affected versions of this package are vulnerable to Improper Validation of Specified Quantity in Input via unsafe runtime option handling in the fetch and HTTP adapters, where user-supplied fetchOptions are merged into the resolved request options without sanitization or allowlist enforcement. An attacker who can influence request configuration can supply option values that override Axios-owned fields (such as signal, method, headers, or body) or inject unexpected fetch option keys, causing the request pipeline to crash and producing a denial of service.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Unintended Proxy or Intermediary ('Confused Deputy')

---

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 insufficient hardening of runtime option handling in the fetch and HTTP adapters (lib/adapters/fetch.js, lib/adapters/http.js, and related helpers). An authenticated attacker can supply malicious request options that are passed through without sanitization, allowing them to override Axios-controlled fetch properties such as body, headers, method, signal, duplex, and credentials, leading to a full compromise of request confidentiality and integrity.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Unintended Proxy or Intermediary ('Confused Deputy')

---

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 enforcement of maxRedirects: 0 in the fetch adapter, where user-supplied fetchOptions are merged into the resolved request options without defaulting the redirect field. When a caller sets maxRedirects: 0 to prevent redirects, the fetch adapter does not apply redirect: 'manual' unless the caller also explicitly sets fetchOptions.redirect, causing the underlying fetch runtime to silently follow a 302 redirect from the initial target and forward the request - including any credentials or sensitive headers - to the redirect destination, which may be attacker-controlled.

Note: This is only exploitable when requests are configured with maxRedirects: 0 but without fetchOptions.redirect: 'manual' or an equivalent runtime-specific redirect control.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Server-side Request Forgery (SSRF)

---

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) via unsafe merging of user-supplied fetchOptions into the resolved request options object in lib/adapters/fetch.js. An attacker who controls request configuration can supply a fetchOptions object with prototype-polluting keys (e.g. __proto__ or constructor), which are spread directly into the options passed to the Fetch API without sanitization, allowing pollution of Object.prototype and affecting downstream system-level behaviour. The fix replaces the spread with Object.assign(Object.create(null), fetchOptions) to strip inherited properties and enforces an allowlist of safe Fetch API keys.

Note: This is only exploitable when the attacker can influence the fetchOptions configuration passed to axios requests.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Allocation of Resources Without Limits or Throttling

---

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 unsafe runtime option handling in the fetch and HTTP adapters, where user-supplied fetchOptions are merged into the resolved request options without sanitization. An attacker who can influence request configuration can trigger uncontrolled resource consumption, crashing the process.

Note: This is only exploitable when requests follow redirects (i.e., maxRedirects is not set to 0), unless application code manually follows the malicious redirect and re-enters axios.

Remediation

Upgrade axios to version 1.20.0 or higher.

References

• GitHub Commit
• GitHub PR
• Maintainer's Advisory

---

Prototype Pollution

---

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 insufficient hardening of runtime option handling across multiple request-processing helpers (lib/helpers/resolveConfig.js, lib/helpers/toFormData.js, lib/adapters/fetch.js, and related files). An attacker can supply a manipulated configuration object that overrides internally owned fetch options (such as body, headers, method, signal) or bypasses the default formSerializer.maxDepth limit, leading to integrity violations in outgoing requests or a crash causing denial of service.

Note: This is only exploitable when the caller does not explicitly set formSerializer.maxDepth, allowing a prototype-level or caller-supplied value to override the expected default.

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:

Type	Origin	Short description
Denial of service (DoS)	Client	This is the most likely attack. DoS occurs when Object holds generic functions that are implicitly called for various operations (for example, toString and valueOf). The attacker pollutes Object.prototype.someattr and alters its state to an unexpected value such as Int or Object. In this case, the code fails and is likely to cause a denial of service. For example: if an attacker pollutes Object.prototype.toString by defining it as an integer, if the codebase at any point was reliant on someobject.toString() it would fail.
Remote Code Execution	Client	Remote code execution is generally only possible in cases where the codebase evaluates a specific attribute of an object, and then executes that evaluation. For example: eval(someobject.someattr). In this case, if the attacker pollutes Object.prototype.someattr they are likely to be able to leverage this in order to execute code.
Property Injection	Client	The attacker pollutes properties that the codebase relies on for their informative value, including security properties such as cookies or tokens. For example: if a codebase checks privileges for someuser.isAdmin, then when the attacker pollutes Object.prototype.isAdmin and sets it to equal true, they can then achieve admin privileges.

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.34.0, 1.20.0 or higher.

References

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

---