Vulnerabilities (CVE)

CESNET ipfixcol2 2.3.0 before 2.9.0 contains an integer overflow vulnerability in the Forwarder output plugin that allows unauthenticated IPFIX exporters to overflow a heap buffer by wrapping uint16_t message length counters. Attackers can send near-65535-byte data sets and large templates to a collector forwarding over TCP to crash it and perform 2-byte writes to attacker-influenced addresses.Show less

CESNET ipfixcol2 2.7.1 before 2.9.0 contains a heap-based buffer overflow in Lz4Decoder.cpp that allows unauthenticated network peers to write past heap buffers. Attackers can declare a small ring buffer_size followed by a large decompressed_size to write up to 65535 controlled bytes and crash the collector.Show less

reSIProcate reTurn client through 1.14.0 contains a heap buffer overflow in TurnTcpSocket::handleReadHeader(), which TurnTlsSocket inherits, that allows malicious TURN servers or on-path attackers to overwrite memory via oversized frame lengths. Attackers can send STUN or ChannelData frames declaring up to 65535 bytes, writing roughly 57 KB past the fixed 8192-byte mReadBuffer and crashing the client. Only the synchronous TCP and TLS client is affected; the asynchronous client (TurnAsyncSocket) and the reTurn server are not.Show less

netrek-client-cow through 3.3.3 contains a stack-based buffer overflow vulnerability in handleSMessage() in short.c that allows malicious servers to overflow a 100-byte stack buffer by sending oversized SP_S_MESSAGE packets. A malicious Netrek server or man-in-the-middle on the plaintext TCP connection can send overlong or unterminated message bodies to write server-controlled bytes onto the stack and crash the client.Show less

Netrek-client-cow through 3.3.3 contains an out-of-bounds read vulnerability in short.c handleSMessage() that allows malicious servers to crash clients via an unchecked m_recpt index. Attackers controlling a Netrek server or intercepting the plaintext TCP connection can send SP_S_MESSAGE packets with m_recpt of 36 or more, reading past players[] and shipnos to deny service.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

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.Show less

HTTP::Body versions before 1.23_01 for Perl allow CPU exhaustion via quadratic rescanning of a multipart body with a missing or malformed boundary. Before the first part, and between parts, the multipart parser searches the whole buffered body for the next boundary. On a miss it keeps everything and searches again from the start when the next chunk arrives. A body with no boundary, or with a delimiter followed by neither CRLF nor "--", is therefore rescanned on every chunk, taking time quadratic in its size. A remote attacker can exhaust worker CPU with a few such requests.Show less

HTTP::Body versions before 1.23_01 for Perl leave the temporary file of an incomplete multipart upload on disk. The multipart parser creates a temporary file as soon as a file part starts, but adds it to the upload list only when the part completes. Uploads are only ever deleted from that list, by the cleanup option or by the caller, so a body that ends inside a file part leaves its temporary file where nothing can find it. A remote attacker can fill the temporary directory by repeating such requests, leaving one file behind for each.Show less

HTTP::Body versions before 1.23_01 for Perl allow memory and temporary file exhaustion via an unlimited number of form fields and multipart parts. The urlencoded parser splits the whole body on its separators at once, creating one scalar per separator before any field is stored. This costs about 90 bytes of memory per separator byte. The multipart parser creates a temporary file for every part that carries a filename. Neither parser limits how many fields or parts a body may hold. A remote attacker can exhaust worker memory with a body made of separators, or create thousands of temporary files with one request of small file parts.Show less

Mongoose is an embedded web server and network library. Prior to 7.22, mg_path_is_sane in src/util.c read path.buf[1] without first requiring path.len to be at least two and read s[2] when only two bytes remained. Unauthenticated remote requests reaching mg_http_upload or mg_http_serve_dir with the affected short path shapes could therefore trigger one-byte heap out-of-bounds reads. On bare-metal or RTOS targets without memory protection, the adjacent byte could be exposed or influence whether a path was accepted, and instrumented builds could crash. This issue is fixed in version 7.22.Show less

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.Show less

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.Show less

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).Show less

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.Show less