| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| pageant provides a [PageantStream] type that implements [AsyncRead] and [AsyncWrite] traits and can be used to talk to a running Pageant instance. Prior to pageant 0.2.3, the Windows pageant crate's pageant/src/wmmessage.rs MemoryMap::read function trusts a peer-controlled u32 response length supplied through the 8192-byte Pageant shared-memory mapping reached by AgentClient::connect_pageant. A local process that impersonates the Pageant window can make query_pageant_direct allocate up to approximately 4 GiB and copy beyond the mapped view, reliably crashing a russh client and conditionally exposing adjacent committed memory. This issue is fixed in pageant 0.2.3. |
| The `_nx_secure_x509_asn1_tlv_block_parse()` function parses ASN.1 TLV (tag-length-value) blocks out of DER-encoded data. It is the primitive underneath all X.509 certificate parsing in NetX Secure, and therefore runs on certificates supplied by a remote peer during the TLS handshake.
The function reads the one-byte ASN.1 tag from the caller's buffer *before* checking that the buffer holds at least one byte. When a caller passes a remaining length of zero, the guard correctly returns `NX_SECURE_X509_ASN1_LENGTH_TOO_LONG`, but the read has already happened one byte past the end of the buffer.
code:
nx_secure/src/nx_secure_x509_asn1_tlv_block_parse.c
```
UINT _nx_secure_x509_asn1_tlv_block_parse(const UCHAR *buffer, ULONG *buffer_length, USHORT *tlv_type,
USHORT *tlv_tag_class, ULONG *tlv_length,
const UCHAR **tlv_data, ULONG *header_length)
{
UINT current_index;
USHORT current_tag;
ULONG length;
ULONG length_bytes;
current_index = 0;
current_tag = buffer[current_index]; /* <-- read before the bounds check */
if (*buffer_length < 1)
{
return(NX_SECURE_X509_ASN1_LENGTH_TOO_LONG);
}
```
The remainder of the function is correctly ordered. The multi-byte length path is guarded by `length_bytes > 4 || length_bytes > *buffer_length` before its read loop, the decoded value is checked against `length > *buffer_length`, and the second single-byte length read follows its own `*buffer_length < 1` guard. The tag read is the only load placed ahead of its check. |
| The decoder in `readFromDataView` in lib0 before 0.2.119 can be tricked into reading more than it should from a buffer. The vulnerability allows reading past the decoders' view, thus exposing adjacent process memory. This can be anything that is currently in the head, for example credentials or logs. This is similar to but different from GHSA-r5c8-rf4w-qrq8. |
| Stack-based buffer overflow in Microsoft Local Security Authority Server (lsasrv) allows an authorized attacker to elevate privileges locally. |
| A missing bounds check in the binary decoder in lib0, versions 0.2.1-0.2.117 and earlier and 1.0.0-rc.32 and earlier, lets any unauthenticated remote peer read adjacent process memory and receive it back. `readUint8Array` never compares the wire-supplied length against the decoder's own view, so one over-long length prefix returns whatever the host process allocated next: other tenants' document content, personal data, and live bearer session tokens**, recovered in full and at will. An attacker who can supply bytes to a lib0 decoder which means any peer that can open a socket, including before authentication reads adjacent process memory and, where the consumer echoes, stores or re-serves the decoded value, receives it back. This is patched in version 0.2.118 and 1.0.0-rc.33. |
| CTranslate2 before 4.8.1 contains an out-of-bounds heap read vulnerability in the binary model loader when deserializing string fields without null terminators. Attackers can craft malicious model files to trigger heap memory reads past buffer boundaries, causing crashes or disclosing adjacent heap memory contents. |
| A stack-based buffer overflow vulnerability exists in Pgpool-II, which may allow an unauthenticated attacker to cause abnormal process termination. |
| XS::Parse::Infix versions from 0.40 through 0.49 for Perl treat a number as an array reference.
The wrapper function XS::Parse::Infix generates for a list-associative infix operator checks whether arguments are array references, but it tests using SvRV() rather than SvROK(). SvRV() reads a union slot that only holds a referent once SvROK(sv) is true, so the guard never validates that it is a reference. For an IV or NV that slot holds the number itself, SvRV() returns the caller's value and SvTYPE() dereferences it at offset 12. This will generally result in a segmentation fault.
An application that hands the wrapper a list built from decoded input (for example, from JSON) lets whoever supplies a number in that list choose the address that the interpreter dereferences.
An ordinary string's byte 12 is rarely SVt_PVAV so the guard croaks by luck, but an attacker-crafted string carrying 0x0b there passes, and the buffer is then used as an AV head, with AvARRAY taken from bytes 16-23 and its entries pushed onto the Perl stack as live SVs.
A simple proof-of-concept uses the zip operator:
use Syntax::Operator::Zip 'zip';
my @args = ([1], 2);
zip(@args); |
| Buffer overflow in ANGLE in Google Chrome on on Android prior to 154.0.8037.57 allowed a remote attacker to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Critical) |
| apcupsd through 3.14.14 has an sscanf stack-based buffer overflow in getupsvar() in src/cgi/upsfetch.c (used by upsstats.cgi, multimon.cgi, and upsfstats.cgi), a related issue to CVE-2026-15544. |
| NVIDIA vGPU Virtual GPU Manager for Linux contains a vulnerability in the kernel mode layer where an attacker could cause an out-of-bounds read. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA vGPU Virtual GPU Manager for Linux contains a vulnerability in the firmware where an attacker could cause an out-of-bounds read. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| NVIDIA vGPU Virtual GPU Manager for Linux contains a vulnerability in the kernel mode layer where an attacker could cause an out-of-bounds read. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| In libsmpp35 from 0.1.0 through 1.8.0 out of bound read issue was found in the at smpp34_unpack() function via attacker controlled SMPP PDUs, leading to memory corruption. |
| pgPointcloud through 1.2.5 contains a heap out-of-bounds read vulnerability in dimensional patch WKB deserialization that allows authenticated database users to read adjacent heap memory. Attackers can supply crafted pcpatch values with attacker-controlled size fields to copy heap memory into stored patches for exfiltration or crash the PostgreSQL backend. |
| Out-of-bounds read in Microsoft Standard XPS allows an authorized attacker to disclose information locally. |
| Heap-based buffer overflow in Microsoft Standard XPS allows an authorized attacker to elevate privileges over a network. |
| virtio-win provides Windows paravirtualized drivers for QEMU and KVM. From mm210 until mm320, the Viosock driver permits a low-privilege local process to submit an IOCTL_SELECT request with attacker-controlled VIRTIO_VSOCK_SELECT.Fdss[*].fd_count values that overflow the 32-bit sum used by VIOSockSelect for bounds checking. The wrapped sum can pass the FD_SETSIZE check even though an individual descriptor count is much larger than the expected limit. VIOSockSelectCopyFds then iterates using the unchecked count and writes beyond the allocated pPkt->Fds array in the NonPagedPool kernel heap. Successful exploitation can corrupt kernel memory and enable privilege escalation in a Windows guest running the driver. This issue is fixed in mm320. |
| Improper Verification of Source of a Communication Channel in the ADS discovery of the Go implementation of Apache PLC4X (PLC4Go) allows an attacker able to send UDP datagrams to the discovering host to redirect subsequent connections to an arbitrary, attacker-chosen address. The discovery result's connection
address was derived from the AmsNetId claimed in the response body rather than from the datagram's actual source address. One spoofed discovery response can therefore insert an inventory entry pointing at any host, including hosts outside the local network, and an application that connects to discovered devices
will open its ADS session, including any configured route credentials, to that host.
Additionally, discovery listeners in both implementations can be disabled by a single malformed datagram:
- In PLC4Go ADS discovery, a short version block causes a panic that ends the listener for the rest of the discovery call, so legitimate devices answering afterwards are not reported.
- In PLC4J, the ADS and EtherNet/IP discoverers stop on an unhandled exception from a malformed response.
- The PLC4J Modbus discoverer can be made to spin indefinitely, consuming a CPU core, by a scanned host that sends a partial response.
Exploitation requires the application to invoke the discovery API, which is opt-in, and for the connection redirect, to act on the discovered items.
This issue affects Apache PLC4X: PLC4Go from 0.11.0 before 1.0.0; PLC4J ADS and Modbus drivers from 0.10.0 before 1.0.0; PLC4J EtherNet/IP driver 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. Version 1.0.0 derives the connection address from the datagram's source address and logs a warning when the claimed AmsNetId disagrees with it. |
