curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
curl would wrongly reuse an existing HTTP proxy connection doing CONNECT to a server, even if the new request uses different credentials for the HTTP proxy. The proper behavior is to create or use a separate connection.
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a redirect to a second URL, curl could leak that token to the second hostname under some circumstances. If the hostname that the first request is redirected to has information in the used .netrc file, with either of the `machine` or `default` keywords, curl would pass on the bearer token set for the first host also to the second one.
libcurl can in some circumstances reuse the wrong connection when asked to do an Negotiate-authenticated HTTP or HTTPS request. libcurl features a pool of recent connections so that subsequent requests can reuse an existing connection to avoid overhead. When reusing a connection a range of criterion must first be met. Due to a logical error in the code, a request that was issued by an application could wrongfully reuse an existing connection to the same server that was authenticated using diff
When doing TLS related transfers with reused easy or multi handles and altering the `CURLSSLOPT_NO_PARTIALCHAIN` option, libcurl could accidentally reuse a CA store cached in memory for which the partial chain option was reversed. Contrary to the user's wishes and expectations. This could make libcurl find and accept a trust chain that it otherwise would not.
When an OAuth2 bearer token is used for an HTTP(S) transfer, and that transfer performs a cross-protocol redirect to a second URL that uses an IMAP, LDAP, POP3 or SMTP scheme, curl might wrongly pass on the bearer token to the new target host.
When doing multi-threaded LDAPS transfers (LDAP over TLS) with libcurl, changing TLS options in one thread would inadvertently change them globally and therefore possibly also affect other concurrently setup transfers. Disabling certificate verification for a specific transfer could unintentionally disable the feature for other threads as well.
When using `CURLOPT_PINNEDPUBLICKEY` option with libcurl or `--pinnedpubkey` with the curl tool, curl should check the public key of the server certificate to verify the peer. This check was skipped in a certain condition that would then make curl allow the connection without performing the proper check, thus not noticing a possible impostor. To skip this check, the connection had to be done with QUIC with ngtcp2 built to use GnuTLS and the user had to explicitly disable the standard certificat
curl's code for managing SSH connections when SFTP was done using the wolfSSH powered backend was flawed and missed host verification mechanisms. This prevents curl from detecting MITM attackers and more.
curl's WebSocket code did not update the 32-bit mask pattern for each new outgoing frame as the specification says. Instead it used a fixed mask that persisted and was used throughout the entire connection. A predictable mask pattern allows for a malicious server to induce traffic between the two communicating parties that could be interpreted by an involved proxy (configured or transparent) as genuine, real, HTTP traffic with content and thereby poison its cache. That cached poisoned content c
A flaw was found in hawtio-operator. When a custom Route TLS secret is configured and the operator runs at debug log level 1 or higher, the entire Route object — including the TLS private key in PEM format — is serialized to JSON and written to the operator's standard output. Operator logs are typically forwarded to centralized logging systems and readable by anyone with pods/log access in the openshift-operators namespace. Debug level 1 is a low threshold commonly enabled during troubleshooting
A weakness has been identified in Portabilis i-Educar up to 2.10. Affected is an unknown function of the file FinalStatusImportService.php of the component Final Status Import. Executing a manipulation of the argument school_id can lead to improper authorization. The attack can be executed remotely. The exploit has been made available to the public and could be used for attacks. Upgrading to version 2.11.0 is able to address this issue. Upgrading the affected component is advised. The vendor exp
Yao through v1.0.0-rc22 authenticates but fails to authorize the GET /user/teams/:id endpoint, allowing any logged-in user to read full team records. Attackers can supply a known team identifier to retrieve sensitive team data including name, description, owner information, and settings without membership verification.
Refly through 1.1.0 contains a server-side request forgery vulnerability in the POST /v1/misc/scrape endpoint that fetches caller-supplied URLs without validating the scheme, host, or resolved address. Authenticated attackers can make the backend issue requests to loopback, private, and link-local addresses including cloud metadata services to read page titles and descriptions of internal resources.
A denial-of-service issue was addressed with improved input validation. This issue is fixed in iOS 27 and iPadOS 27. A remote attacker may be able to cause a denial-of-service.
An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in iOS 26.7 and iPadOS 26.7, iOS 27 and iPadOS 27, macOS Golden Gate 27, macOS Sequoia 15.8, macOS Tahoe 26.7, visionOS 27, watchOS 27. A sandboxed process may be able to circumvent sandbox restrictions.
On affected platforms running Arista EOS with both 802.1X port authentication and the RADIUS proxy feature configured with dynamic authorization, a low-privileged attacker on an adjacent network segment who induces a RADIUS packet through a configured RADIUS proxy client can prevent RADIUS dynamic authorization messages, including Change-of-Authorization (CoA) and Disconnect-Requests as defined in RFC 5176, from being applied to locally authenticated 802.1X sessions. This allows an endpoint sess
IBM MQ 9.1.0.0 through 9.1.0.37 LTS, 9.2.0.0 through 9.2.0.43 LTS, 9.3.0.0 through 9.3.0.41 LTS, 9.3.0.0 through 9.3.5.1 CD, 9.4.0.0 through 9.4.0.25 LTS, 9.4.0.0 through 9.4.5.1 CD, and 10.0.0.0 could allow an authenticated attacker with MFT publish authority to obtain sensitive information or cause a denial of service due to XML external entity injection in the mqweb MFT REST API.
IBM Cloud Pak for Business Automation could allow an authenticated user to cause a denial of service due to uncontrolled resource consumption.
IBM Cloud Pak for Business Automation could allow a remote attacker to bypass authorization and invoke restricted endpoints due to improper validation of HTTP headers.
Interpretation conflict in Safebrowsing in Google Chrome on on Mac prior to 153.0.8010.36 allowed a remote attacker leveraging social engineering to bypass system access restrictions via a crafted file. (Chromium security severity: Low)