{"affected":[{"ecosystem_specific":{"binaries":[{"erlang-rabbitmq-client":"4.1.5-160000.1.1","rabbitmq-server":"4.1.5-160000.1.1","rabbitmq-server-bash-completion":"4.1.5-160000.1.1","rabbitmq-server-plugins":"4.1.5-160000.1.1","rabbitmq-server-zsh-completion":"4.1.5-160000.1.1"}]},"package":{"ecosystem":"openSUSE:Leap 16.0","name":"rabbitmq-server","purl":"pkg:rpm/opensuse/rabbitmq-server&distro=openSUSE%20Leap%2016.0"},"ranges":[{"events":[{"introduced":"0"},{"fixed":"4.1.5-160000.1.1"}],"type":"ECOSYSTEM"}]}],"aliases":[],"details":"This update for rabbitmq-server fixes the following issues:\n\nChanges in rabbitmq-server:\n\nUpdate to 4.1.5:\n\n* Highlights\n\n  - Khepri, an alternative schema data store developed to replace Mnesia,\n    has matured and is now fully supported (it previously was an experimental feature)\n  - 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.\n  - The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x\n    on some workloads\n  - Efficient sub-linear quorum queue recovery on node startup using checkpoints\n  - Quorum queues now support priorities (but not exactly the same way as classic queues)\n  - AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it\n  - The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about\n  - Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,\n    use quorum queues and/or streams. Non-replicated classic queues remain and their development continues\n  - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages\n  - Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster\n  - New exchange type: Local Random Exchange\n  - Quorum queue log reads are now offloaded to channels (sessions, connections).\n  - Initial Support for AMQP 1.0 Filter Expressions\n  - Feature Flags Quality of Life Improvements\n  - rabbitmqadmin v2\n\n* Breaking Changes\n\n  - Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate\n    successfully. Before the authenticated phase, a special lower frame_max value\n    is used.\n  - With this release, the value was increased from the original 4096 bytes to 8192\n    to accommodate larger JWT tokens.\n  - amqplib is a popular client library that has been using\n    a low frame_max default of 4096. Its users must upgrade to a compatible version\n    (starting with 0.10.7) or explicitly use a higher frame_max.\n    amqplib versions older than 0.10.7 will not be able to connect to\n    RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size\n    increase covered above.\n  - The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.\n  - The following rabbitmq.conf settings are unsupported:\n\n    - cluster_formation.etcd.ssl_options.fail_if_no_peer_cert\n    - cluster_formation.etcd.ssl_options.dh\n    - cluster_formation.etcd.ssl_options.dhfile\n\n  - Classic Queues is Now a Non-Replicated Queue Type\n  - Quorum Queues Now Have a Default Redelivery Limit\n  - Up to RabbitMQ 3.13, when an AMQP 0.9.1 client (re-)published a message to RabbitMQ, RabbitMQ interpreted the\n  - AMQP 0.9.1 x-death header in the published message's basic_message.content.properties.headers field.\n  - RabbitMQ 4.x will not interpret this x-death header anymore when clients (re-)publish a message.\n  - CQv1 Storage Implementation was Removed\n  - Settings cluster_formation.randomized_startup_delay_range.* were Removed\n  - Several Disk I/O-Related Metrics were Removed\n  - Default Maximum Message Size Reduced to 16 MiB\n  - RabbitMQ 3.13 rabbitmq.conf setting rabbitmq_amqp1_0.default_vhost is unsupported in RabbitMQ 4.0.\n  - RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user, mqtt.default_password,\n    and amqp1_0.default_user are unsupported in RabbitMQ 4.0.\n  - Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts:\n    from federation links to shovels to TLS-enabled LDAP client connections.\n  - 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.\n\n    * See https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.1\n    * and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.1.0 for more info\n\n- Restore SLES logrotate file, (bsc#1246091)\n","id":"openSUSE-SU-2026:20082-1","modified":"2026-01-22T13:47:27Z","published":"2026-01-22T13:47:27Z","references":[{"type":"ADVISORY","url":null},{"type":"REPORT","url":"https://bugzilla.suse.com/1246091"},{"type":"WEB","url":"https://www.suse.com/security/cve/CVE-2025-30219"}],"related":["CVE-2025-30219"],"summary":"Security update for rabbitmq-server","upstream":["CVE-2025-30219"]}