Echo is a Go web framework. From 5.0.0 until 5.4.1, Echo v5's BodyDump middleware can discard a BodyLimit overflow error for an unknown-length request when BodyDump's capture limit is below the BodyLimit threshold. BodyDump drains the remaining body while ignoring read errors and replaces it with the captured prefix, so an HTTP/1.1 chunked request can be truncated and processed successfully even though the original body exceeded the configured limit. Known-length requests rejected before BodyDump runs are unaffected, and the issue does not establish a general authentication bypass or denial of service. This issue is fixed in 5.4.1.
MONAI versions before 1.6.1 have a vulnerability in the check_hash() function where the integrity verification is insufficient. Specifically, if the hash value is None, the function incorrectly returns True, and MD5 is used as the default hash algorithm. This flaw allows attackers who can perform man-in-the-middle or registry compromise attacks to substitute malicious bundles, datasets, or model archives downloaded without hashes, potentially leading to malicious file delivery and code execution.
i18next-http-backend is a backend layer for i18next that loads translation resources in Node.js, browsers, and Deno. Prior to 4.0.4, interpolateUrl inserts unencoded language and namespace values into loadPath or addPath templates without rejecting ampersand (&), equals (=), or semicolon (;) query separators. When a template places lng or ns in the query string and an attacker controls that value, the attacker can add or override parameters on browser or server-side translation requests, potentially exposing other namespaces or tenants or changing backend behavior through the application's network position and credentials. This vulnerability is the result of an incomplete fix for CVE-2026-41691. This issue is fixed in version 4.0.4.
Vue I18n is the internationalization plugin for Vue.js. From 11.1.10 until 11.4.14 and from 12.0.0-alpha.4 until 12.0.0-alpha.5, sanitizeTranslatedHtml() escapes markup and event-handler text inside an iframe srcdoc value but leaves the srcdoc attribute active. Browsers decode the character references and parse the value as a same-origin nested HTML document, allowing attacker-controlled parameters or translation content placed in srcdoc to execute script when applications enable escapeParameter and render translations as HTML through v-html. Versions 9.14.5 and 10.0.8 are also affected and are no longer supported, while i18n-t rendering is not affected. This issue is fixed in versions 11.4.14 and 12.0.0-alpha.5.
Highcharts JS is a JavaScript charting library based on SVG. From 1.0.0 until 4.2.2, Highcharts Dashboards edit mode walks editableOptions propertyPath segments without rejecting prototype-related keys. An attacker who controls editableOptions can provide a path through __proto__ or constructor, and a user's edit writes the configured value onto Object.prototype. The property then becomes visible to JavaScript throughout the page, with consequences determined by the consuming application. This issue is fixed in 4.2.2.
The OAuth2 Token Manager module for Drupal allows management of system-wide OAuth2 access and refresh tokens for integrations such as Box, Quip, and Slack. A vulnerability exists because the module does not restrict access to its OAuth2 routes, potentially allowing an anonymous visitor to connect the site's integration to an account they control. However, exploitation requires the attacker to obtain the OAuth2 state value from a prior token initialization, which mitigates the risk. The issue is fixed in version 1.2.0.
CVE-2026-105614 is a medium severity vulnerability in DALIBO PostgreSQL Anonymizer versions 1.0.0 up to but not including 3.3.0. The flaw exists in the anon.image_blur() function, which fails to validate the declared dimensions of an input image. An attacker can exploit this by submitting a small image with falsely large declared dimensions, causing excessive memory allocation. This can lead to backend memory exhaustion and out-of-memory (OOM) termination, triggering a cluster-wide crash recovery. The issue is fixed in version 3.3.0 and later.
CVE-2026-105613 is a vulnerability in DALIBO's PostgreSQL Anonymizer where range-based dummy functions do not limit the size of the range. This flaw allows an attacker to cause excessive memory allocation, potentially exhausting backend memory and triggering an out-of-memory kill if overcommit is enabled. The resulting crash leads to cluster-wide recovery. The issue is fixed in version 3.3.0 of PostgreSQL Anonymizer.
When a broker decodes a compressed record batch, the per-record decoder reads a declared body size from the decompressed stream and allocates a buffer of that size before validating it against the bytes available or any configured limit. The size is attacker-controlled, and the batch CRC does not constrain it, so a small (around 90-byte), CRC-valid compressed produce request can declare a body size of up to about 2 GiB and force the broker to attempt that allocation, raising OutOfMemoryError. The record size limit (max.message.bytes), the request size limit, and client/broker quotas bound only the compressed wire size, not the declared decompressed size.
Impact:
An authenticated principal with Write on a topic can crash broker request-handler threads (reached when a batch's codec differs from the topic's compression.type and records are re-encoded) and any consumer that fetches the record, denying service. On brokers started with -XX:+ExitOnOutOfMemoryError, a common hardening, a single crafted request terminates the broker JVM. More seriously, a crafted record is accepted at ingest and written to disk; when the log-cleaner later reads it on a compacted topic, the OutOfMemoryError (an Error, not an Exception) terminates the cleaner thread, which is not restarted. With the default of a single cleaner thread, log compaction then stops for the entire broker, including the internal __consumer_offsets and __transaction_state topics, and the condition persists across restarts until the offending record is removed. The impact is availability only; no data is disclosed or altered.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0, and set max.decompressed.message.bytes (at the broker and/or topic level) to a bounded value appropriate for your workload. Upgrading alone is not sufficient: for backward compatibility this configuration defaults to an effectively unlimited value (about 2 GiB), so a broker remains exposed until the limit is set. Choose a value at or slightly above the largest legitimate decompressed record your applications produce, and comfortably below the broker heap divided by the number of request-handler and cleaner threads. Until you can upgrade and configure the limit, restrict Write access to trusted producers; quotas and max.message.bytes do not mitigate this issue.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the broker validates a record's declared decompressed body size against max.decompressed.message.bytes before allocating, on the produce-validation, log-compaction, and timestamp-lookup paths, and rejects oversized or negative sizes with InvalidRecordException. Operators must set this configuration to a bounded value to be protected, as its default is effectively unlimited.
Several Kafka deserialization paths read a size or count field from input data and use it directly to allocate an array, collection, or byte buffer, with no check against the bytes actually available. A small crafted input can therefore declare a very large size and force a multi-gigabyte allocation. The affected paths are, in Kafka Streams, ProcessorRecordContext (header count), ChangedDeserializer (varint value length), CombinedKeySchema (foreign-key length, which could also produce a negative size), ProcessorMetadata (key length), and AssignmentInfo group-assignment decoding; and, in the clients library, ListDeserializer (used by ListSerde).
Impact:
An attacker can trigger the oversized allocation and raise an OutOfMemoryError that crashes the affected consumer or Kafka Streams thread; the broker and the rest of the cluster are unaffected. The reachable surface depends on the path: writing a crafted record to a Streams application's internal changelog or repartition topics, or committing crafted offset metadata to its consumer group (Streams internal paths); writing a crafted record to any topic that a consumer reads with ListSerde (ListDeserializer); or, as a member of a Streams consumer group, returning crafted assignment data when elected leader (AssignmentInfo). Because a crafted record remains in its topic, the error can recur on restart. The record size limit (max.message.bytes) does not help, because the allocation is driven by a size field rather than by the input's length.
Mitigation:
Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Where authorization is enabled, restrict write access to each application's internal topics and consumer group to its own principal, and restrict who can produce to topics that are consumed with ListSerde.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: these deserialization paths validate the declared size against the remaining input before allocating and reject input that fails the check.
Kafka Streams derives its stream-time clock from record timestamps. PunctuationSchedule.next() computed the next punctuation time as timestamp + (intervalsMissed + 1) * interval with no overflow check. A record with a timestamp at or near Long.MAX_VALUE advances stream time to that value, so the next stream-time punctuation overflows to a negative time. PunctuationQueue then re-queues that time and loops on it indefinitely while holding a lock, stalling the StreamThread.
Impact:
A single record is enough. The affected StreamThread stops processing, and because the record stays in the topic the hang returns on restart; an application whose partitions are all affected becomes unresponsive. Only the Streams application is affected, not the brokers or the cluster. Triggering it needs write access to a source topic whose topology uses stream-time punctuation, and a broker that stores the record: brokers from Apache Kafka 4.0.0 reject such a timestamp by default (log.message.timestamp.after.max.ms, one hour), so it is reachable only on older brokers or where that bound has been relaxed.
Mitigation:
Upgrade Kafka Streams to 4.2.2, 4.3.2, or 4.4.0. As defense in depth, keep log.message.timestamp.after.max.ms bounded on source topics and restrict write access to them.
Resolution:
From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: the next punctuation time is computed with overflow-checked arithmetic (clamped to Long.MAX_VALUE), and a rescheduled punctuation is re-queued only when its time moves forward.
CVE-2026-93523 is a heap-based buffer overflow vulnerability in X.Org X Server and XWayland. It is triggered by a XIPassiveUngrabDevice request containing an out-of-range modifier value. This flaw affects versions of X.Org X Server before 21.1.25 and XWayland before 24.1.14. An authenticated X client could exploit this to crash the X server or potentially execute arbitrary code within the server context.
USB Test is a lightweight Windows CLI utility for verifying sector integrity and detecting overreported capacity on USB flash drives. Prior to version 1.1.5, getSectorSize() in USB Test/src/driveinfo.cpp trusts DISK_GEOMETRY.BytesPerSector returned by IOCTL_DISK_GET_DRIVE_GEOMETRY without checking whether the call succeeded or enforcing size bounds. USB Test/src/drivetest.cpp uses the value for division and to size a heap buffer before memcpy(buffer.data(), §or, 8), so a physically connected malicious USB storage device can report a value below eight bytes and cause repeated out-of-bounds writes, or report zero and cause a divide-by-zero denial of service when a user starts a drive test. The heap corruption can crash the elevated application and may permit arbitrary code execution. This issue is fixed in version 1.1.5.
A heap buffer overflow vulnerability exists in the handling of the GLX RenderLarge request in X.org X server versions before 21.1.25 and XWayland versions before 24.1.14. This flaw occurs when the dataBytes value exceeds the cmdlen, and it can be triggered by an authenticated X client. Exploitation could lead to crashes or arbitrary code execution within the X server context.
A vulnerability in the Linux kernel's netlink subsystem allowed an unprivileged user to infer kernel memory layout details by exploiting how network namespace pointers were hashed. This could enable recovery of the address of init_net, a kernel structure. The issue was fixed by replacing the use of raw network namespace pointers with a unique, non-address net_cookie value in hash keys, preventing information leakage. The fix is compatible with older stable kernels and preserves namespace separation without changing public table walkers.
A vulnerability in the Linux kernel's ring-buffer subsystem caused false warnings in the ring_buffer_map_get_reader() function when the mmap reader caught up with a writer still committing events. This was due to improper handling of a NULL return value from rb_get_reader_page(), which was mistakenly treated as an error. The issue has been fixed by correctly handling the NULL case without warning and removing redundant checks.
A vulnerability in the Linux kernel's iSCSI implementation allows improper validation of the Initiator Task Tag (ITT) reflected in a Reject Protocol Data Unit (PDU). This can lead to the completion of in-flight SCSI commands incorrectly, potentially causing data corruption or kernel crashes. The issue arises because the ITT value from the target is not properly validated before being used to identify tasks, leading to possible reference count underflows and null pointer dereferences.
A vulnerability in the Linux kernel SMB client allows out-of-bounds memory writes when processing SetEA requests with extended attribute values that do not fit the request buffer. This occurs because the CIFSSMBSetEA() function copies the extended attribute value without properly checking buffer size limits before the copy operation, potentially leading to memory corruption.
The BitPay Gateway for WooCommerce WordPress plugin versions through 4.1.3 has a vulnerability where it does not bind the payment provider's transaction confirmation to the specific order nor verify the confirmed payment amount. This flaw allows an unauthenticated attacker who possesses a valid low-value transaction to mark other arbitrary higher-value orders as paid without authorization.