| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| Use after free in Remote Desktop Client allows an unauthorized attacker to execute code over a network. |
| 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. |
| Use after free in Windows SMB Server allows an authorized attacker to elevate privileges locally. |
| Use after free in Windows DHCP Server allows an unauthorized attacker to execute code over a network. |
| Heap-based buffer overflow in Windows UI Immersive Server allows an authorized attacker to elevate privileges locally. |
| 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". |
| Use after free in Windows Direct Composition allows an authorized attacker to elevate privileges locally. |
| 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. |
| Heap-based buffer overflow in Windows Win32K - GRFX allows an authorized attacker to elevate privileges locally. |
