CVE Feed

russh is a Rust SSH client and server library that includes an SSH agent protocol implementation. From 0.50.0-beta.12 until 0.65.0, the agent server's Connection::try_sign path in russh/src/keys/agent/server.rs recognizes SSH_AGENT_CONSTRAIN_CONFIRM but returns a hard-coded successful result instead of calling Agent::confirm. In applications that override Agent::confirm to require user approval or another policy check, a process that can reach the agent socket, including the remote side of a forwarded agent, can use a key added through ssh-add -c without that check and can authenticate or sign data as the user while the key remains loaded. The separate Agent::confirm_request hook still runs for every signing request, so checks implemented there remain effective, and implementations that retain the default always-successful Agent::confirm do not lose an approval check through this regression. This issue is fixed in version 0.65.0.

ethernet_fill_header() in subsys/net/l2/ethernet/ethernet.c can prepend the Ethernet header in place, by pushing it into the headroom of the packet's first fragment, instead of allocating a separate header fragment. Before this fix the in-place path was selected purely from the build-time value of CONFIG_NET_L2_ETHERNET_RESERVE_HEADER, with no check that the packet actually has that headroom, and then called net_buf_push(pkt->buffer, hdr_len). Only Ethernet TX allocations reserve that space: net_pkt_alloc_buffer() invokes the L2 alloc hook (ethernet_l2_alloc()) only when is_pkt_tx() is true and the packet's interface is the Ethernet interface. A packet that was allocated by a different L2 and then handed to Ethernet for transmission therefore has too little (usually zero) headroom. Such packets are produced by ordinary routing and tunnelling paths: net_route_packet_if() re-targets a received packet to another interface when CONFIG_NET_IPV4_FORWARDING / CONFIG_NET_IPV6_FORWARDING are enabled (for example an 802.15.4/OpenThread or PPP interface forwarding to Wi-Fi/Ethernet), net_route_ipv6_mcast_forward_packet() forwards an RX-slab clone that carries no reserve, and the IPIP tunnel interface_send() prepends an outer IP header allocated on the virtual interface. In these configurations a remote or adjacent attacker triggers the condition simply by sending traffic that the device forwards. Because net_buf_simple_push() only asserts on the headroom bound, a build without CONFIG_ASSERT (and without the newer CONFIG_NET_BUF_HARDENING) moves the fragment data pointer below the start of its data block and writes 14 bytes — 18 with VLAN — of Ethernet header out of bounds. With the default fixed-size buffer pools this overwrites the tail of the neighbouring buffer's payload or memory preceding the pool array; with variable-size pools it overwrites the buffer reference count and the heap chunk header. The attacker controls neither the written bytes nor the offset, so the practical impact is memory corruption leading to a crash, packet corruption, or heap inconsistency rather than controlled code execution. The fix takes the in-place path only when net_buf_headroom(pkt->buffer) is large enough and otherwise falls back to a separate header fragment.

The GPIO syscall handlers in drivers/gpio/gpio_handlers.c did not validate the pin argument supplied by a user-mode caller. z_vrfy_gpio_pin_configure(), z_vrfy_gpio_pin_get_config() and z_vrfy_gpio_pin_interrupt_configure() verified only the device object (K_SYSCALL_DRIVER_GPIO() / K_SYSCALL_OBJ()) and then passed the caller-supplied gpio_pin_t straight through to z_impl_gpio_pin_*() and on to the driver. The only pin check in include/zephyr/drivers/gpio.h was __ASSERT(gpio_port_pin_is_supported(cfg->port_pin_mask, pin), ...), which compiles to nothing unless CONFIG_ASSERT is enabled, so in a production build no check existed at all. GPIO drivers use pin as a shift count and as an array index on the documented assumption that it is a pin the controller supports. On STM32, for example, gpio_stm32_pin_interrupt_configure() turns pin into an EXTI line and stm32_gpio_intc_set_irq_callback() writes data->cb[line_num].cb and data->cb[line_num].data into a NUM_EXTI_LINES-entry array (default 16) in drivers/interrupt_controller/intc_gpio_stm32.c, guarded only by a compiled-out __ASSERT_NO_MSG(); the same function then reads exti_irq_table[line_num] and calls irq_enable() on the result. Other controllers index fixed-size per-pin configuration tables the same way — drivers/gpio/gpio_ite_it8xxx2_v2.c reads an MMIO base pointer out of wuc_base[8] with the caller's pin and performs a read-modify-write through it. The issue is reachable only in builds with CONFIG_USERSPACE=y (the file is compiled under that symbol), by a user-mode thread that has been granted access to a GPIO device object. Such a grant is intended to authorize control of that port's pins; the missing validation instead lets the thread drive a supervisor-mode out-of-bounds write of a function pointer and an associated void * past a kernel .bss array, and out-of-bounds reads that feed irq_enable() and MMIO accesses — an escape from the user-mode sandbox that can lead to kernel memory corruption, arbitrary code execution, or a crash. The fix validates pin against the controller's gpio_driver_config.port_pin_mask with gpio_port_pin_is_supported() in every pin-taking z_vrfy_ handler and returns -EINVAL otherwise, complemented by an unconditional pin >= GPIO_MAX_PINS_PER_PORT range check added to the shared z_impl_gpio_pin_*() inlines.

