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 vulnerability was found in libpcre in PCRE before 8.44 allows an integer overflow via a large number after a (?C substring.

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

A vulnerability was found in curl. This issue occurs because it mishandles message verification failures when curl does FTP transfers secured by krb5. This flaw makes it possible for a Man-in-the-middle attack to go unnoticed and allows data injection into the client.

A vulnerability was found in curl. This issue occurs because the number of acceptable "links" in the "decompression chain" was unbounded, allowing a malicious server to insert a virtually unlimited number of compression steps. This flaw leads to a denial of service, either by mistake or by a malicious actor.

A cleartext transmission of sensitive information vulnerability exists in curl <v7.88.0 that could cause HSTS functionality to behave incorrectly when multiple URLs are requested in parallel. 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. This HSTS mechanism would however surprisingly fail when multiple transfers are done in parallel as the HSTS cache file gets overwritten by the most recentlycompleted transfer. A later HTTP-only transfer to the earlier host name would then not get upgraded properly to HSTS.

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

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

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.

curl 7.61.0 through 7.76.1 suffers from exposure of data element to wrong session due to a mistake in the code for CURLOPTSSLCIPHERLIST when libcurl is built to use the Schannel TLS library. The selected cipher set was stored in a single "static" variable in the library, which has the surprising side-effect that if an application sets up multiple concurrent transfers, the last one that sets the ciphers will accidentally control the set used by all transfers. In a worst-case scenario, this weakens transport security significantly.

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.

libcurl would reuse a previously created connection even when a TLS or SSHrelated option had been changed that should have prohibited reuse.libcurl keeps previously used connections in a connection pool for subsequenttransfers to reuse if one of them matches the setup. However several TLS andSSH settings were left out from the configuration match checks making themmatch too easily.

An insufficiently protected credentials vulnerability exists in curl 4.9 to and include curl 7.82.0 are affected that could allow an attacker to extract credentials when follows HTTP(S) redirects is used with authentication could leak credentials to other services that exist on different protocols or port numbers.

An information disclosure vulnerability exists in curl 7.65.0 to 7.82.0 are vulnerable that by using an IPv6 address that was in the connection pool but with a different zone id it could reuse a connection instead.

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

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 flaw was found in the way curl handled telnet protocol option for sending environment variables, which could lead to sending of uninitialized data from a stack-based buffer to the server. This issue leads to potentially revealing sensitive internal information to the server using a clear-text network protocol.

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 curl. The flaw lies in how curl handles cached or pipelined responses that it receives from either a IMAP, POP3, SMTP or FTP server before the TLS upgrade using STARTTLS. In such a scenario curl even after upgrading to TLS would trust these cached responses treating them as valid and authenticated and use them. An attacker could potentially use this flaw to carry out a Man-In-The-Middle attack. The highest threat from this vulnerability is to data confidentiality.

A flaw was found in curl in the way curl handles a file hash mismatch after downloading content using the Metalink feature. This flaw allows malicious actors controlling a hosting server to trick users into downloading malicious content. The highest threat from this vulnerability is to integrity.

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 malicious server can use the PASV response to trick curl into connecting back to a given IP address and port, and this way potentially make curl extract information about services that are otherwise private and not disclosed, for example doing port scanning and service banner extractions. If curl operates on a URL provided by a user (which by all means is an unwise setup), a user can exploit that and pass in a URL to a malicious FTP server instance without needing any server breach to perform the attack.

A flaw was found in the way curl handled telnet protocol option for sending environment variables, which could lead to sending of uninitialized data from a stack-based buffer to the server. This issue leads to potentially revealing sensitive internal information to the server using a clear-text network protocol.

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.

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.

libcurl wrongly allows cookies to be set for Top Level Domains (TLDs) if thehost name is provided with a trailing dot.curl can be told to receive and send cookies. curl's "cookie engine" can bebuilt with or without Public Suffix Listawareness. If PSL support not provided a more rudimentary check exists to atleast prevent cookies from being set on TLDs. This check was broken if thehost name in the URL uses a trailing dot.This can allow arbitrary sites to set cookies that then would get sent to adifferent and unrelated site or domain.

The curl URL parser wrongly accepts percent-encoded URL separators like '/'when decoding the host name part of a URL making it a different URL usingthe wrong host name when it is later retrieved.For example a URL like http://example.com%2F127.0.0.1/ would be allowed bythe parser and get transposed into http://example.com/127.0.0.1/. This flawcan be used to circumvent filters checks and more.

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.

An authentication bypass vulnerability exists in libcurl <8.0.0 in the FTP connection reuse feature that can result in wrong credentials being used during subsequent transfers. Previously created connections are kept in a connection pool for reuse if they match the current setup. However certain FTP settings such as CURLOPTFTPACCOUNT CURLOPTFTPALTERNATIVETOUSER CURLOPTFTPSSLCCC and CURLOPTUSESSL were not included in the configuration match checks causing them to match too easily. This could lead to libcurl using the wrong credentials when performing a transfer potentially allowing unauthorized access to sensitive information.

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.