CVE-2019-3861
An out of bounds read flaw was discovered in libssh2 before 1.8.1 in the way SSH packets with a padding length value greater than the packet
CVSS
5.0
Medium
EPSS
5.1%
p93
KEV
—
Exploit Today
28
0-100
Published: Mar 25, 2019 · Last modified: Oct 14, 2026 · CWE-125
5.1%EPSS · 30 days5.1%
2026-10-162026-11-12
An out of bounds read flaw was discovered in libssh2 before 1.8.1 in the way SSH packets with a padding length value greater than the packet length are parsed. A remote attacker who compromises a SSH server may be able to cause a Denial of Service or read data in the client memory.
- lists.opensuse.orghttp://lists.opensuse.org/opensuse-security-announce/2019-03/msg00040.html
- lists.opensuse.orghttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00003.html
- access.redhat.comhttps://access.redhat.com/errata/RHSA-2019:2136
- bugzilla.redhat.comhttps://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3861
- lists.debian.orghttps://lists.debian.org/debian-lts-announce/2019/03/msg00032.html
- lists.fedoraproject.orghttps://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5DK6VO2CEUTAJFYIKWNZKEKYMYR3NO2O/
- seclists.orghttps://seclists.org/bugtraq/2019/Apr/25
- security.netapp.comhttps://security.netapp.com/advisory/ntap-20190327-0005/
- www.debian.orghttps://www.debian.org/security/2019/dsa-4431
- www.libssh2.orghttps://www.libssh2.org/CVE-2019-3861.html
- www.oracle.comhttps://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html
- lists.opensuse.orghttp://lists.opensuse.org/opensuse-security-announce/2019-03/msg00040.html
- lists.opensuse.orghttp://lists.opensuse.org/opensuse-security-announce/2019-04/msg00003.html
- access.redhat.comhttps://access.redhat.com/errata/RHSA-2019:2136
- bugzilla.redhat.comhttps://bugzilla.redhat.com/show_bug.cgi?id=CVE-2019-3861
- lists.debian.orghttps://lists.debian.org/debian-lts-announce/2019/03/msg00032.html
- lists.fedoraproject.orghttps://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/5DK6VO2CEUTAJFYIKWNZKEKYMYR3NO2O/
- seclists.orghttps://seclists.org/bugtraq/2019/Apr/25
- security.netapp.comhttps://security.netapp.com/advisory/ntap-20190327-0005/
- www.debian.orghttps://www.debian.org/security/2019/dsa-4431
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-646755.3 MED—
———BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.5 and 1.5.1, a single unauthenticated BACnet/IP UDP datagram (port 47808) triggers an out-of-bounds read in xy_color_decode() (src/bacnet/lighting.c), reachable pre-authentication through two default-registered service handlers: the UnconfirmedRequest WriteGroup service (0x0A) and Confirmed WriteProperty on a BACnetXYColor-typed property. This issue has been patched in versions 1.4.5, 1.5.1, and 1.6.0.5hCVE-2026-62976——
———BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to version 1.5.1, the RAMFS-backed FILE object implementation stores appended records as NUL-terminated strings, but its record-counting logic later walks the buffer as if an additional terminating empty record were present. As a result, two consecutive AtomicWriteFile(record-access) append requests can cause record_count() to call bacnet_strnlen() on a pointer that is already one byte past the end of the heap allocation. This issue has been patched in versions 1.5.1 and 1.6.0.5hCVE-2026-62975——
———BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to version 1.5.1, the RAMFS-backed FILE implementation accepts AtomicWriteFile(record-access) requests that replace existing records with caller-controlled content. If a client replaces a record with shorter data, the backend can shrink the heap allocation and then continue processing with a trailing-copy length derived from the old layout. During that replace path, the RAMFS backend computes the trailing-copy length from the old file layout, then shrinks the heap allocation, and finally uses the stale length in memmove(). As a result, the source range of that memmove() can extend beyond the end of the reallocated heap buffer, producing a heap out-of-bounds read. This issue has been patched in versions 1.5.1 and 1.6.0.5hCVE-2026-129217——
———In FRRouting (FRR) 8.3 through 10.5.1, bgp_notify_decapsulate_hard_reset() in bgpd/bgp_packet.c does not validate the length of the data field of a received BGP NOTIFICATION Cease/Hard Reset message (RFC 8538). When the data field is exactly one byte long, the function reads one byte past the end of a heap buffer and the 16-bit length of the encapsulated data underflows to 65535, causing a 65535-byte out-of-bounds heap read followed by an assertion failure. A remote BGP peer that has established a session and negotiated the Graceful Restart capability with the Notification (N) bit can send such a message to crash the bgpd daemon, terminating all BGP sessions (denial of service). This is fixed in 10.0.5, 10.1.5, 10.2.6, 10.3.4, 10.4.3, 10.5.2 and 10.6.0.8hCVE-2026-629737.5 HIG—
———BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.5, 1.5.1, and 1.6.0, a remote out-of-bounds read exists in the official BACnet client application apps/readpropm in bacnet-stack commit e2bdbf6. When readpropm sends a legitimate ReadPropertyMultiple request to a malicious BACnet/IP peer, the peer can reply with a malformed but structurally valid ReadPropertyMultiple-ACK that drives the client into a global-buffer-overflow read on the global receive buffer Rx_Buf. This issue has been patched in versions 1.4.5, 1.5.1, and 1.6.0.5hCVE-2026-62972——
———BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to versions 1.4.5, 1.5.1, and 1.6.0, lighting_command_decode in src/bacnet/lighting.c decodes its first field with the bounded apdu_size - apdu_len, but every nested decode in the operation switch is called with the original full apdu_size while the read pointer has been advanced to &apdu[apdu_len]. The leaf decoders bound their reads against the size they are told, so they read up to apdu_len bytes past the end of the caller's buffer, resulting in an out-of-bounds read. This issue has been patched in versions 1.4.5, 1.5.1, and 1.6.0.5h