Allocation of Resources Without Limits or Throttling Affecting logstash-9.1-with-output-opensearch package, versions *


Severity

Recommended
low

Based on default assessment until relevant scores are available.

Threat Intelligence

EPSS
0.53% (44th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications
  • Snyk IDSNYK-MINIMOSLATEST-LOGSTASH91WITHOUTPUTOPENSEARCH-19926118
  • published19 Sept 2026
  • disclosed16 Sept 2026

Introduced: 16 Sep 2026

NewCVE-2026-75516  (opens in a new tab)
CWE-770  (opens in a new tab)

How to fix?

There is no fixed version for Minimos:latest logstash-9.1-with-output-opensearch.

NVD Description

Note: Versions mentioned in the description apply only to the upstream logstash-9.1-with-output-opensearch package and not the logstash-9.1-with-output-opensearch package as distributed by Minimos. See How to fix? for Minimos:latest relevant fixed versions and status.

The RabbitMQ Java client library allows Java and JVM-based applications to connect to and interact with RabbitMQ nodes. Prior to 5.34.0, AMQConnection.start() applies Math.min(maxInboundMessageBodySize, frameMax) after Connection.Tune negotiation even though AMQP defines frameMax value zero as unlimited and ConnectionFactory.DEFAULT_FRAME_MAX is zero. When the client default and server-negotiated value are both zero, the result is passed to Utils.framePayloadLimit(int), which interprets zero as Integer.MAX_VALUE and disables the configured maxInboundMessageBodySize cap. A malicious AMQP server, or a man-in-the-middle attacker able to modify Connection.Tune and inject frames into the connection, can then send an oversized frame of any frame type, causing Frame.readFrom() to allocate a large byte array before content-level validation and potentially terminate the client process through memory exhaustion. This issue is fixed in version 5.34.0.