A flaw was found in curl. This flaw lies in the --ssl-reqd option or related settings in libcurl. Users specify this flag to upgrade to TLS when communicating with either IMAP, POP3 or a FTP server. An attacker controlling such servers could return a crafted response which could lead to curl client continue its operation without TLS encryption leading to data being transmitted in clear text over the network. The highest threat from this vulnerability is to data confidentiality.

@npmcli/arborist, the library that calculates dependency trees and manages the nodemodules folder hierarchy for the npm command line interface, aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder. This is, in part, accomplished by resolving dependency specifiers defined in package.json manifests for dependencies with a specific name, and nesting folders to resolve conflicting dependencies. When multiple dependencies differ only in the case of their name, Arborist's internal data structure saw them as separate items that could coexist within the same level in the nodemodules hierarchy. However, on case-insensitive file systems (such as macOS and Windows), this is not the case. Combined with a symlink dependency such as file:/some/path, this allowed an attacker to create a situation in which arbitrary contents could be written to any location on the filesystem. For example, a package pwn-a could define a dependency in their package.json file such as "foo": "file:/some/path". Another package, pwn-b could define a dependency such as FOO: "file:foo.tgz". On case-insensitive file systems, if pwn-a was installed, and then pwn-b was installed afterwards, the contents of foo.tgz would be written to /some/path, and any existing contents of /some/path would be removed. Anyone using npm v7.20.6 or earlier on a case-insensitive filesystem is potentially affected. This is patched in @npmcli/arborist 2.8.2 which is included in npm v7.20.7 and above.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain .. path portions, and resolving the sanitized paths against the extraction target directory.

This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as C:some\path. If the drive letter does not match the extraction target, for example D:\extraction\dir, then the result of path.resolve(extractionDirectory, entryPath) would resolve against the current working directory on the C: drive, rather than the extraction target directory.

Additionally, a .. portion of the path could occur immediately after the drive letter, such as C:../foo, and was not properly sanitized by the logic that checked for .. within the normalized and split portions of the path.

This only affects users of node-tar on Windows systems.

Patches

4.4.18 || 5.0.10 || 6.1.9

Workarounds

There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does.

Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.

Fix

The fixed versions strip path roots from all paths prior to being resolved against the extraction target folder, even if such paths are not "absolute".

Additionally, a path starting with a drive letter and then two dots, like c:../, would bypass the check for .. path portions. This is checked properly in the patched versions.

Finally, a defense in depth check is added, such that if the entry.absolute is outside of the extraction taret, and we are not in preservePaths:true mode, a warning is raised on that entry, and it is skipped. Currently, it is believed that this check is redundant, but it did catch some oversights in development.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

@npmcli/arborist, the library that calculates dependency trees and manages the nodemodules folder hierarchy for the npm command line interface, aims to guarantee that package dependency contracts will be met, and the extraction of package contents will always be performed into the expected folder.

This is accomplished by extracting package contents into a project's nodemodules folder.

If the nodemodules folder of the root project or any of its dependencies is somehow replaced with a symbolic link, it could allow Arborist to write package dependencies to any arbitrary location on the file system.

Note that symbolic links contained within package artifact contents are filtered out, so another means of creating a nodemodules symbolic link would have to be employed.

1. A preinstall script could replace nodemodules with a symlink. (This is prevented by using --ignore-scripts.) 2. An attacker could supply the target with a git repository, instructing them to run npm install --ignore-scripts in the root. This may be successful, because npm install --ignore-scripts is typically not capable of making changes outside of the project directory, so it may be deemed safe.

Patches

2.8.2 (included in npm v7.20.7 and above)

Workarounds

Do not run npm install on untrusted codebases, without first ensuring that the nodemodules directory in the project is not a symbolic link.

Fix

Prior to extracting any package contents, the nodemodules folder into which it is extracted is verified to be a real directory. If it is not, then it is removed.

Caveat: if you are currently relying on creating a symbolic link to the nodemodules folder in order to share dependencies between projects, then that will no longer be possible. Please use the npm link command, explicit file:... dependencies, and/or workspaces to share dependencies in a development environment.

Impact Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained two directories and a symlink with names containing unicode values that normalized to the same value. Additionally, on Windows systems, long path portions would resolve to the same file system entities as their 8.3 "short path" counterparts. A specially crafted tar archive could thus include directories with two forms of the path that resolve to the same file system entity, followed by a symbolic link with a name in the first form, lastly followed by a file using the second form. It led to bypassing node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. If this is not possible, a workaround is available below.

Patches

6.1.9 || 5.0.10 || 4.4.18

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } })

Users are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.

Fix

The problem is addressed in the following ways, when comparing paths in the directory cache and path reservation systems:

