Total
3927 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64694 | 1 Apple | 1 Macos | 2026-07-28 | 9.8 Critical |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-43764 | 1 Apple | 1 Macos | 2026-07-28 | 9.8 Critical |
| An integer overflow was addressed with improved input validation. This issue is fixed in macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6. An app may be able to cause unexpected system termination. | ||||
| CVE-2026-28973 | 1 Apple | 3 Ios And Ipados, Macos, Watchos | 2026-07-28 | 8.6 High |
| An integer overflow was addressed with improved input validation. This issue is fixed in iOS 26.6 and iPadOS 26.6, macOS Sequoia 15.7.8, macOS Sonoma 14.8.8, macOS Tahoe 26.6, watchOS 26.6. A malicious app may be able to break out of its sandbox. | ||||
| CVE-2026-63091 | 1 Proftpd | 1 Proftpd | 2026-07-28 | 6.5 Medium |
| ProFTPD before 1.3.9c and 1.3.10rc3 contains a signed integer overflow vulnerability in the mod_sftp module's SCP size-record parser that allows authenticated low-privilege attackers to bypass ASLR by sending a crafted file size value of UINT64_MAX, which results in a negative off_t value. Attackers can exploit the subsequent conversion to uint32_t, causing an approximately 4 GB requested read length and forcing the server to read beyond the end of the SSH channel data and write overread process memory into the uploaded file. In tested configurations, the disclosed data contains libc, libcrypto, and PIE pointers sufficient to derive their randomized base addresses, thereby bypassing ASLR and enabling reliable exploitation of memory corruption vulnerabilities in the same process. | ||||
| CVE-2026-47714 | 1 Struktur | 1 Libheif | 2026-07-27 | 6.1 Medium |
| libheif is a HEIF and AVIF file format decoder and encoder. In versions 1.21.2 and prior, the inline mask parsing code in `libheif/region.cc` contains an integer overflow. Both `width` and `height` are `unsigned int` (32-bit) values parsed from the HEIF file. Their product can exceed `UINT32_MAX`, wrapping to a small value before the division by 8. This causes an undersized buffer allocation, leading to out-of-bounds memory access when the mask data is later interpreted as a `width x height` bitmap. Version 1.22.0 patches the issue. | ||||
| CVE-2026-47251 | 1 Struktur | 1 Libheif | 2026-07-27 | N/A |
| libheif is a HEIF and AVIF file format decoder and encoder. The fix for CVE-2026-3949 (commit `b97c8b5`, PR #1712) introduced an integer overflow in the very security check it added. The check itself can be bypassed, allowing a crafted HEIF file with a VVC track to trigger the same out-of-bounds heap read that CVE-2026-3949 was meant to prevent. This is a separate, currently-unpatched vulnerability. Issue #1712 was closed as fixed without testing the edge case where `size` is near `UINT32_MAX`. Version 1.22.0 patches the issue. | ||||
| CVE-2026-16517 | 2 Libarchive, Redhat | 6 Libarchive, Enterprise Linux, Hardened Images and 3 more | 2026-07-27 | 2.9 Low |
| A signed integer overflow vulnerability was found in libarchive's ZIP writer. In the archive_write_zip_header function in archive_write_set_format_zip.c, when ZIP encryption is enabled and the entry file size is close to INT64_MAX, the addition of the encryption overhead to the entry size overflows int64_t, resulting in undefined behavior. This could lead to incorrect Zip64 extension decisions or potential memory corruption. | ||||
| CVE-2026-16395 | 1 Mozilla | 1 Firefox | 2026-07-27 | 9.8 Critical |
| Integer overflow in the Audio/Video component. This vulnerability was fixed in Firefox 153 and Thunderbird 153. | ||||
| CVE-2026-16408 | 1 Mozilla | 1 Firefox | 2026-07-27 | 9.8 Critical |
| Integer overflow in the Audio/Video: Playback component. This vulnerability was fixed in Firefox 153 and Thunderbird 153. | ||||
| CVE-2026-16280 | 1 Imaginationtech | 1 Graphics Ddk | 2026-07-27 | 9.8 Critical |
| An integer overflow when calculating physical offsets for sparse PMRs may result in 32-bit truncation of address computations for PMRs larger than 4 GB. This can lead to incorrect GPU MMU mappings and may allow a non-privileged user to trigger access to unintended physical memory, resulting in memory corruption or information disclosure. | ||||
| CVE-2026-55969 | 1 Apache | 1 Thrift | 2026-07-27 | 7.5 High |
| Integer Overflow or Wraparound vulnerability in Apache Thrift C++, c_glib, Go, netstd, Delphi and Haxe bindings. This issue affects Apache Thrift: before 0.24.0. Users are recommended to upgrade to version 0.24.0, which fixes the issue. | ||||
| CVE-2026-57433 | 1 Haarg | 1 Storable | 2026-07-27 | 9.8 Critical |
| Storable versions before 3.41 for Perl have a signed integer overflow when deserializing a crafted SX_HOOK record. retrieve_hook_common reads a signed 32-bit item count from an SX_HOOK record and calls av_extend with that count plus one. A count of I32_MAX wraps the addition to a negative value. A crafted blob passed to thaw or retrieve triggers the overflow; av_extend receives the negative count and dies with a panic, terminating the deserialization. | ||||
| CVE-2024-14040 | 1 Linux | 1 Linux Kernel | 2026-07-27 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: nexthop: Increase weight to u16 In CLOS networks, as link failures occur at various points in the network, ECMP weights of the involved nodes are adjusted to compensate. With high fan-out of the involved nodes, and overall high number of nodes, a (non-)ECMP weight ratio that we would like to configure does not fit into 8 bits. Instead of, say, 255:254, we might like to configure something like 1000:999. For these deployments, the 8-bit weight may not be enough. To that end, in this patch increase the next hop weight from u8 to u16. Increasing the width of an integral type can be tricky, because while the code still compiles, the types may not check out anymore, and numerical errors come up. To prevent this, the conversion was done in two steps. First the type was changed from u8 to a single-member structure, which invalidated all uses of the field. This allowed going through them one by one and audit for type correctness. Then the structure was replaced with a vanilla u16 again. This should ensure that no place was missed. The UAPI for configuring nexthop group members is that an attribute NHA_GROUP carries an array of struct nexthop_grp entries: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 resvd1; __u16 resvd2; }; The field resvd1 is currently validated and required to be zero. We can lift this requirement and carry high-order bits of the weight in the reserved field: struct nexthop_grp { __u32 id; /* nexthop id - must exist */ __u8 weight; /* weight of this nexthop */ __u8 weight_high; __u16 resvd2; }; Keeping the fields split this way was chosen in case an existing userspace makes assumptions about the width of the weight field, and to sidestep any endianness issues. The weight field is currently encoded as the weight value minus one, because weight of 0 is invalid. This same trick is impossible for the new weight_high field, because zero must mean actual zero. With this in place: - Old userspace is guaranteed to carry weight_high of 0, therefore configuring 8-bit weights as appropriate. When dumping nexthops with 16-bit weight, it would only show the lower 8 bits. But configuring such nexthops implies existence of userspace aware of the extension in the first place. - New userspace talking to an old kernel will work as long as it only attempts to configure 8-bit weights, where the high-order bits are zero. Old kernel will bounce attempts at configuring >8-bit weights. Renaming reserved fields as they are allocated for some purpose is commonly done in Linux. Whoever touches a reserved field is doing so at their own risk. nexthop_grp::resvd1 in particular is currently used by at least strace, however they carry an own copy of UAPI headers, and the conversion should be trivial. A helper is provided for decoding the weight out of the two fields. Forcing a conversion seems preferable to bending backwards and introducing anonymous unions or whatever. | ||||
| CVE-2026-16554 | 1 Davegamble | 1 Cjson | 2026-07-27 | 6.8 Medium |
| cJSON library is vulnerable to an integer overflow in the print_string_ptr() function in cJSON.c on 32-bit platforms. The escape_characters counter, a 32-bit size_t, can wrap around when processing strings containing approximately 858,993,460 or more control characters, causing the output buffer to be allocated based on an underestimated length. When cJSON_PrintBuffered() is used with a pre-allocated buffer, the subsequent write loop overflows the heap allocation. An attacker supplying a crafted JSON string to an application using cJSON on a 32-bit platform can cause a heap buffer overflow, potentially leading to remote code execution, information disclosure, or denial of service. Because project creator contact attempts were unsuccessful, the vulnerability has only been confirmed in version 1.7.19 but may also affect other versions. | ||||
| CVE-2026-63889 | 1 Linux | 1 Linux Kernel | 2026-07-26 | 8.1 High |
| In the Linux kernel, the following vulnerability has been resolved: scsi: scsi_transport_fc: Widen FPIN pname walker counter to u32 An adjacent Fibre Channel fabric actor that can deliver an FPIN ELS frame to an lpfc or qla2xxx Linux initiator can trigger a non-return in the generic FC transport. This is not a local userspace or IP network path; the attacker must be able to inject fabric traffic, for example as a compromised switch or fabric controller, or as a same-zone N_Port on a fabric that permits source spoofing. The Link-Integrity and Peer-Congestion FPIN walkers used a u8 loop counter against the 32-bit on-wire pname_count field, and did not bound pname_count by the descriptor body already validated by the TLV walker. A pname_count of 256 therefore wraps the counter and keeps the loop condition true indefinitely. Factor the shared pname_list[] walk into one helper, widen the counter to u32, and clamp pname_count against the entries that fit in the descriptor body before iterating. | ||||
| CVE-2026-64256 | 1 Linux | 1 Linux Kernel | 2026-07-26 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: xfs: don't wrap around quota ids in dqiterate LOLLM noticed that q_id is an unsigned 32-bit variable. If it happens to be set to XFS_DQ_ID_MAX due to a filesystem that actually has a dquot for ID_MAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64. | ||||
| CVE-2026-63984 | 1 Linux | 1 Linux Kernel | 2026-07-25 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: ipv6: rpl: fix hdrlen overflow in ipv6_rpl_srh_decompress() ipv6_rpl_srh_decompress() computes: outhdr->hdrlen = (((n + 1) * sizeof(struct in6_addr)) >> 3); hdrlen is __u8. For n >= 127 the result exceeds 255 and silently truncates. With n=127 (cmpri=15, cmpre=15, pad=0, hdrlen=16): (128 * 16) >> 3 = 256, truncated to 0 as __u8 The caller in ipv6_rpl_srh_rcv() then places the compressed header at buf + ((ohdr->hdrlen + 1) << 3). With hdrlen=0 this is buf + 8, but the decompressed region occupies buf[0..2055] (8-byte header plus 128 full addresses). The compressed header overlaps the decompressed data, and ipv6_rpl_srh_compress() writes into this overlap, corrupting the routing header of the forwarded packet. The existing guard at exthdrs.c:546 checks (n + 1) > 255, which prevents n+1 from overflowing unsigned char (the segments_left field), but does not prevent the computed hdrlen from overflowing __u8. n=127 passes because 128 <= 255, yet hdrlen=256 does not fit. Tighten the bound to (n + 1) > 127. This caps n at 126, giving hdrlen = (127 * 16) >> 3 = 254, which fits in __u8. The compressed header then lands at buf + ((254 + 1) << 3) = buf + 2040, exactly past the decompressed region (buf[0..2039]). No overlap. 127 segments is well beyond any realistic RPL deployment. | ||||
| CVE-2026-52972 | 1 Linux | 1 Linux Kernel | 2026-07-24 | 7.0 High |
| In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Cap AEAD AD length to 0x80000000 In order to prevent arithmetic overflows when checking the TX buffer size, cap the associated data length to 0x80000000. | ||||
| CVE-2024-42133 | 2 Linux, Redhat | 2 Linux Kernel, Enterprise Linux | 2026-07-24 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Ignore too large handle values in BIG hci_le_big_sync_established_evt is necessary to filter out cases where the handle value is belonging to ida id range, otherwise ida will be erroneously released in hci_conn_cleanup. | ||||
| CVE-2026-15108 | 1 Google | 1 Chrome | 2026-07-24 | 4.3 Medium |
| Integer overflow in Extensions API in Google Chrome prior to 150.0.7871.115 allowed an attacker who convinced a user to install a malicious extension to perform an out of bounds memory read via a crafted Chrome Extension. (Chromium security severity: High) | ||||