In libarchive 3.6.1, the software does not check for an error after calling calloc function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference or, in some cases, even arbitrary code execution.

Upstream patch: https://github.com/libarchive/libarchive/commit/fd180c36036df7181a64931264732a10ad8cd024

A vulnerability was found in lz4, where a potential memory corruption due to an integer overflow bug which caused one of the memmove arguments to become negative. Depending on how the library was compiled this will hit an assert() inside the library and dump core, leaving a 4GB core file, or it wil go into libc and crash inside the memmove() function.

Reference: https://github.com/lz4/lz4/pull/972

A vulnerability was found in curl. The issue occurs when doing HTTP(S) transfers, where curl might erroneously use the read callback (CURLOPTREADFUNCTION) to ask for data to send, even when the CURLOPTPOSTFIELDS option has been set if it previously used the same handle to issue a PUT request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent POST request.

A vulnerability was found in curl. This issue occurs because when curl saves cookies, alt-svc, and HSTS data to local files, it makes the operation atomic by finalizing the process with a rename from a temporary name to the final target file name. This flaw leads to unpreserved file permissions, either by mistake or by a malicious actor.

A vulnerability in input validation exists in curl <8.0 during communication using the TELNET protocol may allow an attacker to pass on maliciously crafted user name and "telnet options" during server negotiation. The lack of proper input scrubbing allows an attacker to send content or perform option negotiation without the application's intent. This vulnerability could be exploited if an application allows user input thereby enabling attackers to execute arbitrary code on the system.

curl. Multiple issues were addressed by updating to curl version 7.79.1.

A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality fail when multiple URLs are requested serially. Using its HSTS support, curl can be instructed to use HTTPS instead of usingan insecure clear-text HTTP step even when HTTP is provided in the URL. ThisHSTS mechanism would however surprisingly be ignored by subsequent transferswhen done on the same command line because the state would not be properlycarried on.

Use after free in Blink XSLT in Google Chrome prior to 91.0.4472.164 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

A path traversal vulnerability exists in curl <8.0.0 SFTP implementation causes the tilde (~) character to be wrongly replaced when used as a prefix in the first path element in addition to its intended use as the first element to indicate a path relative to the user's home directory. Attackers can exploit this flaw to bypass filtering or execute arbitrary code by crafting a path like /~2/foo while accessing a server with a specific user.

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.

A vulnerability was found in curl. The issue occurs if curl is told to use an HTTP proxy for a transfer with a non-HTTP(S) URL. It sets up the connection to the remote server by issuing a CONNECT request to the proxy and then tunnels the rest of the protocol through. An HTTP proxy might refuse this request (HTTP proxies often only allow outgoing connections to specific port numbers, like 443 for HTTPS) and instead return a non-200 response code to the client. Due to flaws in the error/cleanup handling, this could trigger a double-free issue in curl if using one of the following schemes in the URL for the transfer: dict, gopher, gophers, ldap, ldaps, rtmp, rtmps, telnet.

A use of incorrectly resolved name vulnerability fixed in 7.83.1 might remove the wrong file when --no-clobber is used together with --remove-on-error.

In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#ConfigureTLShostnamevalidationfortheSplunkCLI to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.

The issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.

An improper authentication vulnerability exists in curl 7.33.0 to and including 7.82.0 which might allow reuse OAUTH2-authenticated connections without properly making sure that the connection was authenticated with the same credentials as set for this transfer. This affects SASL-enabled protocols: SMPTP(S) IMAP(S) POP3(S) and LDAP(S) (openldap only).

In Universal Forwarder for Windows versions below 9.4.2, 9.3.4, 9.2.6, and 9.1.9, a new installation of or an upgrade to an affected version can result in incorrect permissions assignment in the Universal Forwarder for Windows Installation directory (by default, C:\Program Files\SplunkUniversalForwarder). This lets non-administrator users on the machine access the directory and all its contents.

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.

An improper link resolution flaw can occur while extracting an archive leading to changing modes, times, access control lists, and flags of a file outside of the archive. An attacker may provide a malicious archive to a victim user, who would trigger this flaw when trying to extract the archive. A local attacker may use this flaw to gain more privileges in a system.

An authentication bypass vulnerability exists in libcurl prior to v8.0.0 where it reuses a previously established SSH connection despite the fact that an SSH option was modified which should have prevented reuse. libcurl maintains a pool of previously used connections to reuse them for subsequent transfers if the configurations match. However two SSH settings were omitted from the configuration check allowing them to match easily potentially leading to the reuse of an inappropriate connection.

A vulnerability was found in libpcre in PCRE before 8.43 allows a subject buffer over-read in JIT when UTF is disabled, and \X or \R has more than one fixed quantifier, a related issue to CVE-2019-20454.

References: https://bugs.gentoo.org/717920 https://www.pcre.org/original/changelog.txt

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.

A flaw was found in libpcre. A buffer overread in JIT mode when \X is used in non-UTF mode may cause application crash and denial of service. The flaw is in function doextuninoutf() in pcre2jitcompile.c, which uses the macro GETCHARINC to read a character. However, in case there is an invalid UTF character the value read is too big, which causes an out-of-bounds read in the next statement, while executing macro UCDGRAPHBREAK.

References:

https://bugs.exim.org/showbug.cgi?id=2421 https://bugzilla.redhat.com/showbug.cgi?id=1734468

Upstream patch:

http://git.php.net/?p=php-src.git;a=commitdiff;h=8947fd9e9fdce87cd6c59817b1db58e789538fe9

A vulnerability was found in curl. This issue occurs due to an erroneous function. A malicious server could make curl within Network Security Services (NSS) get stuck in a never-ending busy loop when trying to retrieve that information. This flaw allows an Infinite Loop, affecting system availability.

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 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.

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.

A double free vulnerability exists in libcurl <8.0.0 when sharing HSTS data between separate "handles". This sharing was introduced without considerations for do this sharing across separate threads but there was no indication of this fact in the documentation. Due to missing mutexes or thread locks two threads sharing the same HSTS data could end up doing a double-free or use-after-free.

A vulnerability exists in curl <7.87.0 HSTS check that could be bypassed to trick it to keep using HTTP. Using its HSTS support, curl can be instructed to use HTTPS instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. However, the HSTS mechanism could be bypassed if the host name in the given URL first uses IDN characters that get replaced to ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) .. Then in a subsequent request, it does not detect the HSTS state and makes a clear text transfer. Because it would store the info IDN encoded but look for it IDN decoded.

A vulnerability was found in curl. The issue occurs because curl's HSTS check can be bypassed to trick it to keep using HTTP. Using its HSTS support, it can instruct curl to use HTTPS directly instead of using an insecure clear-text HTTP step even when HTTP is provided in the URL. This mechanism can be bypassed if the hostname in the given URL uses IDN characters that get replaced with ASCII counterparts as part of the IDN conversion. Like using the character UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) instead of the common ASCII full stop (U+002E) ..

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.

An allocation of resources without limits or throttling vulnerability exists in curl <v7.88.0 based on the "chained" HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable "links" in this "decompression chain" wascapped, but the cap was implemented on a per-header basis allowing a maliciousserver to insert a virtually unlimited number of compression steps simply byusing many headers. The use of such a decompression chain could result in a "malloc bomb", making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.