A flaw was found in openshift-ansible. The installer container's `run` script downloads and executes remote inventory and dynamic scripts without integrity verification. A remote attacker, by performing a Man-in-the-Middle (MITM) attack or compromising the HTTP server providing these scripts, could substitute an arbitrary executable. This malicious executable would then run with the installer's user ID (UID) and full cluster-provisioning privileges, leading to arbitrary code execution.

Ultralytics Google Drive Download Path Traversal Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of downloads from Google Drive. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute arbitrary code in the context of the current process. Was ZDI-CAN-32376.

Ultralytics parse_model Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parse_model function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-30121.

Ultralytics load_dataset_cache_file Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the load_dataset_cache_file function. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-30124.

Ultralytics parse_model Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parse_model function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-30123.

Ultralytics torch_safe_load Command Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the torch_safe_load function. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-30122.

Ultralytics check_det_dataset Code Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the check_det_dataset function. The issue results from the lack of proper validation of a user-supplied string before using it to execute Python code. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-30119.

Ultralytics torch_load Deserialization of Untrusted Data Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Ultralytics. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the torch_load function. The issue results from the lack of proper validation of user-supplied data, which can result in deserialization of untrusted data. An attacker can leverage this vulnerability to execute code in the context of the current user. Was ZDI-CAN-29652.

A BSON encoding component of the MongoDB Java Driver does not verify that an externally supplied raw document's self-declared length agrees with the extent of the byte range it is given before that range is copied into an outgoing database command. An application that wraps untrusted raw bytes in such a document and uses it as part of a command can therefore emit a structurally inconsistent message, causing the database to interpret attacker-supplied trailing content as additional fields of the surrounding command. No authentication to the driver or database is required beyond the ability to influence those bytes through the victim application, and no user interaction is needed. The result is unintended modification of the command actually executed, which can alter the data read or written under the application's credentials.

Alpine iLX-F511 Bluetooth OBEX Packet Handling Heap-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the handling of Bluetooth OBEX packets. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29012.

Alpine iLX-F511 Android Auto Service Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the Android Auto service. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29015.

Alpine iLX-F511 Android Auto Connection Handler Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the Android Auto connection handler. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29016.

Alpine iLX-F511 libanwbtstack.so prh_rfcomm_cc_process_test Out-Of-Bounds Read Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of Alpine iLX-F511 devices. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability. The specific flaw exists within the prh_rfcomm_cc_process_test function. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-29018.

Alpine iLX-F511 diagapp Command Injection Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the diagapp component. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-28750.

Alpine iLX-F511 Framework Service Exposed Dangerous Function Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the framework service. The issue results from an exposed dangerous function. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29006.

Alpine iLX-F511 prh_sdp_service_search_decode Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. An attacker must first obtain the ability to pair a malicious Bluetooth device with the target system in order to exploit this vulnerability. The specific flaw exists within the prh_sdp_service_search_decode function. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29069.

Alpine iLX-F511 Framework Service Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the framework service. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29007.

Alpine iLX-F511 vCard Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected Alpine iLX-F511 devices. User interaction is required to exploit this vulnerability in that the target must connect to a malicious Bluetooth device. The specific flaw exists within the parsing of vCard data. The issue results from the lack of proper validation of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-29017.

