π¨ CVE-2026-93561
Memcache binary codec signed/unsigned type mismatch causes frame desynchronization and response smuggling
π@cveNotify
Memcache binary codec signed/unsigned type mismatch causes frame desynchronization and response smuggling
π@cveNotify
π¨ CVE-2026-93572
## Summary
`RedisArrayAggregator` recently added `maxElements` and `maxNestedArrayDepth` limits to fix public Redis resource-exhaustion advisories. The limits are independent, but the allocator remains eager: every positive nested RESP array header creates `new ArrayList<RedisMessage>(length)` before any child element exists.
With the default constructor, an attacker can send nested array headers with length `1,000,000` until the default nesting limit of `1024` is reached. This can reserve up to `1,024,000,000` child slots from roughly 12 KB of RESP input. This is backing capacity, not logical list size: `ArrayList(int)` constructs an empty list with the specified initial capacity.
## Technical Details
Current `decodeRedisArrayHeader(...)` checks the two limits independently:
```java
if (header.length() > maxElements) {
throw new CodecException("this codec doesn't support longer length than " + maxElements);
}
if (depths.size() >= maxNestedArrayDepth) {
releaseAndClearDepths();
throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth);
}
depths.push(new AggregateState((int) header.length()));
```
`AggregateState` i
π@cveNotify
## Summary
`RedisArrayAggregator` recently added `maxElements` and `maxNestedArrayDepth` limits to fix public Redis resource-exhaustion advisories. The limits are independent, but the allocator remains eager: every positive nested RESP array header creates `new ArrayList<RedisMessage>(length)` before any child element exists.
With the default constructor, an attacker can send nested array headers with length `1,000,000` until the default nesting limit of `1024` is reached. This can reserve up to `1,024,000,000` child slots from roughly 12 KB of RESP input. This is backing capacity, not logical list size: `ArrayList(int)` constructs an empty list with the specified initial capacity.
## Technical Details
Current `decodeRedisArrayHeader(...)` checks the two limits independently:
```java
if (header.length() > maxElements) {
throw new CodecException("this codec doesn't support longer length than " + maxElements);
}
if (depths.size() >= maxNestedArrayDepth) {
releaseAndClearDepths();
throw new CodecException("max nested array depth exceeded: " + maxNestedArrayDepth);
}
depths.push(new AggregateState((int) header.length()));
```
`AggregateState` i
π@cveNotify
Redhat
CVE-2026-93572 - Red Hat Customer Portal
CVE Details App
π¨ CVE-2026-93578
Missing Extended Key Usage (EKU) check in OCSP Client allows certificate revocation bypass
π@cveNotify
Missing Extended Key Usage (EKU) check in OCSP Client allows certificate revocation bypass
π@cveNotify
π¨ CVE-2026-28197
An authenticated, low-privileged user with access to the NetBackup Flex
OS management shell could supply a specially crafted input to a
privileged administrative command, causing it to execute arbitrary code
with root-level permissions. Successful exploitation grants the attacker
unrestricted control over the Flex appliance host and all hosted
containers, fully compromising confidentiality, integrity, and
availability.
π@cveNotify
An authenticated, low-privileged user with access to the NetBackup Flex
OS management shell could supply a specially crafted input to a
privileged administrative command, causing it to execute arbitrary code
with root-level permissions. Successful exploitation grants the attacker
unrestricted control over the Flex appliance host and all hosted
containers, fully compromising confidentiality, integrity, and
availability.
π@cveNotify
GitHub
SecAdvisory/COH-2026-0001.md at master Β· cohesity/SecAdvisory
Cohesity Security Advisory information. . Contribute to cohesity/SecAdvisory development by creating an account on GitHub.
π¨ CVE-2026-28198
An authenticated, low-privileged user with access to the NetBackup Flex
OS management shell could bypass the cryptographic signature
verification step of a privileged support command by supplying a
specially formed access credential. Successful exploitation grants the
attacker an unrestricted root shell with full control over the Flex
appliance host and all hosted containers, completely compromising
confidentiality, integrity, and availability.
π@cveNotify
An authenticated, low-privileged user with access to the NetBackup Flex
OS management shell could bypass the cryptographic signature
verification step of a privileged support command by supplying a
specially formed access credential. Successful exploitation grants the
attacker an unrestricted root shell with full control over the Flex
appliance host and all hosted containers, completely compromising
confidentiality, integrity, and availability.
π@cveNotify
GitHub
SecAdvisory/COH-2026-0001.md at master Β· cohesity/SecAdvisory
Cohesity Security Advisory information. . Contribute to cohesity/SecAdvisory development by creating an account on GitHub.
π¨ CVE-2026-93488
A flaw was found in Netty. SpdySessionHandler accepts an unlimited number of concurrent remote-initiated streams because localConcurrentStreams defaults to Integer.MAX_VALUE and the handler provides no API to change it. A remote peer can open a SPDY connection and send a large number of SYN_STREAM frames with FLAG_FIN=0, causing unbounded heap and direct memory allocation that can lead to JVM OutOfMemoryError and a denial of service.
π@cveNotify
A flaw was found in Netty. SpdySessionHandler accepts an unlimited number of concurrent remote-initiated streams because localConcurrentStreams defaults to Integer.MAX_VALUE and the handler provides no API to change it. A remote peer can open a SPDY connection and send a large number of SYN_STREAM frames with FLAG_FIN=0, causing unbounded heap and direct memory allocation that can lead to JVM OutOfMemoryError and a denial of service.
π@cveNotify
Redhat
CVE-2026-93488 - Red Hat Customer Portal
CVE Details App
π¨ CVE-2026-93492
A flaw was found in Netty's HTTP/2 HpackEncoder. A remote attacker can exploit this by sending HTTP/2 SETTINGS frames with a very large MAX_HEADER_TABLE_SIZE. This causes the HpackEncoder to store an excessive number of unique headers, leading to increased CPU usage and memory consumption, ultimately resulting in a Denial of Service (DoS).
π@cveNotify
A flaw was found in Netty's HTTP/2 HpackEncoder. A remote attacker can exploit this by sending HTTP/2 SETTINGS frames with a very large MAX_HEADER_TABLE_SIZE. This causes the HpackEncoder to store an excessive number of unique headers, leading to increased CPU usage and memory consumption, ultimately resulting in a Denial of Service (DoS).
π@cveNotify
π¨ CVE-2023-5778
Improper handling of length parameter inconsistency vulnerability in ABB Freelance Controller DCP, ABB Freelance Controller AC700, ABB Freelance Controller AC800, and ABB Freelance Controller AC900.
This issue affects Freelance Controller DCP: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC700: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC800: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC900: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1.
π@cveNotify
Improper handling of length parameter inconsistency vulnerability in ABB Freelance Controller DCP, ABB Freelance Controller AC700, ABB Freelance Controller AC800, and ABB Freelance Controller AC900.
This issue affects Freelance Controller DCP: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC700: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC800: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1; Freelance Controller AC900: through 2013, 2013 SP1, 2016, 2016 SP1, 2019, and 2019 SP1.
π@cveNotify
π¨ CVE-2026-88622
NUUO Network Video Recorder 2.0.0 is vulnerable to Command Injection in handle_import_privilege.php.
π@cveNotify
NUUO Network Video Recorder 2.0.0 is vulnerable to Command Injection in handle_import_privilege.php.
π@cveNotify
NUUO Inc.
Trusted Video Management | NUUO Inc.
π¨ CVE-2026-93589
ImageMagick before 7.1.2-31 and 6.9.13-56 contains a division-by-zero flaw in the FLIF encoder. An incorrect value for ticks per second in the image being encoded causes a divide-by-zero and crashes the encoder, resulting in a denial of service. The issue is fixed in 7.1.2-31 and 6.9.13-56.
π@cveNotify
ImageMagick before 7.1.2-31 and 6.9.13-56 contains a division-by-zero flaw in the FLIF encoder. An incorrect value for ticks per second in the image being encoded causes a divide-by-zero and crashes the encoder, resulting in a denial of service. The issue is fixed in 7.1.2-31 and 6.9.13-56.
π@cveNotify
GitHub
Division by Zero in FLIF encoder
An incorrect value for ticks per second will result in a crash in the FLIF encoder
π¨ CVE-2026-93594
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 enforces its per-type/per-record access-control rules only in LocalBucket, keyed on file id. Query-execution paths that reach record data through LSM index files or the TimeSeries engine never invoke that permission check, so an authenticated user who is denied readRecord/deleteRecord on a type can still, with a single ordinary SQL statement, read the type's indexed key values and record IDs (e.g. SELECT key, rid FROM INDEX:Type[field]), read MAX/MIN values via the index shortcut, read and count TimeSeries samples, learn the type's record count, and delete index entries (DELETE FROM INDEX:Type[field]), which desynchronizes the index from the data and can defeat unique constraints. Index and type names needed for exploitation are discoverable because SELECT FROM schema:indexes is unfiltered. The issue affects both embedded and server deployments and all transports (HTTP, Bolt, Postgres, Gremlin) once a principal is bound. Fixed in 26.9.1.
π@cveNotify
ArcadeDB (Maven artifact com.arcadedb:arcadedb-engine) through 26.8.1 enforces its per-type/per-record access-control rules only in LocalBucket, keyed on file id. Query-execution paths that reach record data through LSM index files or the TimeSeries engine never invoke that permission check, so an authenticated user who is denied readRecord/deleteRecord on a type can still, with a single ordinary SQL statement, read the type's indexed key values and record IDs (e.g. SELECT key, rid FROM INDEX:Type[field]), read MAX/MIN values via the index shortcut, read and count TimeSeries samples, learn the type's record count, and delete index entries (DELETE FROM INDEX:Type[field]), which desynchronizes the index from the data and can defeat unique constraints. Index and type names needed for exploitation are discoverable because SELECT FROM schema:indexes is unfiltered. The issue affects both embedded and server deployments and all transports (HTTP, Bolt, Postgres, Gremlin) once a principal is bound. Fixed in 26.9.1.
π@cveNotify
GitHub
Per-type ACL bypass: index-target and TimeSeries reads/writes/counts reach records without the LocalBucket permission check
## Summary
ArcadeDB enforces its per-type / per-record access-control rules at exactly one place: `LocalBucket`, keyed on the file id. Every execution path that reaches record data through the **L...
ArcadeDB enforces its per-type / per-record access-control rules at exactly one place: `LocalBucket`, keyed on the file id. Every execution path that reaches record data through the **L...
π¨ CVE-2026-93599
rustls-webpki through 0.103.12 (and 0.104.0-alpha releases before 0.104.0-alpha.7) contains a reachable panic in bit_string_flags() in src/der.rs. The input guard fails to reject a named-bit BIT STRING whose content is exactly [0x00] (zero padding bits and no data bytes), so raw_bits.len() - 1 underflows on the empty slice and the subsequent index operation panics (subtract-with-overflow in debug, index-out-of-bounds in release). The condition is reachable through the public API BorrowedCertRevocationList::from_der() when a CRL contains an issuingDistributionPoint extension with such an onlySomeReasons value. Exploitation requires an application that explicitly opts in to CRL revocation checking by passing RevocationOptions to verify_for_usage() and that parses CRL bytes obtained from a source the attacker can influence; the default rustls configuration, which does not use RevocationOptions, is unaffected. A crafted CRL causes a denial of service via the panic. Fixed in 0.103.13 and 0.104.0-alpha.7.
π@cveNotify
rustls-webpki through 0.103.12 (and 0.104.0-alpha releases before 0.104.0-alpha.7) contains a reachable panic in bit_string_flags() in src/der.rs. The input guard fails to reject a named-bit BIT STRING whose content is exactly [0x00] (zero padding bits and no data bytes), so raw_bits.len() - 1 underflows on the empty slice and the subsequent index operation panics (subtract-with-overflow in debug, index-out-of-bounds in release). The condition is reachable through the public API BorrowedCertRevocationList::from_der() when a CRL contains an issuingDistributionPoint extension with such an onlySomeReasons value. Exploitation requires an application that explicitly opts in to CRL revocation checking by passing RevocationOptions to verify_for_usage() and that parses CRL bytes obtained from a source the attacker can influence; the default rustls configuration, which does not use RevocationOptions, is unaffected. A crafted CRL causes a denial of service via the panic. Fixed in 0.103.13 and 0.104.0-alpha.7.
π@cveNotify
GitHub
Panic in `BorrowedCertRevocationList::from_der` via empty `BIT STRING` in `IssuingDistributionPoint`
### Summary
`bit_string_flags()` in `src/der.rs` panics with an index-out-of-bounds when given a BIT STRING whose content is exactly `[0x00]` (one byte: zero padding bits, zero data bytes). This...
`bit_string_flags()` in `src/der.rs` panics with an index-out-of-bounds when given a BIT STRING whose content is exactly `[0x00]` (one byte: zero padding bits, zero data bytes). This...
π¨ CVE-2024-56344
IBM Cognos Analytics 12.0.4 through 12.0.4 FP2, and 12.1.0 through 12.1.3 FP1 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques.
π@cveNotify
IBM Cognos Analytics 12.0.4 through 12.0.4 FP2, and 12.1.0 through 12.1.3 FP1 could allow a remote attacker to obtain sensitive information, caused by the failure to properly enable HTTP Strict Transport Security. An attacker could exploit this vulnerability to obtain sensitive information using man in the middle techniques.
π@cveNotify
Ibm
Security Bulletin: IBM Cognos Analytics 12.0.4 and 12.1.3 versions are affected by security vulnerabilities
There are vulnerabilities identified in Cognos Analytics application and its open source components. These vulnerabilties has been resolved and the remediation versions is provided below.
π¨ CVE-2025-13882
IBM Sterling Partner Engagement Manager Essentials Edition 6.3.0.0 through 6.3.0.2, and 6.2.4.0 through 6.2.4.4 and IBM Sterling Partner Engagement Manager Standard Edition 6.2.4.0 through 6.2.4.4 could allow an unauthenticated user to cause a denial of service in the email service due to improper control of interaction frequency.
π@cveNotify
IBM Sterling Partner Engagement Manager Essentials Edition 6.3.0.0 through 6.3.0.2, and 6.2.4.0 through 6.2.4.4 and IBM Sterling Partner Engagement Manager Standard Edition 6.2.4.0 through 6.2.4.4 could allow an unauthenticated user to cause a denial of service in the email service due to improper control of interaction frequency.
π@cveNotify
Ibm
Security Bulletin: Multiple Security Vulnerabilities in IBM Sterling Partner Engagement Manager.
Multiple vulnerabilities were addressed in IBM Sterling Partner Engagement Manager.
π¨ CVE-2025-1350
IBM Controller 11.0.0 through 11.0.1 FP7, and 11.1.0 through 11.1.3 FP1 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.
π@cveNotify
IBM Controller 11.0.0 through 11.0.1 FP7, and 11.1.0 through 11.1.3 FP1 could allow a remote attacker to obtain sensitive information when a detailed technical error message is returned in the browser. This information could be used in further attacks against the system.
π@cveNotify
Ibm
Security Bulletin: Multiple vulnerabilities in IBM Controller
Multiple vulnerabilities were addressed in IBM Controller version 11.2.0
π¨ CVE-2026-10832
A flaw was found in the DERDecoder class within wildfly-elytron-asn1. A remote attacker can exploit this resource exhaustion vulnerability by sending a specially crafted DER (Distinguished Encoding Rules) payload. The decoder attempts to allocate excessive memory based on an inflated length value without proper validation, leading to Java Virtual Machine (JVM) memory exhaustion. This results in a remote Denial of Service (DoS) for services that process untrusted DER/ASN.1 input, including SASL (Simple Authentication and Security Layer) authentication mechanisms and X.500 certificate principal parsing paths.
π@cveNotify
A flaw was found in the DERDecoder class within wildfly-elytron-asn1. A remote attacker can exploit this resource exhaustion vulnerability by sending a specially crafted DER (Distinguished Encoding Rules) payload. The decoder attempts to allocate excessive memory based on an inflated length value without proper validation, leading to Java Virtual Machine (JVM) memory exhaustion. This results in a remote Denial of Service (DoS) for services that process untrusted DER/ASN.1 input, including SASL (Simple Authentication and Security Layer) authentication mechanisms and X.500 certificate principal parsing paths.
π@cveNotify
Redhat
CVE-2026-10832 - Red Hat Customer Portal
CVE Details App
π¨ CVE-2026-16512
gptp_handle_msg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenced the gPTP header returned by GPTP_HDR() and switched on hdr->message_type without first checking that the received frame carries at least sizeof(struct gptp_hdr) (34) bytes of payload. The header accessor gptp_get_hdr() deliberately never fails for a short buffer β it returns pkt->frags->data and leaves validation to its callers β so a truncated frame produced a header pointer covering memory beyond the received data. The per-message-type checks that follow do not compensate: GPTP_VALID_LEN() reduces to len > 60 once the Ethernet header has been pulled, which is false for every fixed-size gPTP message, so GPTP_CHECK_LEN() never rejects a truncated SYNC, FOLLOWUP, PDELAY_RESP or SIGNALING message.
The defect is reached by an unauthenticated peer on the same link sending an Ethernet frame with ethertype 0x88F7 to the PTP multicast address on an interface configured as a gPTP port, with CONFIG_NET_GPTP enabled. Because conformant Ethernet pads frames to 60 bytes, a payload shorter than 34 bytes generally requires a link that can deliver sub-minimum frames β for example the native_sim TAP driver (drivers/ethernet/eth_native_tap.c), which forwards whatever length the host device supplies, or a MAC configured to accept undersized frames.
The short packet is retained (net_pkt_ref() into rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr or rcvd_announce_ptr) and later parsed by the media-dependent and media-independent state machines in subsys/net/l2/ethernet/gptp/gptp_md.c and subsys/net/l2/ethernet/gptp/gptp_mi.c, which read tens of further bytes and copy some of them (the announce priority vector, hdr->port_id) into state that is subsequently transmitted. Under the default fixed-size buffer allocator (CONFIG_NET_BUF_FIXED_DATA_SIZE, 128-byte fragments) the accesses stay inside the allocated fragment and disclose stale recycled buffer contents; under the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator, where fragments are heap-allocated at the exact frame length, they are genuine out-of-bounds reads. There is no write and no availability impact.
π@cveNotify
gptp_handle_msg() in subsys/net/l2/ethernet/gptp/gptp.c dereferenced the gPTP header returned by GPTP_HDR() and switched on hdr->message_type without first checking that the received frame carries at least sizeof(struct gptp_hdr) (34) bytes of payload. The header accessor gptp_get_hdr() deliberately never fails for a short buffer β it returns pkt->frags->data and leaves validation to its callers β so a truncated frame produced a header pointer covering memory beyond the received data. The per-message-type checks that follow do not compensate: GPTP_VALID_LEN() reduces to len > 60 once the Ethernet header has been pulled, which is false for every fixed-size gPTP message, so GPTP_CHECK_LEN() never rejects a truncated SYNC, FOLLOWUP, PDELAY_RESP or SIGNALING message.
The defect is reached by an unauthenticated peer on the same link sending an Ethernet frame with ethertype 0x88F7 to the PTP multicast address on an interface configured as a gPTP port, with CONFIG_NET_GPTP enabled. Because conformant Ethernet pads frames to 60 bytes, a payload shorter than 34 bytes generally requires a link that can deliver sub-minimum frames β for example the native_sim TAP driver (drivers/ethernet/eth_native_tap.c), which forwards whatever length the host device supplies, or a MAC configured to accept undersized frames.
The short packet is retained (net_pkt_ref() into rcvd_sync_ptr, rcvd_follow_up_ptr, rcvd_pdelay_resp_ptr or rcvd_announce_ptr) and later parsed by the media-dependent and media-independent state machines in subsys/net/l2/ethernet/gptp/gptp_md.c and subsys/net/l2/ethernet/gptp/gptp_mi.c, which read tens of further bytes and copy some of them (the announce priority vector, hdr->port_id) into state that is subsequently transmitted. Under the default fixed-size buffer allocator (CONFIG_NET_BUF_FIXED_DATA_SIZE, 128-byte fragments) the accesses stay inside the allocated fragment and disclose stale recycled buffer contents; under the experimental CONFIG_NET_BUF_VARIABLE_DATA_SIZE allocator, where fragments are heap-allocated at the exact frame length, they are genuine out-of-bounds reads. There is no write and no availability impact.
π@cveNotify
GitHub
net: gptp: check minimum packet length before header dereference Β· zephyrproject-rtos/zephyr@84eaf32
gptp_handle_msg() dereferenced hdr = GPTP_HDR(pkt) and read
hdr->message_type before checking that the packet is at least
sizeof(struct gptp_hdr) bytes, allowing a short Ethernet frame to
tr...
hdr->message_type before checking that the packet is at least
sizeof(struct gptp_hdr) bytes, allowing a short Ethernet frame to
tr...
π¨ CVE-2026-16514
gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.
The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes β so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() β gptp_handle_msg() β gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each β about 2 KB β beyond the end of the network buffer.
The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.
The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.
π@cveNotify
gptp_mi_qualify_announce() in subsys/net/l2/ethernet/gptp/gptp_mi.c walks the Path Trace TLV of a received IEEE 802.1AS Announce message, comparing each clock identity against the local one. The loop bound was taken solely from the attacker-controlled wire field announce->steps_removed (accepted up to 254), never from announce->tlv.len, which is the field that states how many identities the TLV actually carries. Because path_sequence is the flexible member of the wire TLV (struct gptp_path_trace_tlv) and GPTP_ANNOUNCE() yields a raw pointer into the received packet buffer, the memcmp() inside the loop can address memory well past the end of the received frame.
The stack's only length validation, GPTP_ANNOUNCE_CHECK_LEN(), requires the received gPTP payload to be exactly 68 + tlv.len bytes β so it does not constrain the loop, it guarantees the data is absent. An unauthenticated attacker on the same Ethernet segment can send a single Announce frame declaring tlv.len = 0 with steps_removed = 254; the frame passes the length check and reception path (net_gptp_recv() β gptp_handle_msg() β gptp_mi_qualify_announce()), which performs no authentication, and the loop then reads 255 entries of 8 bytes each β about 2 KB β beyond the end of the network buffer.
The impact is an out-of-bounds read. The bytes read are only used as a memcmp() operand and are never returned to the attacker, so there is no meaningful information disclosure; the practical risk is that the overread crosses a network buffer pool boundary into unmapped or MPU-protected memory and faults the networking RX thread, causing a denial of service. Exposure is limited to builds that enable the opt-in, experimental CONFIG_NET_GPTP (TSN/AVB deployments) and to attackers with layer-2 adjacency, since gPTP frames are sent to a link-local multicast address and are not routed.
The fix computes the true entry count as tlv.len / GPTP_CLOCK_ID_LEN and rejects the announce when steps_removed + 1 exceeds it, so the loop can no longer run past the data the packet-length check proved present.
π@cveNotify
GitHub
net: gptp: bound path-sequence loop by TLV length Β· zephyrproject-rtos/zephyr@a2c882d
gptp_mi_qualify_announce() iterated announce->tlv.path_sequence up to
(steps_removed + 1) entries β with steps_removed potentially up to 254
β without validating against the actual TLV wire ...
(steps_removed + 1) entries β with steps_removed potentially up to 254
β without validating against the actual TLV wire ...
π¨ CVE-2026-16515
net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none.
An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim β a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required.
The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it.
The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.
π@cveNotify
net_icmpv6_send_error() in subsys/net/ip/icmpv6.c implemented only one of the three RFC 4443 section 2.4 suppression rules (do not answer an ICMPv6 error with an ICMPv6 error). It did not check whether the triggering packet's source address identifies a single node (rule e.6) or whether the packet was sent to a multicast destination (rule e.3, whose only exceptions are Packet Too Big and Parameter Problem Code 2). Of the five call sites, only the port-unreachable path in subsys/net/ip/connection.c carried an equivalent guard of its own; the extension-header, unknown-next-header and fragmentation paths in subsys/net/ip/ipv6.c and subsys/net/ip/ipv6_fragment.c had none.
An unauthenticated attacker with access to the same link can exploit this in two ways. Sending a single IPv6 packet to the link-local all-nodes group ff02::1 carrying an unrecognized next-header value, with the source address spoofed to a chosen victim, causes every Zephyr node on the link to emit an ICMPv6 Parameter Problem message to that victim β a reflector with an amplification factor equal to the number of nodes. Alternatively, sending a unicast packet whose source address is a multicast address causes the node to transmit its ICMPv6 error to that multicast address, turning one unicast packet into a link-flooded multicast frame. Packets addressed to ff02::1 are accepted unconditionally by ipv6_input(), and no check rejects a multicast source address, so no special configuration is required.
The impact is degraded availability of the shared link and of the reflection victim, together with the ability for the attacker to hide its own address behind the responding nodes. The effect is amplified on constrained mesh links such as 802.15.4/Thread, where link-local multicast is flooded hop by hop. There is no memory-safety consequence: the error packet itself is well formed, it is simply emitted in cases where the protocol forbids it.
The fix adds both suppression checks at the single choke point in net_icmpv6_send_error(), before any reply packet is allocated, preserving the RFC-mandated exceptions for NET_ICMPV6_PACKET_TOO_BIG and Parameter Problem Code 2. Note that the IPv4 counterpart net_icmpv4_send_error() in subsys/net/ip/icmpv4.c still checks only for a broadcast destination and retains an equivalent gap for multicast destinations and non-unique sources.
π@cveNotify
GitHub
net: ip: icmpv6: drop errors for multicast/unspecified addresses Β· zephyrproject-rtos/zephyr@ba4247b
RFC 4443 section 2.4 says an ICMPv6 error must not be sent if the
triggering packet's source doesn't identify a single node (e.6), or
if the packet was sent to a multicast destinati...
triggering packet's source doesn't identify a single node (e.6), or
if the packet was sent to a multicast destinati...
π¨ CVE-2026-25684
A file type attribution issue in Zscaler Internet Access File Type Control evaluation rules may allow improper evaluation of File Type Control policies in rare circumstances.
π@cveNotify
A file type attribution issue in Zscaler Internet Access File Type Control evaluation rules may allow improper evaluation of File Type Control policies in rare circumstances.
π@cveNotify
π¨ CVE-2026-77927
ClipBucket v5 before 5.5.3-#182 contains a blind SQL injection vulnerability that allows authenticated users to extract arbitrary data from the database by submitting the check_photo parameter as an array to bypass the clean_requests() sanitization function in ClipBucket.class.php. Attackers can pass unsanitized array elements through the bulk deletion handler in manage_photos.php to photo_exists() in photos.class.php, where non-numeric values are interpolated directly into a SQL query, enabling time-based blind SQL injection to retrieve credential hashes and other sensitive data.
π@cveNotify
ClipBucket v5 before 5.5.3-#182 contains a blind SQL injection vulnerability that allows authenticated users to extract arbitrary data from the database by submitting the check_photo parameter as an array to bypass the clean_requests() sanitization function in ClipBucket.class.php. Attackers can pass unsanitized array elements through the bulk deletion handler in manage_photos.php to photo_exists() in photos.class.php, where non-numeric values are interpolated directly into a SQL query, enabling time-based blind SQL injection to retrieve credential hashes and other sensitive data.
π@cveNotify
GitHub
Miscellaneous : Fix possible SQL injection (Thanks @QwesiRED !), Clea⦠· MacWarrior/clipbucket-v5@136dd2e
β¦nup code
---------
Co-authored-by: MacWarrior <macwarrior94@gmail.com>
---------
Co-authored-by: MacWarrior <macwarrior94@gmail.com>