In the Linux kernel, the following vulnerability has been resolved:
xml.parsers.expat and xml.etree.ElementTree use insufficient entropy for Expat hash-flooding protection, which allows a crafted XML document to trigger hash flooding.\r\n\r\nFully mitigating this vulnerability requires both updating libexpat to 2.8.0 or later and applying this patch.
A heap-based buffer overflow problem was found in glib through an incorrect calculation of buffer size in the gescapeuristring() function. If the string to escape contains a very large number of unacceptable characters (which would need escaping), the calculation of the length of the escaped string could overflow, leading to a potential write off the end of the newly allocated string.
Accessibility. This issue was addressed through improved state management.
Accessibility. This issue was addressed through improved state management.
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
A flaw was found in libxml2. This vulnerability occurs when the library processes a specially crafted XML Schema Definition (XSD) validated document that includes an internal entity reference. An attacker could exploit this by providing a malicious document, leading to a type confusion error that causes the application to crash. This results in a denial of service (DoS), making the affected system or application unavailable.
React Router is a router for React. In versions 7.7.0 through 7.13.1, when using React Router's unstable React Server Components (RSC) APIs, there is a potential client-side Cross-Site Scripting (XSS) vulnerability in the RSC redirect handling if redirects come from untrusted sources. This does not impact applications that are not using the unstable RSC APIs in React Router. This is patched in version 7.13.2.
Last updated 2 July 2026
Accelerate. An out-of-bounds read was addressed with improved bounds checking.
Issue summary: During processing of a crafted CMS EnvelopedData message with KeyAgreeRecipientInfo a NULL pointer dereference can happen.
Impact summary: Applications that process attacker-controlled CMS data may crash before authentication or cryptographic operations occur resulting in Denial of Service.
When a CMS EnvelopedData message that uses KeyAgreeRecipientInfo is processed, the optional parameters field of KeyEncryptionAlgorithmIdentifier is examined without checking for its presence. This results in a NULL pointer dereference if the field is missing.
Applications and services that call CMSdecrypt() on untrusted input (e.g., S/MIME processing or CMS-based protocols) are vulnerable.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.
Issue summary: An uncommon configuration of clients performing DANE TLSA-based server authentication, when paired with uncommon server DANE TLSA records, may result in a use-after-free and/or double-free on the client side.
Impact summary: A use after free can have a range of potential consequences such as the corruption of valid data, crashes or execution of arbitrary code.
However, the issue only affects clients that make use of TLSA records with both the PKIX-TA(0/PKIX-EE(1) certificate usages and the DANE-TA(2) certificate usage.
By far the most common deployment of DANE is in SMTP MTAs for which RFC7672 recommends that clients treat as 'unusable' any TLSA records that have the PKIX certificate usages. These SMTP (or other similar) clients are not vulnerable to this issue. Conversely, any clients that support only the PKIX usages, and ignore the DANE-TA(2) usage are also not vulnerable.
The client would also need to be communicating with a server that publishes a TLSA RRset with both types of TLSA records.
No FIPS modules are affected by this issue, the problem code is outside the FIPS module boundary.
Issue summary: When a delta CRL that contains a Delta CRL Indicator extension is processed a NULL pointer dereference might happen if the required CRL Number extension is missing.
Impact summary: A NULL pointer dereference can trigger a crash which leads to a Denial of Service for an application.
When CRL processing and delta CRL processing is enabled during X.509 certificate verification, the delta CRL processing does not check whether the CRL Number extension is NULL before dereferencing it. When a malformed delta CRL file is being processed, this parameter can be NULL, causing a NULL pointer dereference.
Exploiting this issue requires the X509VFLAGUSEDELTAS flag to be enabled in the verification context, the certificate being verified to contain a freshestCRL extension or the base CRL to have the EXFLAGFRESHEST flag set, and an attacker to provide a malformed CRL to an application that processes it.
The vulnerability is limited to Denial of Service and cannot be escalated to achieve code execution or memory disclosure. For that reason the issue was assessed as Low severity according to our Security Policy.
The FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue, as the affected code is outside the OpenSSL FIPS module boundary.
802.1X. An authentication issue was addressed with improved state management.
The html.Parse function in golang.org/x/net/html has quadratic parsing complexity when processing certain inputs, which can lead to denial of service (DoS) if an attacker provides specially crafted HTML content.
Last updated 2 June 2026
Heap Buffer Overflow in Hexadecimal Conversion
Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the 'DEFAULT' keyword.
Impact summary: A less preferred key exchange may be used even when a more preferred group is supported by both client and server, if the group was not included among the client's initial predicated keyshares. This will sometimes be the case with the new hybrid post-quantum groups, if the client chooses to defer their use until specifically requested by the server.
If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to interpolate the built-in default group list into its own configuration, perhaps adding or removing specific elements, then an implementation defect causes the 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups were treated as a single sufficiently secure 'tuple', with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported.
As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as 'X25519MLKEM768', if the client's configuration results in only 'classical' groups (such as 'X25519' being the only ones in the client's initial keyshare prediction).
OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS 1.3 key agreement group on TLS servers. The old syntax had a single 'flat' list of groups, and treated all the supported groups as sufficiently secure. If any of the keyshares predicted by the client were supported by the server the most preferred among these was selected, even if other groups supported by the client, but not included in the list of predicted keyshares would have been more preferred, if included.
The new syntax partitions the groups into distinct 'tuples' of roughly equivalent security. Within each tuple the most preferred group included among the client's predicted keyshares is chosen, but if the client supports a group from a more preferred tuple, but did not predict any corresponding keyshares, the server will ask the client to retry the ClientHello (by issuing a Hello Retry Request or HRR) with the most preferred mutually supported group.
The above works as expected when the server's configuration uses the built-in default group list, or explicitly defines its own list by directly defining the various desired groups and group 'tuples'.
No OpenSSL FIPS modules are affected by this issue, the code in question lies outside the FIPS boundary.
OpenSSL 3.6 and 3.5 are vulnerable to this issue.
OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.
OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.
React Router is a router for React. In versions 7.5.1 through 7.13.1, when using Framework Mode with pre-rendering enabled, improper neutralization of the HTTP Location header value can permit Cross-Site Scripting (XSS) in the statically generated HTML files if the redirect location comes from an untrusted source. This does not impact applications using Declarative Mode (<BrowserRouter>) or Data Mode (createBrowserRouter/<RouterProvider>). This is patched in version 7.13.2.
Summary
Cookies set with the cookies parameter on requests are sent after following a cross-origin redirect.
Impact
If a developer uses the cookies parameter on a per-request basis then sensitive data might be leaked to an attacker if they manage to control a redirect.
Workaround
If unable to upgrade, using a Cookie header in the headers parameter is not vulnerable.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/f54c40851b0d6c4bbdab97ba518a223adda32478
IBM API Connect 12.1.0.0 through 12.1.0.3 uses default credentials which could allow an attacker to gain unauthorized access to the application before the system enforces a credential update.
IBM API Connect 10.0.8.0 through 10.0.8.9 and 12.1.0.0 through 12.1.0.3 contains an unauthenticated SQL injection vulnerability in the password reset functionality.
CoreDNS through 1.10.1 enables attackers to achieve DNS cache poisoning and inject fake responses via a birthday attack.
When using CURLOPTPINNEDPUBLICKEY 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 certificate verification.
When doing SSH-based transfers using either SCP or SFTP, and asked to do public key authentication, curl would wrongly still ask and authenticate using a locally running SSH agent.
When doing SSH-based transfers using either SCP or SFTP, and setting the knownhosts file, libcurl could still mistakenly accept connecting to hosts not present in the specified file if they were added as recognized in the libssh global knownhosts file.
Summary PsySH automatically loads and executes a .psysh.php file from the Current Working Directory (CWD) on startup. If an attacker can write to a directory that a victim later uses as their CWD when launching PsySH, the attacker can trigger arbitrary code execution in the victim's context. When the victim runs PsySH with elevated privileges (e.g., root), this results in local privilege escalation.
Details PsySH supports per-directory configuration via a .psysh.php file located in the process CWD. This file is executed implicitly when PsySH starts, without requiring explicit opt-in and without validating that the file and directory are safe (e.g., owned by the current user and not group/world-writable).
This enables a CWD poisoning scenario: a low-privileged user can plant a malicious .psysh.php in any directory they can write to, then wait for a higher-privileged user to start PsySH while their shell is in that directory.
PoC 1. As a low-privileged user, create a malicious .psysh.php in an attacker-writable directory (example: /tmp):
bash bob@localhost:/tmp$ echo "<?php system('id > poc.txt'); ?>" > .psysh.php bob@localhost:/tmp# ls -lah .psysh.php -rw-r--r-- 1 bob bob 33 Jan 28 11:17 .psysh.php
2. As the victim user, start PsySH with CWD set to that directory and exit:
bash root@localhost:/tmp# cd /tmp root@localhost:/tmp# ./psysh Psy Shell v0.12.18 (PHP 8.1.2-1ubuntu2.23 — cli) by Justin Hileman New PHP manual is available (latest: 3.0.1). Update with doc --update-manual exit
INFO Goodbye.
3. Verify code execution triggered in the victim context:
bash bob@localhost:/tmp$ ls -lah poc.txt -rw-r--r-- 1 root root 39 Jan 28 11:19 poc.txt bob@localhost:/tmp$ cat poc.txt uid=0(root) gid=0(root) groups=0(root)
Impact
This is a CWD configuration poisoning issue leading to arbitrary code execution in the victim user’s context. If a privileged user (e.g., root, a CI runner, or an ops/debug account) launches PsySH with CWD set to an attacker-writable directory containing a malicious .psysh.php, the attacker can execute commands with that privileged user’s permissions, resulting in local privilege escalation.
Downstream consumers that embed PsySH inherit this risk. For example, Laravel Tinker (php artisan tinker) uses PsySH. If a privileged user runs Tinker while their shell is in an attacker-writable directory, the .psysh.php auto-load behavior can be abused in the same way to execute attacker-controlled code under the victim’s privileges.
When doing a second SMB request to the same host again, curl would wrongly use a data pointer pointing into already freed memory.
A security flaw has been discovered in musl libc up to 1.2.6. Affected is the function iconv of the file src/locale/iconv.c of the component GB18030 4-byte Decoder. Performing a manipulation results in inefficient algorithmic complexity. The attack must be initiated from a local position. To fix this issue, it is recommended to deploy a patch.
An issue was discovered in musl libc 0.7.10 through 1.2.6. Stack-based memory corruption can occur during qsort of very large arrays, due to incorrectly implemented double-word primitives. The number of elements must exceed about seven million, i.e., the 32nd Leonardo number on 32-bit platforms (or the 64th Leonardo number on 64-bit platforms, which is not practical).