Описание
Security update for rabbitmq-server
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.
-
- Restore SLES logrotate file, (bsc#1246091)
Список пакетов
openSUSE Leap 16.0
Ссылки
- SUSE Security Ratings
- SUSE Bug 1246091
- SUSE CVE CVE-2025-30219 page
Описание
RabbitMQ is a messaging and streaming broker. Versions prior to 4.0.3 are vulnerable to a sophisticated attack that could modify virtual host name on disk and then make it unrecoverable (with other on disk file modifications) can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions will display an error message (a notification) in the management UI. The error message includes virtual host name, which was not escaped prior to open source RabbitMQ 4.0.3 and Tanzu RabbitMQ 4.0.3, 3.13.8. An attack that both makes a virtual host fail to start and creates a new virtual host name with an XSS code snippet or changes the name of an existing virtual host on disk could trigger arbitrary JavaScript code execution in the management UI (the user's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.
Затронутые продукты
Ссылки
- CVE-2025-30219
- SUSE Bug 1240071