Alpine iLX-F511 Fiv.System Exposed Dangerous Method Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Alpine iLX-F511. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the Fiv service. The issue results from an exposed dangerous method. An attacker can leverage this vulnerability to escalate privileges and execute arbitrary code in the context of root. Was ZDI-CAN-29095.

Alpine iLX-F511 SSH Hard-Coded Credentials Remote Code Execution Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-F511 devices. Authentication is not required to exploit this vulnerability. The specific flaw exists within the SSH service. The issue results from the use of hard-coded credentials. An attacker can leverage this vulnerability to execute code in the context of the telechips user. Was ZDI-CAN-29013.

A user with permission to edit contact points but not their protected fields can change protected settings, such as a contact point's destination URL, by switching an integration to a legacy schema version, which can expose stored credentials and redirect alert notifications (incorrect authorization).

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier improperly identifies file paths attempting path traversal in the file browser for workspaces and $JENKINS_HOME/userContent/, allowing attackers with Overall/Read permission to obtain the names, sizes, and last modification times of files in the $JENKINS_HOME, and attackers with Item/Workspace permission to obtain the names of jobs that have a workspace on the same agent.

A missing permission check in Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows attackers with Overall/Read permission to obtain the server, port, user name, and no-proxy host list of the configured HTTP proxy.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not consistently enforce the restriction on deserializing objects of types marked as storing their configuration in independent top-level configuration files as nested values, allowing attackers to bypass the root element check and potentially inject nested objects.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not escape the text shown in the tooltips of breadcrumb bar overflow menu entries, resulting in a stored cross-site scripting (XSS) vulnerability exploitable by attackers with Overall/Read permission.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows agents to send exceptions implementing the Stapler HttpResponse interface to the controller, resulting in a cross-site scripting (XSS) vulnerability exploitable by attackers in control of agent processes.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier computes on the agent the URL of the link shown in the workspace browser for each file and directory, resulting in a cross-site scripting (XSS) vulnerability exploitable by attackers in control of agent processes.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows attackers with Overall/Read permission to trigger warnings in the "Manage Old Data" feature that can be acted on by administrators to inject attacker-controlled data, overriding existing user account information, including login passwords.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier allows requests authenticated using HTTP Basic authentication, including with an API token, to obtain a "remember me" cookie, allowing attackers who have obtained a user's API token to retain access to Jenkins using a "remember me" cookie after the API token is revoked or expires.

In Jenkins 2.587 and earlier, LTS 2.580.1 and earlier, the HTTP endpoint for creating the first user account does not check whether the setup wizard has been completed, resulting in a race condition that allows unauthenticated attackers to create an administrator account while the initial user account is being replaced.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier checks for symbolic links in the path of an extracted file only before creating its parent directories, not immediately before writing it, and allows symbolic links in artifacts to replace existing files or empty directories, allowing attackers with Item/Configure permission to write files to arbitrary locations on the Jenkins controller file system.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier provides an HTTP endpoint that loads agents by name without validating the name, allowing attackers with Overall/Read permission to load any config.xml file on the controller file system as an agent configuration, and to overwrite an arbitrary config.xml file when that agent is saved, potentially resulting in arbitrary code execution.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier follows symbolic links when copying the directory of an item being renamed, allowing attackers with Item/Create and Item/Configure permission to read arbitrary files on the Jenkins controller file system.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier converts the launch commands in older agent configurations into launchers provided by the Command Agent Launcher Plugin without checking whether they have been approved by an administrator, allowing attackers with Agent/Configure permission to execute arbitrary code in the context of the Jenkins controller JVM.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not restrict item types in collections after deserialization, allowing attackers with access to POST config.xml API endpoints to submit crafted `config.xml` files that can lead to, e.g., stored cross-site scripting (XSS) vulnerabilities.

Jenkins 2.587 and earlier, LTS 2.580.1 and earlier does not apply its deserialization filter to classes referenced by the `resolves-to` attribute during XStream deserialization.

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.

