Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.2.20. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.5 (Confidenti
Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is 7.2.20. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. CVSS 3.1 Base Score 7.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).
USN-8944-1 updated ca-certificates. This update provides the corresponding
changes for Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, and
Ubuntu 20.04 LTS by removing the "emSign ECC Root CA - G3" and "Comodo AAA
Services root" CA certificates.
Original advisory details:
This update removes the "emSign ECC Root CA - G3" CA certificate due to
intermediate CA certificates being compromised.
In addition, in Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS,
the ca-certificates package contained outdated CA certificates. This
update refreshes the included certificates to those contained in the 2.90
version of the Mozilla ce
Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 8u503, 8u503-perf, 11.0.32.1, 17.0.20.1, 21.0.12.1, 25.0.4.1, 27; Oracle GraalVM for JDK: 17.0.20.1 and 21.0.12.1; Oracle GraalVM Enterprise Edition: 21.3.19.1.1. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert o
libcurl could accidentally return a URL for `curl_easy_getinfo()`'s
`CURLINFO_EFFECTIVE_URL` option containing credentials, even though neither
the URL provided to libcurl nor the redirected URL did.
When processing an HTTP redirect to a URL containing userinfo (a
`username:password` component), curl might erroneously retain and re-transmit
the original host's HTTP Negotiate authentication state. Consequently, a
malicious server can trigger a redirect containing arbitrary userinfo to force
curl to send a freshly minted Kerberos ticket—generated using the ambient
identity of the client process to an untrusted third-party host, effectively
bypassing the domain-scoping restrictions normally enforced by the absence of
`--location-trusted`.
A deeply nested multipart MIME structure constructed via the public API causes
a stack overflow in libcurl during normal cleanup operations. An excessive
recursion depth within `curl_mime_free` leads to unbounded stack frame
allocation during structure traversal, ultimately crashing the host process.
When invoked with `--remote-header-name` (`-J`), curl fails to preserve its
documented anti-clobbering protection if an intermediate 103 Early Hints
response precedes the final HTTP response, or if an `ETag` header is processed
before `Content-Disposition` under `--etag-save`. This flaw allows an HTTP(S)
server to overwrite an existing local file specified in the
`Content-Disposition` header despite the presence of the `-J` non-overwrite
constraint.
libcurl's TFTP state machine fails to validate state transitions against the
requested transfer direction, accepting opening server responses for both
reads and writes interchangeably. A malicious TFTP server can respond to a
download request in a way that forces the client into transmit mode, prompting
libcurl to consume and transmit data from the handle's persistent
`CURLOPT_READDATA` pointer - including data remaining from unrelated prior
operations, such as an HTTP POST request executed on a reused handle.
When an FTP wildcard `LIST` operation fails, libcurl omits the restoration
path meant for successful listings, leaving the write callback set to the
internal listing parser and the write callback data pointing directly to the
easy handle. Subsequent reuse of this handle triggers an immediate crash, and
cloning it via `curl_easy_duphandle()` copies this corrupted state into the
duplicate. If the original handle is subsequently freed, executing a transfer
on the cloned handle causes a heap use-after-free read against the dangling
handle reference; alternatively, reusing the original or cloned handle while
changing only `CURLOPT_WRITEDATA` (and
By permanently omitting the final control-response line, a malicious FTP,
IMAP, POP3, or SMTP server can exploit libcurl and completely bypass its
configured transfer timeout mechanism, indefinitely blocking all concurrent
transfers bound to the same multi-handle.
When writing a long cookie name and value to a Netscape cookie jar, a remote
HTTP server can make `curl` write a record that exceeds its line-length
parsing limit. Consequently, any subsequent `curl` invocation reading from
that same cookie jar using `--cookie` silently aborts parsing prematurely upon
encountering the too long line, ignoring all subsequent valid cookies in the
file.
When built with wolfSSL, curl can successfully validate a pinned public key
hash against a key the TLS peer does not possess. During the TLS handshake,
wolfSSL validates the connection, but curl's subsequent re-parsing of the same
certificate - tricked by a manipulated validity length field - extracts and
matches a different embedded key, incorrectly authorizing the pinned public
key.
When libcurl uses libssh2 with a hashed `known_hosts` file, an unrelated
initial entry can cause host key validation to report a key *mismatch* as a
*missing* key to the `CURLOPT_SSH_KEYFUNCTION` callback.
Enabling `CURLOPT_CRLF` causes curl to advertise the raw input byte count in
the `IMAP APPEND {N}` literal while transmitting line-ending expanded data.
The server reads only $N$ bytes for the payload, causing the remaining
overflow bytes to be interpreted and executed as pipelined IMAP commands
within the authenticated session.
An authenticated HTTPS origin can supply an HSTS `max-age` value that the
parser accepts, but time serialization later fails to process. On 64-bit
systems, extreme max-age values compute an absolute expiry within standard
time integer limits that exceeds calendar time structure bounds. During cache
saves, the original HSTS file is truncated before writing a temporary
replacement; when serialization fails, the temporary file is deleted, leaving
an empty or partial cache. Because the save error is silently ignored during
cleanup, curl exits successfully despite the data loss.
Importing a `includeSubDomains` parent HSTS entry before a longer-lived child
entry, silently drops the child. Consequently, when the parent expires, the
child's valid HSTS policy is lost, causing curl to issue unencrypted HTTP
requests rather than upgrading to HTTPS.
When using ambient user credentials, an HTTP request directed to one origin
may be dispatched over a connection previously authenticated via Negotiate for
a different origin, leaving the request's intended credentials unused.
libcurl's connection cache match function never considers the automatic client
certificate option, so a cached, already authenticated Schannel connection can
be handed to a transfer that got redirected to a different origin, even though
the code explicitly switched off the auto client cert option for that transfer
to prevent exactly this.
An HTTP proxy can trick libcurl into sending the origin's credentials (Basic
password, or a Negotiate/Kerberos ticket) to the proxy itself, by answering
the `CONNECT` tunnel request with 401 `WWW-Authenticate:` instead of the
expected 407 `Proxy-Authenticate:`.