1. The String.normalize('NFKD') method is used to first normalize all unicode to its maximally compatible and multi-code-point form. 2. All slashes are normalized to / on Windows systems (on posix systems, \ is a valid filename character, and thus left intact). 3. When a symbolic link is encountered on Windows systems, the entire directory cache is cleared. Collisions related to use of 8.3 short names to replace directories with other (non-symlink) types of entries may make archives fail to extract properly, but will not result in arbitrary file writes.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory, where the symlink and directory names in the archive entry used backslashes as a path separator on posix systems. The cache checking logic used both \ and / characters as path separators, however \ is a valid filename character on posix systems.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

Additionally, a similar confusion could arise on case-insensitive filesystems. If a tar archive contained a directory at FOO, followed by a symbolic link named foo, then on case-insensitive file systems, the creation of the symbolic link would remove the directory from the filesystem, but not from the internal directory cache, as it would not be treated as a cache hit. A subsequent file entry within the FOO directory would then be placed in the target of the symbolic link, thinking that the directory had already been created.

These issues were addressed in releases 4.4.16, 5.0.8 and 6.1.7.

The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. If this is not possible, a workaround is available below.

Patches

4.4.16 || 5.0.8 || 6.1.7

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } })

Users are encouraged to upgrade to the latest patched versions, rather than attempt to sanitize tar input themselves.

Fix

The problem is addressed in the following ways:

1. All paths are normalized to use / as a path separator, replacing \ with / on Windows systems, and leaving \ intact in the path on posix systems. This is performed in depth, at every level of the program where paths are consumed. 2. Directory cache pruning is performed case-insensitively. This may result in undue cache misses on case-sensitive file systems, but the performance impact is negligible.

Caveat

Note that this means that the entry objects exposed in various parts of tar's API will now always use / as a path separator, even on Windows systems. This is not expected to cause problems, as / is a valid path separator on Windows systems, but may result in issues if entry.path is compared against a path string coming from some other API such as fs.realpath() or path.resolve().

Users are encouraged to always normalize paths using a well-tested method such as path.resolve() before comparing paths to one another.

ASN.1 strings are represented internally within OpenSSL as an ASN1STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL's own "d2i" functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1STRINGset() function will additionally NUL terminate the byte array in the ASN1STRING structure. However, it is possible for applications to directly construct valid ASN1STRING structures which do not NUL terminate the byte array by directly setting the "data" and "length" fields in the ASN1STRING array. This can also happen by using the ASN1STRINGset0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1STRINGs that have been directly constructed by the application without NUL terminating the "data" field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1STRING structures). It can also occur in the X509get1email(), X509REQget1email() and X509get1ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).

A flaw was found in Node.js, where it is vulnerable to a use-after-free attack. This flaw allows an attacker to exploit memory corruption to change process behavior. The highest threat from this vulnerability is to confidentiality and integrity.

libcurl-using applications can ask for a specific client certificate to be used in a transfer. This is done with the CURLOPTSSLCERT option (--cert with the command line tool).When libcurl is built to use the macOS native TLS library Secure Transport, an application can ask for the client certificate by name or with a file name - using the same option. If the name exists as a file, it will be used instead of by name.If the appliction runs with a current working directory that is writable by other users (like /tmp), a malicious user can create a file name with the same name as the app wants to use by name, and thereby trick the application to use the file based cert instead of the one referred to by name making libcurl send the wrong client certificate in the TLS connection handshake.

Node.js tar module could allow a local attacker to traverse directories on the system, caused by insufficient absolute path sanitization. An attacker could use a specially-crafted tar file containing "dot dot" sequences (/../) to create or overwrite arbitrary files on the system.

Impact

Arbitrary File Creation, Arbitrary File Overwrite, Arbitrary Code Execution

node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created.

This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory. This order of operations resulted in the directory being created and added to the node-tar directory cache. When a directory is present in the directory cache, subsequent calls to mkdir for that directory are skipped. However, this is also where node-tar checks for symlinks occur.

By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite.

This issue was addressed in releases 3.2.3, 4.4.15, 5.0.7 and 6.1.2.

Patches

3.2.3 || 4.4.15 || 5.0.7 || 6.1.2

Workarounds

Users may work around this vulnerability without upgrading by creating a custom filter method which prevents the extraction of symbolic links.

js const tar = require('tar')

tar.x({ file: 'archive.tgz', filter: (file, entry) => { if (entry.type === 'SymbolicLink') { return false } else { return true } } })

Users are encouraged to upgrade to the latest patch versions, rather than attempt to sanitize tar input themselves.

Node.js before 16.4.1, 14.17.2, and 12.22.2 is vulnerable to local privilege escalation attacks under certain conditions on Windows platforms. More specifically, improper configuration of permissions in the installation directory allows an attacker to perform two different escalation attacks: PATH and DLL hijacking.

A use-after-free flaw was found in the way curl handled TLS session data. The curl versions using the OpenSSL library as their TLS backend could use freed memory after TLS session renegotiation was performed by the OpenSSL library. A malicious TLS server could use this flaw to crash or, possibly, execute arbitrary code with the privileges of a client application using the curl library.

