Monthly
Uncontrolled memory allocation in ag-psd's readPsd() lets a remote attacker crash any Node service that parses untrusted Photoshop files: the reader sizes off-heap typed-array buffers from attacker-declared header geometry (width, height, channels, depth and per-layer rectangles) before validating those declarations against the bytes actually present, so a 52-byte PSD can commit roughly 3.17 GB of peak RSS in about 0.45 seconds before a RangeError is raised. All npm releases up to and including 30.2.0 are affected, CVSS 3.1 scores this 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-789), and no authentication, interaction or special configuration is needed - only exposure to attacker-supplied PSD input with default read options. The flaw is not listed in CISA KEV, but the vendor advisory publishes a working 52-byte proof-of-concept input (sha256 a1146a6f…) together with reproduction steps; this is a real, actionable denial-of-service issue rather than a critical emergency, and remediation should be scheduled this week for any service that accepts user-uploaded PSDs.
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit a roughly 90-byte, CRC-valid compressed produce request that declares a decompressed record body of up to about 2 GiB, forcing the broker to attempt that allocation and raise OutOfMemoryError. The flaw is reachable on the produce-validation path when a batch's codec differs from the topic's configured compression.type and records are re-encoded, and a crafted record accepted at ingest can also kill the single default log-cleaner thread when it is later read on a compacted topic, stopping compaction broker-wide (including __consumer_offsets and __transaction_state) across restarts until the record is removed; because OutOfMemoryError is an Error rather than an Exception, the cleaner thread is not restarted. Impact is availability only - no data disclosure or modification - and no public exploit code has been identified at time of analysis. Critically, patching alone does not close exposure: the new max.decompressed.message.bytes setting defaults to an effectively unlimited (~2 GiB) value for backward compatibility, so operators must both upgrade and configure a bounded limit.
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
Eager, unbounded memory allocation in the asynchronous Smile parser (NonBlockingByteArrayParser) lets a Smile feed of roughly ten bytes force a byte[] allocation of approximately 2 GB before any body bytes are consumed, producing an OutOfMemoryError that crashes the request or processing thread on reactive/async Smile endpoints; a VInt crafted to overflow int instead yields a negative length and a NegativeArraySizeException that is not a JacksonException and so escapes the parser contract. Only applications that construct the non-blocking parser via SmileFactory.createNonBlockingByteArrayParser and feed it attacker-supplied Smile bytes are exposed - the blocking SmileParser already contains the (value >>> 25) overflow guard - and no authentication, privileges or user interaction are required beyond the ability to submit data for parsing (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-789). No public exploit code has been identified at time of analysis, although the upstream advisory includes a code-verified reproduction recipe, and fixes are published across all supported branches.
Denial of service in the MQTT5-to-MQTT 3.1.1 compatibility adapter of AWS aws-c-mqtt (versions 0.9.1 through 0.16.1) allows a hostile or impersonated MQTT broker to trigger an excessive memory allocation that crashes the client process, and the crash can recur if the application automatically restarts and reconnects. Exploitation requires that the application uses the compatibility adapter and either connects to an attacker-controlled broker or has its broker traffic tampered with on-path (assessed CVSS 3.1: AV:N/AC:H/PR:N/UI:N/A:H; vendor CVSS 4.0: 8.2 with AT:P). No public exploit identified at time of analysis and no CISA KEV listing; the vendor-released fix is aws-c-mqtt 0.16.2, also bundled in aws-crt-cpp v0.43.9 and AWS IoT Device SDK for C++ v2 v1.45.1.
Apache bRPC before 1.18.0 exposes a denial-of-service condition through its RTMP AMF parser, which trusts 32-bit string lengths and array element counts supplied by untrusted input before verifying that the stream actually contains that much data. A remote, unauthenticated attacker who can reach a bRPC server with the optional RTMP component enabled - or any application passing untrusted data directly into the AMF parser - can send a small crafted AMF payload declaring an oversized long string or array count, forcing excessive memory allocation or resource consumption before parsing fails; no public exploit code or active exploitation has been reported, EPSS is low (0.27%, 19th percentile), and the flaw is rated 7.5 with availability-only impact.
Memory exhaustion in Pillow 8.1.0 through 12.x allows unauthenticated remote attackers to cause denial of service by supplying a crafted APNG that triggers a full-canvas background allocation inside Image.open() before the decompression-bomb check. The flaw is reachable when an application parses untrusted images with an affected version; no pixel loading, frame iteration, authentication, or user interaction is required. No public exploit code or CISA KEV entry was identified at time of analysis, but the availability impact is high (CVSS 8.7; assessed CVSS:3.1 A:H).
Unauthenticated remote attackers can crash Dragonfly through 2.0.2 by issuing a single HRANDFIELD, ZRANDMEMBER, or SRANDMEMBER command with a large negative COUNT against a key holding at least one element, causing an unbounded memory allocation that drives the process into the OOM killer and terminates the instance for every connected client. The CVSS 4.0 vector (8.7) and the independent CVSS 3.1 assessment both rate this AV:N/AC:L/PR:N/UI:N with availability-only impact (C:N/I:N/A:H), so no credentials or user interaction are required out of the box, although the attacker must be able to reach the Dragonfly port and a key of the matching type must exist (or be creatable). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; practical risk is concentrated on internet-exposed or unauthenticated Dragonfly deployments.
Unbounded direct-memory allocation in Eclipse Vert.x's MySQL client (io.vertx:vertx-mysql-client) versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 allows a malicious, compromised, or man-in-the-middle MySQL server to crash the client with an out-of-memory condition before authentication completes. The attacker sends a continuous stream of maximum-length (0xFFFFFF) MySQL protocol packets, preventing the decoder from reaching the end-of-message boundary. This is a denial-of-service issue; no public exploit code has been identified at time of analysis (not in CISA KEV).
An unbounded-memory denial of service in the Eclipse Vert.x PostgreSQL client (io.vertx:vertx-pg-client) allows a malicious, compromised, or man-in-the-middle PostgreSQL server to crash a client application by sending a wire-protocol message header whose 4-byte length field is set to an extremely large value (up to Integer.MAX_VALUE). The client-side decoder performs no maximum-size validation, so it keeps accumulating TCP data into a composite buffer until the JVM exhausts heap and terminates; the abuse happens during connection startup, before authentication completes, so no valid database credentials are required - the attacker only needs to control the server side of the connection or sit on the client-to-PostgreSQL TCP path. Per the independent assessment this is a genuine but conditional availability risk (CVSS 8.2, AV:N/AC:H, availability-only impact) rather than a mass-exploitation priority: no public exploit code or confirmed active exploitation was identified at time of analysis, and clients that connect exclusively to trusted, authenticated, TLS-verified PostgreSQL servers are not realistically exposed.
Uncontrolled memory allocation in ag-psd's readPsd() lets a remote attacker crash any Node service that parses untrusted Photoshop files: the reader sizes off-heap typed-array buffers from attacker-declared header geometry (width, height, channels, depth and per-layer rectangles) before validating those declarations against the bytes actually present, so a 52-byte PSD can commit roughly 3.17 GB of peak RSS in about 0.45 seconds before a RangeError is raised. All npm releases up to and including 30.2.0 are affected, CVSS 3.1 scores this 7.5 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-789), and no authentication, interaction or special configuration is needed - only exposure to attacker-supplied PSD input with default read options. The flaw is not listed in CISA KEV, but the vendor advisory publishes a working 52-byte proof-of-concept input (sha256 a1146a6f…) together with reproduction steps; this is a real, actionable denial-of-service issue rather than a critical emergency, and remediation should be scheduled this week for any service that accepts user-uploaded PSDs.
Memory exhaustion in the Apache Kafka broker lets an authenticated principal holding Write permission on a topic submit a roughly 90-byte, CRC-valid compressed produce request that declares a decompressed record body of up to about 2 GiB, forcing the broker to attempt that allocation and raise OutOfMemoryError. The flaw is reachable on the produce-validation path when a batch's codec differs from the topic's configured compression.type and records are re-encoded, and a crafted record accepted at ingest can also kill the single default log-cleaner thread when it is later read on a compacted topic, stopping compaction broker-wide (including __consumer_offsets and __transaction_state) across restarts until the record is removed; because OutOfMemoryError is an Error rather than an Exception, the cleaner thread is not restarted. Impact is availability only - no data disclosure or modification - and no public exploit code has been identified at time of analysis. Critically, patching alone does not close exposure: the new max.decompressed.message.bytes setting defaults to an effectively unlimited (~2 GiB) value for backward compatibility, so operators must both upgrade and configure a bounded limit.
Network-reachable, unauthenticated deserialization flaws in Apache Kafka’s clients library and Kafka Streams can force multi-gigabyte allocations and crash the consuming application or Streams thread with an OutOfMemoryError; the broker and other cluster components are unaffected. Versions 0.10.0.0 through 4.1.2, 4.2.0 through 4.2.1, and 4.3.0 through 4.3.1 are affected across the Kafka Streams paths (ProcessorRecordContext, ChangedDeserializer, CombinedKeySchema, ProcessorMetadata, AssignmentInfo) and the clients ListDeserializer used by ListSerde. Exploitation requires the ability to place crafted data on the relevant deserialization path-writing to internal changelog or repartition topics, committing offset metadata, supplying crafted group-assignment data as Streams group leader, or producing to a topic consumed with ListSerde; Kafka ACLs block many of these paths when authorization is enabled, no CISA KEV entry is reported in the supplied data, no EPSS score is available, and no public exploit identified at time of analysis.
Eager, unbounded memory allocation in the asynchronous Smile parser (NonBlockingByteArrayParser) lets a Smile feed of roughly ten bytes force a byte[] allocation of approximately 2 GB before any body bytes are consumed, producing an OutOfMemoryError that crashes the request or processing thread on reactive/async Smile endpoints; a VInt crafted to overflow int instead yields a negative length and a NegativeArraySizeException that is not a JacksonException and so escapes the parser contract. Only applications that construct the non-blocking parser via SmileFactory.createNonBlockingByteArrayParser and feed it attacker-supplied Smile bytes are exposed - the blocking SmileParser already contains the (value >>> 25) overflow guard - and no authentication, privileges or user interaction are required beyond the ability to submit data for parsing (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, CWE-789). No public exploit code has been identified at time of analysis, although the upstream advisory includes a code-verified reproduction recipe, and fixes are published across all supported branches.
Denial of service in the MQTT5-to-MQTT 3.1.1 compatibility adapter of AWS aws-c-mqtt (versions 0.9.1 through 0.16.1) allows a hostile or impersonated MQTT broker to trigger an excessive memory allocation that crashes the client process, and the crash can recur if the application automatically restarts and reconnects. Exploitation requires that the application uses the compatibility adapter and either connects to an attacker-controlled broker or has its broker traffic tampered with on-path (assessed CVSS 3.1: AV:N/AC:H/PR:N/UI:N/A:H; vendor CVSS 4.0: 8.2 with AT:P). No public exploit identified at time of analysis and no CISA KEV listing; the vendor-released fix is aws-c-mqtt 0.16.2, also bundled in aws-crt-cpp v0.43.9 and AWS IoT Device SDK for C++ v2 v1.45.1.
Apache bRPC before 1.18.0 exposes a denial-of-service condition through its RTMP AMF parser, which trusts 32-bit string lengths and array element counts supplied by untrusted input before verifying that the stream actually contains that much data. A remote, unauthenticated attacker who can reach a bRPC server with the optional RTMP component enabled - or any application passing untrusted data directly into the AMF parser - can send a small crafted AMF payload declaring an oversized long string or array count, forcing excessive memory allocation or resource consumption before parsing fails; no public exploit code or active exploitation has been reported, EPSS is low (0.27%, 19th percentile), and the flaw is rated 7.5 with availability-only impact.
Memory exhaustion in Pillow 8.1.0 through 12.x allows unauthenticated remote attackers to cause denial of service by supplying a crafted APNG that triggers a full-canvas background allocation inside Image.open() before the decompression-bomb check. The flaw is reachable when an application parses untrusted images with an affected version; no pixel loading, frame iteration, authentication, or user interaction is required. No public exploit code or CISA KEV entry was identified at time of analysis, but the availability impact is high (CVSS 8.7; assessed CVSS:3.1 A:H).
Unauthenticated remote attackers can crash Dragonfly through 2.0.2 by issuing a single HRANDFIELD, ZRANDMEMBER, or SRANDMEMBER command with a large negative COUNT against a key holding at least one element, causing an unbounded memory allocation that drives the process into the OOM killer and terminates the instance for every connected client. The CVSS 4.0 vector (8.7) and the independent CVSS 3.1 assessment both rate this AV:N/AC:L/PR:N/UI:N with availability-only impact (C:N/I:N/A:H), so no credentials or user interaction are required out of the box, although the attacker must be able to reach the Dragonfly port and a key of the matching type must exist (or be creatable). No public exploit code has been identified at time of analysis and the issue is not listed in CISA KEV; practical risk is concentrated on internet-exposed or unauthenticated Dragonfly deployments.
Unbounded direct-memory allocation in Eclipse Vert.x's MySQL client (io.vertx:vertx-mysql-client) versions 4.0.0 through 4.5.34, 5.0.0 through 5.0.12, 5.1.0 through 5.1.9, and 5.2.0 allows a malicious, compromised, or man-in-the-middle MySQL server to crash the client with an out-of-memory condition before authentication completes. The attacker sends a continuous stream of maximum-length (0xFFFFFF) MySQL protocol packets, preventing the decoder from reaching the end-of-message boundary. This is a denial-of-service issue; no public exploit code has been identified at time of analysis (not in CISA KEV).
An unbounded-memory denial of service in the Eclipse Vert.x PostgreSQL client (io.vertx:vertx-pg-client) allows a malicious, compromised, or man-in-the-middle PostgreSQL server to crash a client application by sending a wire-protocol message header whose 4-byte length field is set to an extremely large value (up to Integer.MAX_VALUE). The client-side decoder performs no maximum-size validation, so it keeps accumulating TCP data into a composite buffer until the JVM exhausts heap and terminates; the abuse happens during connection startup, before authentication completes, so no valid database credentials are required - the attacker only needs to control the server side of the connection or sit on the client-to-PostgreSQL TCP path. Per the independent assessment this is a genuine but conditional availability risk (CVSS 8.2, AV:N/AC:H, availability-only impact) rather than a mass-exploitation priority: no public exploit code or confirmed active exploitation was identified at time of analysis, and clients that connect exclusively to trusted, authenticated, TLS-verified PostgreSQL servers are not realistically exposed.