An authenticated Kafka principal with no authorization grants (not even ALTER_CONFIGS) can make a broker read a file or an environment variable from the broker host and return its contents. An IncrementalAlterConfigs (or AlterConfigs) request targeting a BROKER resource reaches the broker's configuration validation before any authorization check is applied to that path. Validation resolves configuration variables such as ${file:/path:key} or ${env:VAR} using a ConfigProvider named in the request, and this resolution bypasses the org.apache.kafka.automatic.config.providers allowlist that was added as the mitigation for CVE-2024-31141. An arbitrary ConfigProvider (for example FileConfigProvider or EnvVarConfigProvider) is therefore instantiated and the referenced file or environment variable is read, and a type-validation error returns the resolved content to the caller. Impact: On a cluster with an authorizer enabled, an authenticated principal with no authorization grants can read the contents of files accessible to the broker process, and the broker's environment variables, exposing credentials, keystores, or other secrets, defeating the CVE-2024-31141 allowlist. The read is bounded by the broker process's file permissions. The brokers and the cluster remain available; the issue is disclosure of file and environment- variable contents. Clusters with no authorizer configured are not affected in practice, because every principal already holds ALTER_CONFIGS there. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. As defense in depth, run brokers under a least-privileged operating-system account so that sensitive files are not readable by the broker process. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: broker configuration changes are authorized (ALTER_CONFIGS on the cluster) before the configuration is validated, and configuration- variable resolution enforces the config-providers allowlist.

Apache Kafka Connect has the /connector-plugins/{connector-type}/config/validate endpoint on its REST API to validate connector configurations. Apache Kafka Connect also support Configuration Providers which enable to hide the values of sensitive configuration and only resolve them at runtime.  An attacker with access to the validate endpoint can use it to resolve and return plaintext values via any of the configuration providers installed on a Connect worker. Users are recommended to upgrade to version 4.2.2, 4.3.2, 4.4.0 or above, which fix this issue.

Apache Kafka Connect contains an authentication bypass vulnerability affecting the admin REST API when admin.listeners is configured with a separate listener from the main listeners property. When operators isolate the admin REST API by explicitly configuring the "admin.listeners" property, REST extensions specified via rest.extension.classes (such as BasicAuthSecurityRestExtension) are not registered or applied to the admin resource configuration. While the primary REST API listener (configured via listeners) enforces configured authentication and authorization filters, endpoints mounted under the separate admin listener (/admin/loggers) fail to inherit or instantiate these extension filters. As a result, the admin logger endpoint accepts unauthenticated read and write requests even when security extensions are active on the main listener. Impact: An unauthenticated attacker with network access to the admin listener can: 1. Read the complete set of logger names and levels, disclosing loaded class names and which security extensions are in use. 2. Write logger levels, including with scope=cluster which propagates the change to all workers in the Connect cluster. This can be used to suppress logging (setting root to OFF) or generate excessive log output (setting root to TRACE), potentially impacting availability and observability. Mitigation: Users who cannot upgrade immediately can remove the admin.listeners configuration (or leave it unset). When unset, admin resources share the regular listener and inherit its security extensions. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0, we make sure the REST extensions specified via "rest.extension.classes" will also apply to "admin.listeners".

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.

Apache Kafka's code-generated readers for flexible protocol versions read a tagged-field count declared by the sender and retain a RawTaggedField object for each unknown field. That count was bounded only by the outer request frame size (socket.request.max.bytes); it was not checked against the remaining buffer bytes or capped. Because each entry can be encoded in as little as two bytes (unknown tag 0, size 0), a modest request can declare tens of millions of tagged fields and force one object allocation per declared field. Flexible request headers (header version 2, used by flexible APIs such as ApiVersions v3) are parsed this way, so the amplification applies to the request header itself. Impact: The flexible request header is parsed on the network thread before authorization, request dispatch, and request-time quota accounting. A client can send a request of a few tens of megabytes whose header declares about 20 million tagged fields, forcing roughly that many RawTaggedField allocations and exhausting broker heap or inducing process-wide GC stalls, denying broker service. Because the header is parsed for pre-authentication APIs such as ApiVersions (v3), the allocation can occur before authentication; no Kafka resource ACL or quota is required. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers bounds-check the tagged-field count for flexible-versioned messages, rejecting a negative count, a count exceeding the remaining buffer bytes, or a count exceeding a fixed maximum (10,000), before any per-field allocation.