In BIND 9.0.0 -> 9.11.29, 9.12.0 -> 9.16.13, and versions BIND 9.9.3-S1 -> 9.11.29-S1 and 9.16.8-S1 -> 9.16.13-S1 of BIND Supported Preview Edition, as well as release versions 9.17.0 -> 9.17.11 of the BIND 9.17 development branch, when a vulnerable version of named receives a query for a record triggering the flaw described above, the named process will terminate due to a failed assertion check. The vulnerability affects all currently maintained BIND 9 branches (9.11, 9.11-S, 9.16, 9.16-S, 9.17) as well as all other versions of BIND 9.

curl 7.1.1 to and including 7.75.0 is vulnerable to an "Exposure of Private Personal Information to an Unauthorized Actor" by leaking credentials in the HTTP Referer: header. libcurl does not strip off user credentials from the URL when automatically populating the Referer: HTTP request header field in outgoing HTTP requests, and therefore risks leaking sensitive data to the server that is the target of the second HTTP request.

A regular expression denial of service vulnerability was found in hosted-git-info. If an application allows user input into the affected regular expression (regexp) function, shortcutMatch or fromUrl, then an attacker could craft a regexp which takes an ever increasing amount of time to process, potentially resulting in a denial of service.

A flaw was found in ssri package. A malicious string provided by an attacker may lead to Regular Expression Denial of Service (ReDoS). This issue only affects consumers using the strict option. The highest threat from this vulnerability is to availability.

A flaw was found in nodejs. When too many connection attempts with an 'unknownProtocol' are established a leak of file descriptors can occur leading to a potential denial of service. If a file descriptor limit is configured on the system, then the server is unable to accept new connections and prevent the process also from opening. If no file descriptor limit is configured, then this can lead to an excessive memory usage and cause the system to run out of memory. The highest threat from this vulnerability is to system availability.

A flaw was found in nodejs. A denial of service is possible when the whitelist includes “localhost6”. When “localhost6” is not present in /etc/hosts, it is just an ordinary domain that is resolved via DNS over the network. If the attacker controls the victim's DNS server or can spoof its responses, the DNS rebinding protection can be bypassed by using the “localhost6” domain. As long as the attacker uses the “localhost6” domain, they can still apply the attack described in CVE-2018-7160.

BIND servers are vulnerable if they are running an affected version and are configured to use GSS-TSIG features. In a configuration which uses BIND's default settings the vulnerable code path is not exposed, but a server can be rendered vulnerable by explicitly setting valid values for the tkey-gssapi-keytab or tkey-gssapi-credentialconfiguration options. Although the default configuration is not vulnerable, GSS-TSIG is frequently used in networks where BIND is integrated with Samba, as well as in mixed-server environments that combine BIND servers with Active Directory domain controllers. The most likely outcome of a successful exploitation of the vulnerability is a crash of the named process. However, remote code execution, while unproven, is theoretically possible. Affects: BIND 9.5.0 -> 9.11.27, 9.12.0 -> 9.16.11, and versions BIND 9.11.3-S1 -> 9.11.27-S1 and 9.16.8-S1 -> 9.16.11-S1 of BIND Supported Preview Edition. Also release versions 9.17.0 -> 9.17.1 of the BIND 9.17 development branch

A flaw was found in nodejs. Affected versions of Node.js allow two copies of a header field in an HTTP request. The first header field is recognized while the second is ignored leading to HTTP request smuggling. The highest threat from this vulnerability is to data confidentiality and integrity.

A flaw was found in nodejs. When writing to a TLS enabled socket, node::StreamBase::Write calls node::TLSWrap::DoWrite with a freshly allocated WriteWrap object as first argument. If the DoWrite method does not return an error, this object is passed back to the caller as part of a StreamWriteResult structure. This may be exploited to corrupt memory leading to a Denial of Service or potentially other exploits.

curl 7.41.0 through 7.73.0 is vulnerable to an improper check for certificate revocation due to insufficient verification of the OCSP response.

curl 7.21.0 to and including 7.73.0 is vulnerable to uncontrolled recursion due to a stack overflow issue in FTP wildcard match parsing.

A flaw was found in libcurl from versions 7.29.0 through 7.71.1. An application that performs multiple requests with libcurl's multi API, and sets the CURLOPTCONNECTONLY option, might experience libcurl using the wrong connection. The highest threat from this vulnerability is to data confidentiality.

curl 7.20.0 through 7.70.0 is vulnerable to improper restriction of names for files and other resources that can lead too overwriting a local file when the -J flag is used.

A flaw was found in libcurl. A part of a password may be prepended to the host name before the host name is resolved, leading to a leak of the partial password over the network and to DNS servers. This highest threat from this vulnerability is to data confidentiality.

SQLite is vulnerable to a denial of service, caused by a use-after-free in resetAccumulator in select.c. By sending a specially crafted request, a remote attacker could exploit this vulnerability to cause a denial of service.

ext/fts3/fts3.c in SQLite before 3.32.0 has a use-after-free in fts3EvalNextRow related to the snippet feature.

Last updated 18 August 2025