ssl.SSLContext.wrapbio() didn't require the serverhostname argument to not be None if ssl.SSLContext.checkhostname was set. Due to a missing parameter check in SSLObject, if the serverhostname argument isn't supplied then hostname verification would be silently skipped.

This defect could lead to programs where certificate hostname verification appeared to be succeeding with SSLContext.checkhostname = True and no ValueError being raised due to misconfiguration.

If the program passes a serverhostname value that isn't an empty string or None to any of these APIs then certificate hostname verification proceeds as expected and the program is not affected by this vulnerability.

Mitigating this vulnerability doesn't require updating Python or applying the patch. To mitigate, pass a valid non-None and non-empty serverhostname value to SSLContext.wrapbio(), asyncio.createconnection(), or asyncio.loop.starttls() and certificate hostname verification will proceed as expected. Upgrading to the latest version of Python or applying the patch only changes the behavior from silently skipping hostname verification to raising a ValueError, similar to SSLContext.wrapsocket(), when serverhostname isn't supplied.

A remote, unauthenticated TLS client can make a server crash or call through a freed pointer if its snicallback assigns a different context to SSLSocket.context (the documented way to select a certificate per server name) and nothing else keeps the original ssl.SSLContext alive. Typical cases are servers that create an SSLContext per connection or replace it while connections are open; servers that wrap their listening socket with it are not affected.

Mitigation: keep a reference to every SSLContext that sets snicallback for the lifetime of the server. TLS clients are not affected.

Integer Overflow, Improper Validation of Array Index, Uncontrolled Recursion and Memory Allocation with Excessive Size Value in the Go implementation of Apache PLC4X (PLC4Go) allow a malicious device, or an attacker able to inject network traffic, to crash or exhaust the memory of the client application, causing a denial of service.

The individual defects are: - Generated parsers pre-allocate arrays with the element count claimed on the wire (0.13.0 through 0.13.1). - Transport read helpers allocate buffers of the size claimed on the wire without an upper bound. - ADS and KNXnet/IP response handling indexes into received data without checking its length, causing a panic. - ADS and EIP frame-length handling accepts, or arithmetically wraps to, a length of zero, breaking message framing. - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Java implementation is covered by CVE-2026-102509 https://cveprocess.apache.org/cve5/CVE-2026-102509 .

Additionally, length and position arithmetic in generated serializers was performed in 16-bit integers. If an application forwards attacker-influenced payloads larger than 8 KB, the length field wraps, and the remainder of the payload may be interpreted by the receiving device (for example, an ADS PLC) as additional, independent protocol messages.

This issue affects Apache PLC4X: from 0.11.0 before 1.0.0. PLC4Go is consumed as the Go module github.com/apache/plc4x/plc4go; versions refer to the corresponding Apache PLC4X releases.

Users are recommended to upgrade to version 1.0.0, which fixes the issue.

Memory Allocation with Excessive Size Value, Allocation of Resources Without Limits, and Uncontrolled Recursion in the Java implementation of Apache PLC4X (PLC4J) allow a malicious or impersonated device to exhaust the memory or stack of the client application, causing a denial of service.

In the OPC UA driver these defects are reachable before authentication: the offending data is parsed while the secure channel and session are being established, before the server's identity has been bound to it. Configuring a trusted server therefore does not prevent exploitation by an attacker who can impersonate it.

The individual defects are: - Length-prefixed byte strings are allocated at the size claimed on the wire before the length is checked against the data actually received (0.10.0 through 0.13.1). - Array fields in generated protocol parsers pre-allocate a list with the element count claimed on the wire, allowing a single count field to trigger a multi-gigabyte allocation. This parser is shared by all PLC4J drivers; the OPC UA driver is the verified pre-authentication path (0.10.0 through 0.13.1). - The OPC UA driver accumulates message chunks without enforcing the negotiated maximum chunk count and message size (0.12.0 through 0.13.1). - The OPC UA driver pre-allocates collections using element counts received from the server (0.10.0 through 0.13.1). - Recursive protocol types are parsed without a nesting-depth limit. The same defect in the Go implementation is covered by CVE-2026-102510 https://cveprocess.apache.org/cve5/CVE-2026-102510 .

This issue affects Apache PLC4X: from 0.10.0 before 1.0.0.

Users are recommended to upgrade to version 1.0.0, which fixes the issue.

Race condition in tempfile.TemporaryDirectory cleanup allows deleting files outside the temporary directory

An out-of-bounds write issue was addressed with improved bounds checking. This issue is fixed in iOS 26.7.1 and iPadOS 26.7.1, macOS Sequoia 15.8.1, macOS Tahoe 26.7.1. Processing a maliciously crafted file may lead to arbitrary code execution. Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 27.

Citrix NetScaler ADC and NetScaler Gateway contain an improper input validation vulnerability that could allow an unauthenticated attacker to execute arbitrary commands.

Citrix NetScaler ADC and NetScaler Gateway contain an improper restriction of operations within the bounds of a memory buffer vulnerability that could allow for remote code execution or denial of service