Apache Kafka's code-generated protocol readers pre-size an array's collection from the element count declared by the sender. That count is checked only against the bytes remaining in the request buffer, which assumes about one byte per element; because most elements need several bytes, a request can declare far more elements than the buffer holds and still pass. For a keyed array the reader then allocates an ImplicitLinkedHashCollection of capacity (2 * count +1), so a request of a few tens of megabytes can force a heap allocation several times larger before any element is read. The pattern is emitted into every generated reader, so it affects all Kafka API types with an array field.  Impact: Request parsing happens before any authorization check. On a listener that does not require authentication (for example PLAINTEXT), an unauthenticated attacker can send a few concurrent requests that each declare a very large= array length and allocate many times their wire size in broker heap, crashing the broker with an OutOfMemoryError. The reporter demonstrated three concurrent ~90 MB ProduceRequest (v3) connections exhausting a 1 GB heap (~8x amplification). On listeners that require authentication, the attacker needs valid credentials but no specific ACL, since parsing precedes authorization.. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.2, or 4.4.0. Until then, lowering socket.request.max.bytes and restricting network access to broker listeners reduces, but does not remove, exposure. Resolution: From Apache Kafka 4.2.2, 4.3.2, and 4.4.0: generated readers cap the initial array pre-allocation at MessageUtil.MAX_PREALLOCATED_ARRAY_CAPACITY (1000) and grow it on demand, and reject a declared array length above MessageUtil.MAX_ARRAY_LENGTH (1,000,000).

The broker-side PushTelemetry API (KIP-714) validates only the compressed size of a client's metrics payload against telemetry.max.bytes (default 1 MB) before decompressing it. ClientTelemetryUtils.decompress() then decompresses the payload with no limit on the decompressed output size, growing a heap buffer until the compressed input is exhausted. A small, highly compressible payload (for example gzip-compressed zeros) can therefore expand to hundreds of megabytes of broker heap. Impact: An authenticated client can send a PushTelemetry request with a small compressed payload that decompresses to a very large size, consuming broker heap out of proportion to the request size. Repeated or concurrent requests can exhaust the broker heap and cause an OutOfMemoryError, degrading or crashing the broker; a client that targets multiple brokers can affect cluster availability. PushTelemetry is available to any authenticated client and is not gated by an ACL. Mitigation: Upgrade to Apache Kafka 4.2.2, 4.3.1, or 4.4.0. On affected versions there is no configuration that fully prevents the amplification, because telemetry.max.bytes bounds only the compressed size; lowering telemetry.max.bytes reduces the worst-case decompressed size proportionally and is a partial mitigation. Resolution: - From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: ClientTelemetryUtils.decompress() enforces a maximum decompressed size equal to telemetry.max.bytes (default 1 MB). Decompression reads in bounded chunks and aborts with a TelemetryTooLargeException once the decompressed total exceeds the limit, so an over-large or highly compressible payload is rejected instead of being fully expanded in heap. The decompressed size is therefore bounded by default.

An Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in AccessManager in Juniper Networks Session Smart Router and Session Smart Conductor allows an attacker with config-write privileges to achieve arbitrary command execution as root in the YANG configuration.

A Kafka broker using SASL/OAUTHBEARER with the default validator (sasl.oauthbearer.jwt.validator.class=DefaultJwtValidator) selects its implementation from configuration. When sasl.oauthbearer.jwks.endpoint.url is set, the validator verifies the JWT signature. When that URL is unset (the default) and no verification key resolver is supplied, DefaultJwtValidator silently falls back to ClientJwtValidator, which does not verify the JWT signature, algorithm, or issuer - and the broker starts with no warning or error. This is the residual of CVE-2026-33557, whose fix restored signature verification only on the path where the JWKS endpoint URL is set. Impact: A broker in this state accepts any structurally valid JWT, including "alg":"none" tokens. An unauthenticated remote attacker who can reach the listener can forge a token asserting any principal - including configured superusers - and gain full access to the cluster. Only brokers that enable SASL/OAUTHBEARER validation without a JWKS endpoint URL (and without a custom verification key resolver) are affected; brokers that set the URL verify signatures and are not affected. Unlike CVE-2026-110952 (issuer/audience not enforced by default), here no signature is verified at all. Mitigation (all affected versions, no upgrade required): Set sasl.oauthbearer.jwks.endpoint.url for every listener/mechanism that uses OAuthBearerValidatorCallbackHandler, or configure a signature-verifying sasl.oauthbearer.jwt.validator.class. Resolution: From Apache Kafka 4.2.2, 4.3.1, and 4.4.0: a broker that would fall back to the non-verifying ClientJwtValidator fails to start with a ConfigException instead of running without signature verification (secure by default).