Security update for rabbitmq-server

Announcement ID: SUSE-SU-2026:20126-1
Release Date: 2026-01-22T13:47:27Z
Rating: moderate
References:
Cross-References:
CVSS scores:
  • CVE-2025-30219 ( SUSE ): 5.7 CVSS:4.0/AV:L/AC:H/AT:P/PR:H/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
  • CVE-2025-30219 ( SUSE ): 6.1 CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L
  • CVE-2025-30219 ( NVD ): 6.1 CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L
Affected Products:
  • SUSE Linux Enterprise Server 16.0
  • SUSE Linux Enterprise Server for SAP Applications 16.0

An update that solves one vulnerability can now be installed.

Description:

This update for rabbitmq-server fixes the following issues:

Changes in rabbitmq-server:

Update to 4.1.5:

  • Highlights

  • Khepri, an alternative schema data store developed to replace Mnesia, has matured and is now fully supported (it previously was an experimental feature)

  • AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.
  • The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x on some workloads
  • Efficient sub-linear quorum queue recovery on node startup using checkpoints
  • Quorum queues now support priorities (but not exactly the same way as classic queues)
  • AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it
  • The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about
  • Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types, use quorum queues and/or streams. Non-replicated classic queues remain and their development continues
  • Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages
  • Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster
  • New exchange type: Local Random Exchange
  • Quorum queue log reads are now offloaded to channels (sessions, connections).
  • Initial Support for AMQP 1.0 Filter Expressions
  • Feature Flags Quality of Life Improvements

  • rabbitmqadmin v2

  • Breaking Changes

  • Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate successfully. Before the authenticated phase, a special lower frame_max value is used.

  • With this release, the value was increased from the original 4096 bytes to 8192 to accommodate larger JWT tokens.
  • amqplib is a popular client library that has been using a low frame_max default of 4096. Its users must upgrade to a compatible version (starting with 0.10.7) or explicitly use a higher frame_max. amqplib versions older than 0.10.7 will not be able to connect to RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size increase covered above.
  • The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.

  • The following rabbitmq.conf settings are unsupported:

    • cluster_formation.etcd.ssl_options.fail_if_no_peer_cert
    • cluster_formation.etcd.ssl_options.dh
    • cluster_formation.etcd.ssl_options.dhfile

  • Classic Queues is Now a Non-Replicated Queue Type

  • Quorum Queues Now Have a Default Redelivery Limit
  • Up to RabbitMQ 3.13, when an AMQP 0.9.1 client (re-)published a message to RabbitMQ, RabbitMQ interpreted the
  • AMQP 0.9.1 x-death header in the published message's basic_message.content.properties.headers field.
  • RabbitMQ 4.x will not interpret this x-death header anymore when clients (re-)publish a message.
  • CQv1 Storage Implementation was Removed
  • Settings cluster_formation.randomized_startup_delay_range.* were Removed
  • Several Disk I/O-Related Metrics were Removed
  • Default Maximum Message Size Reduced to 16 MiB
  • RabbitMQ 3.13 rabbitmq.conf setting rabbitmq_amqp1_0.default_vhost is unsupported in RabbitMQ 4.0.
  • RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user, mqtt.default_password, and amqp1_0.default_user are unsupported in RabbitMQ 4.0.
  • Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts: from federation links to shovels to TLS-enabled LDAP client connections.

  • RabbitMQ Shovels will be able connect to a RabbitMQ 4.0 node via AMQP 1.0 only when the Shovel runs on a RabbitMQ node >= 3.13.7.

    • See https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.1
    • and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.1.0 for more info

  • Restore SLES logrotate file, (bsc#1246091)

Patch Instructions:

To install this SUSE update use the SUSE recommended installation methods like YaST online_update or "zypper patch".
Alternatively you can run the command listed for your product:

  • SUSE Linux Enterprise Server 16.0
    zypper in -t patch SUSE-SLES-16.0-171=1
  • SUSE Linux Enterprise Server for SAP Applications 16.0
    zypper in -t patch SUSE-SLES-16.0-171=1

Package List:

  • SUSE Linux Enterprise Server 16.0 (aarch64 ppc64le s390x x86_64)
    • rabbitmq-server-plugins-4.1.5-160000.1.1
    • rabbitmq-server-4.1.5-160000.1.1
    • erlang-rabbitmq-client-4.1.5-160000.1.1
  • SUSE Linux Enterprise Server 16.0 (noarch)
    • rabbitmq-server-zsh-completion-4.1.5-160000.1.1
    • rabbitmq-server-bash-completion-4.1.5-160000.1.1
  • SUSE Linux Enterprise Server for SAP Applications 16.0 (ppc64le x86_64)
    • rabbitmq-server-plugins-4.1.5-160000.1.1
    • rabbitmq-server-4.1.5-160000.1.1
    • erlang-rabbitmq-client-4.1.5-160000.1.1
  • SUSE Linux Enterprise Server for SAP Applications 16.0 (noarch)
    • rabbitmq-server-zsh-completion-4.1.5-160000.1.1
    • rabbitmq-server-bash-completion-4.1.5-160000.1.1

References: