The Solace appliance now exposes NAB egress throughput per-interface via CLI and SEMP (e.g. `show interface rates`). Users with global read-only access can now check current throughput across all NAB interfaces alongside other broker statistics.

A count of the number of shared subscriptions in use against the system limit has been added to the show->smrp->subscriptions->summary CLI command. And, the SYSTEM_ROUTING_SUBSCRIPTIONS_LOAD_FACTOR_HIGH event has been augmented to consider the number of shared subscriptions. This provides an early warning as the system limit is approached and a way to monitor the current number of shared subscriptions in use.

Support for the CHS-3560AC-08-A chassis variant is added as of this release.

This feature adds the ability to disable basic authentication (username/password) for SEMP and Broker Manager via a new CLI command: configure/authentication/basic/semp shutdown. When basic authentication is disabled: All SEMP API requests using basic credentials are rejected with 401 Unauthorized. Broker Manager login page displays only OAuth authentication options. CLI access via SSH continues to support basic authentication for emergency access. Important: Disabling basic authentication will prevent access to management tools that do not support OAuth, including SolAdmin, configuration wizards, and custom SEMP scripts. Ensure OAuth is properly configured before disabling basic authentication. Configuration: Default is basic authentication enabled. CLI command to disable: configure/authentication/basic/semp shutdown. CLI command to enable: configure/authentication/basic/semp no shutdown.

This feature enables the broker to check multiple credential sources during client basic authentication. When a client username is not found in the internal database, authentication can fall back to LDAP, allowing organizations to maintain human user credentials in enterprise directory systems (like Active Directory) while storing application credentials locally on the broker. This supports regulatory compliance requirements and enables phased migration strategies.

A new readiness endpoint has been added to the broker health-check to facilitate operation of the broker in automated environments like Kubernetes. The readiness endpoint is suitable for pod distribution budgets during broker upgrades in Kubernetes environments, augmenting the existing load-balancer health-check endpoint.

As part of Distributed Tracing, AMQP messages published to or received from a Solace Event Broker will automatically propagate (in trace spans and downstream messages) any tracing information in its W3C context propagation header.

This feature enables configuration of the send-to-DMQ (Dead Message Queue) behavior per-endpoint, rather than relying on the dmq-eligible flag in published messages. This provides more granular control over how dead messages are handled and removes the reliance on the publishing application to set the dmq-eligible flag correctly. Endpoints can be configured to respect-dmq-eligible (implementing the existing behavior) or if respect-dmq-eligible is not enabled, all dead messages will be sent to the DMQ if configured. If respect-dmq-eligible is not enabled and no DMQ is configured, then dead messages will be discarded.

Customers who have purchased Insights to observe their event mesh can now easily install the Insights Agent in their appliances without Solace support.

PubSub+ Software Event Brokers with max-connections set to 1000 can now support Guaranteed messages up to 30 MB, previously available only at higher scaling tiers. To enable this, additional memory must be allocated and the new system scaling parameter max-guaranteed-message-size must be configured. See https://docs.solace.com/Software-Broker/System-Resource-Calculator.htm and https://docs.solace.com/Software-Broker/Set-Scaling-Params-Standalone.htm?Highlight=scale for details.

After a Dynamic Message Routing (DMR) cluster link bounces, if the broker has Content Shortest Path First (CSPF) neighbors, it may take longer than expected (up to 1 minute) for the CSPF neighbor to become operationally active again.

Solace Cloud and Solace Software Event Broker version 10.25.23.7878 will not start up successfully when running on Linux kernel version 6.1 in any Linux distribution. The change previously announced under SOL-145849 was reverted to resolve this issue.

In rare cases on appliances with very high traffic rates, messaging statistics may be incorrect.

For appliances receiving a high volume of TLS connections, client connections may time out due to server-side delays in sending the server certificate during the TLS handshake. Aggressive client reconnection attempts can sustain and worsen the condition.

When using Precision Time Protocol (PTP) for clock synchronization, the broker may experience significant time offset after a reboot following extended uptime periods.

A memory leak can occur when deleting OAuth profiles that use JWKS endpoints. Both global and Message VPN OAuth profiles are exposed with repeated profile deletions or reconfigurations.

When message priority is enabled and a flow transitions out of streaming state, a race condition may cause messages to be redelivered to flows and discarded due to their Time-To-Live (TTL) value, while newer messages continue to be processed normally.

In High Availability (HA) configurations with software event brokers, an error affecting the internal state of mate link operations may prevent the standby broker from recovering redundancy under certain conditions following a broker restart.

SSL clients may remain stuck on the broker after closing their TCP connections. When this occurs, the connections display a "CLOSED" state but clients are not completely disconnected from the broker.

The broker may restart unexpectedly due to a race condition during routine internal certificate rotation.

Appliances may incorrectly report external disk paths removed when SANs have a burst of path change activity triggering unnecessary or unexpected failovers, even when storage connectivity remains healthy.

Windows executable (.exe) files are present in the Python site-packages directory of the broker container. These files are benign and used for Windows Python package installation, but can be flagged by some security tools as suspicious.

In rare cases, running assert-leader or resync-leader can trigger a crash on the broker receiving configuration.

During periods of network instability, redundancy can go operationally down on a high-availability (HA) redundancy group until the inactive software broker is restarted.

When using distributed tracing, the broker may restart when processing messages if the trace data aligns to a specific internal buffer boundary.

The broker generates excessive debug logs with stack traces when processing valid AMQP messages with empty properties.

Transactions may fail with "endpoint quota exceeded" errors when the replay-log exceeds its configured quota, though the error message does not clearly indicate the failure is due to replay-log quota limits.

AMQP clients with multiple sender links may experience links becoming blocked with no available credits when messages are published on different links in close succession while the broker is under high load.

In Broker Manager, queue names with two hierarchy levels starting with #mqtt/ (such as #mqtt/example) can be created but cannot be deleted or modified through the user interface.
Workaround: Use SEMP or CLI to delete or modify these queues.

On appliances, if an HBA Fibre Channel link goes down while messages are being spooled to disk, the appliance may be unable to automatically fail over to the remaining operational HBA link due to a Linux Kernel thread becoming blocked. When this condition is detected, the broker initiates an automatic reboot to restore normal operation.

Messages with time-to-live (TTL) configured may remain on queues after expiration in rare cases when messages using varying TTLs are published in specific patterns.

When using Distributed Tracing with context propagation, AMQP consumers using strict type checking may fail to consume messages that include trace context information, such as traceparent and tracestate fields, causing connections to close and affected messages to be rejected.

The broker may restart when processing AMQP XOAUTH2 authentication requests that contain unexpected line feed (LF) characters in the authentication header.

The Integrated Kafka Bridge failed to authenticate using SCRAM authentication when connecting to Kafka broker versions 4.x and above.

The broker is exposed to https://github.com/confluentinc/librdkafka/issues/4789 which may trigger a restart when a Kafka Receiver connects to an external Kafka cluster and attempts to use OffsetFetch.

In environments with Disaster Recovery (DR) and Dynamic Message Routing (DMR), in very rare cases, removing an external DMR link on a node that has a DR mate resets the channel IDs, which could potentially disrupt message flow between cluster nodes and cause message loss.

A High Availability (HA) failover may leak shared subscription identifiers on the previously Active broker, causing the current Active broker to reach its shared subscriptions limit and preventing the creation of new shared subscriptions despite available capacity.

In rare cases, redundancy may remain operationally down after the broker recovers from an unexpected restart in Kubernetes environments.

In Dynamic Message Routing (DMR) networks, there may be a delay of up to 60 seconds when a node learns subscriptions from a remote gateway node through another node connected by an internal link.

Assured Delivery Blade (ADB) keys are not included when backing up the ADB configuration of a High-Availability (HA) pair of Appliances, causing the Backup Appliance to enter an AD-NotReady state upon configuration restore.

Appliances may become overloaded and unresponsive when ECC single-bit hardware error correction events occur at a high rate, preventing clients from connecting and causing message delivery delays.

When using OAuth JWT authentication for REST delivery points, memory usage may gradually increase over time due to a memory leak that occurs during authentication attempts. This may lead to an unexpected broker restart if the broker has exhausted its memory.

To check whether your broker is using OAuth JWT authentication for RDPs, execute the show command: ‘show message-vpn rest rest-consumer authentication’. In the output, look for rest-consumers with ‘authentication scheme’ set to 'oauth-jwt'. If any rest-consumers are configured with oauth-jwt, then the broker is exposed to this issue.

A REST Delivery Point (RDP) may attempt to process undeliverable messages indefinitely, which under high load can lead to unexpected broker restarts.

In rare cases, the AD-Active broker in a High Availability (HA) triplet of software event brokers may become unresponsive and restart due to a race condition triggered when the HA mate link connection is lost during message spool synchronization. In some cases when this occurs the HA brokers may not continue to provide service. This issue exists in versions 10.9.1.235+, 10.10.1.189+, 10.11.1.194+, 10.12.0.144, and all versions of 10.25.0. Solace strongly recommends upgrading affected brokers.

Storage Area Network (SAN) storage paths may not automatically recover after restarting IBM 2145 SAN controllers.

The broker may restart when MQTT clients using client certificate authentication connect during management operations that require exclusive access, such as configuration backups.

In rare situations, redundancy can be reported as down due to “Messaging nodes priority not in range” on the monitoring node of a redundancy group of software brokers when the AD-Active broker reports an invalid VRRP Priority.

Workaround: Execute “redundancy release-activity” followed by “no redundancy release-activity” on the AD-Active broker to force a VRRP priority update.

Rapidly changing a partitioned queue to be non-partitioned, by setting its partition count to zero or by changing its access type to exclusive, and then back to partitioned before the partition scaling process completes can cause error logs and prevent consumers from binding to partitions.

A REST Delivery Point (RDP) reports a FAILED outcome, instead of the appropriate REJECTED outcome, when a Solace broker limitation prevents it from converting a message to an HTTP request and where a retry is certain to encounter the same limitation.

In environments with Disaster Recovery (DR) and Dynamic Message Routing (DMR), restarting a node may initially send incomplete link state information, causing topology inconsistencies that can briefly affect message routing.

The broker may restart during a High Availability (HA) failover if it occurs while the partition count is changed on a partitioned queue that is also processing active message traffic, and experiencing normal client connections and disconnections.

In environments with Disaster Recovery (DR) and Dynamic Message Routing (DMR), configuring DMR links and enabling DMR at the Message VPN level in an incorrect sequence can cause message loss after a reboot when one or more Message VPNs are disabled for DR. It is recommended to follow the appropriate DR configuration procedure for DMR networks.

In rare cases, due a race condition, an external DMR link may take a long time (>60s) to become operational when the affected broker is also processing updates from other external links.

In some cases, due to a race condition, TLS clients with valid certificates may receive an "Untrusted Certificate" error if a previous connection attempt from another client used an invalid certificate.

MQTT clients using SSL are incorrectly rejected from connecting to the broker if the SMF SSL service is administratively shutdown.

In PubSub+ Manager, when filtering objects with long names that are truncated in the display, hovering over the object names shows an incorrect preview text.

Solace Broker Manager may become unresponsive and CPU usage may spike significantly when viewing queues in message VPNs that contain a large number of partitioned queues.

When using transactions with replication with “sync” transaction-replication-mode, transactions may be leaked on the replication standby site if a transaction fails to commit.

Once in bash, run the CLI or gather-diagnostics as usual.

SEMPv2 paging of MQTT sessions returns a 400 Not Found response when a non-durable MQTT client is connected to the broker.

Under extremely rare conditions, the event broker may restart when processing a high rate of guaranteed messages.

When a DMR gateway node with both internal and external links is restarted, it may cause its internal neighbors to quickly withdraw and re-apply their DMR subscriptions. While this occurs, messages destined for those subscriptions will not be delivered. This issue can only occur if the DMR gateway node is operating as a non-redundant node, that is, if configured as a standalone broker, or if it is a member of an HA pair, but redundancy is operationally down.

When using transacted replication, messages with message-priorities, and with transactions, messages may not be replication-acked to the DR-standby site.

The broker may restart while processing an MQTT client login request that uses client certificate authentication if it cannot parse the attached certificate.

The Dynamic Message Routing (DMR) Wizard in the PubSub+ Manager may fail with the error "503 Service Temporarily Unavailable" when configuring a DMR cluster. This occurs when the wizard sends proxy requests faster than the configured rate limit allows.

The broker may experience degraded performance when committing transactions that published messages to Last Value Queues (LVQs). This issue is more likely to occur with larger transaction sizes.

A mixed-version DMR mesh containing broker versions of both 10.10.1 (or lower) and 10.11.1 (or higher) may fail to handle network subscription updates from the DMR mesh. When this occurs, messages destined for those subscriptions will not be delivered. This issue can only occur if the DMR mesh contains an external DMR link with a DMR bridge that connects Message VPNs with different names and if the mesh presently has or in the past had at least one broker running version 10.8.1.209 or lower.

The replication group message IDs of spooled messages are reset during SolOS upgrades from pre-10.4.0 to 10.4.0 or later, and from pre-10.8.1 to 10.8.1 or later. Messages spooled before the upgrade cannot be replayed with replay-from-id using their original replication group message IDs after the upgrade completes.

The broker may restart when delivering messages with corrupted binary metadata to REST consumers.

The broker may restart when processing an invalid client certificate.

Running assert-leader from an AD-Standby broker, which is not a recommended operation, may cause Dynamic Message Routing (DMR) to be temporarily disabled and re-enabled on the active broker.

The NAB Pool 5 buffer load and the aggregate NAB Buffer Load Factor may be reported incorrectly in the “show memory” command and SYSTEM_NAB_BUFFER_LOAD_FACTOR_HIGH event logs, potentially showing a lower load than is actually present.

In environments with Disaster Recovery (DR) and Dynamic Message Routing (DMR), messages may be lost when removing a DMR Gateway node that also serves as a DR mate.

In environments with Disaster Recovery (DR) and Dynamic Message Routing (DMR), messages may be lost when removing a DMR link to a node that also served as a DR standby.

The broker may reboot when evaluating a selector against a message with corrupted binary metadata.

AMQP message IDs and correlation IDs in UUID format may become corrupted when processed by the broker.

For appliances only, the support user directory /usr/sw/support may have incorrect ownership permissions, preventing the support user from creating files in their home directory during system operations.

Config-sync connections for replication between appliances use TLS 1.2 even if both appliances support TLS 1.3.

The RPC bind service (rpcbind) becomes active upon upgrade from SolOS 9.11.0.13 to SolOS 10.0.1.186 or later, and remains active in subsequent upgrades. This service is not required for normal broker operation and may be flagged by security scanners as a potential vulnerability.

The broker may incorrectly report that the maximum router selectors limit has been exceeded when binding consumers with selectors to queues.

To provide better compatibility between Software Event Brokers and Event Broker Appliances, some system limits have been increased on SW Brokers with Max-Connections = 200K. Number of configured usernames: 5,000 Number of Authorization Groups: 9,000 Number of client profiles: 10,507 Number of ACL profiles: 10,000 Number of ACL publish and subscribe topic exceptions (combined): 500,000 Number of topic subscriptions that can be assigned to a queue: 500,000 Number of transacted sessions: 100,000 Number of transactions (local and XA combined): 100,000 Number of selectors: 100,000 Number of Connection Factory objects: 5,000 See the Limits-and-Alerts for details.

The SYSTEM_ROUTING_SUBSCRIPTIONS_LOAD_FACTOR_HIGH event now identifies the contributing resource when the threshold is breached.

The maximum length of a group name extracted from the groups claim of an OAuth token has been increased from 64 bytes to 256 bytes.

The Solace Event Broker Software no longer supports running with a container user ID of zero if the container does not have the chroot capability. If the container was created this way after upgrade, ssh to the CLI would not work. To restore ssh access, the container must be recreated with the chroot capability enabled.

The SEMP version strings have changed structure in this release.

SEMP used to have a version string that looked like:
• 2.A where A was an integer.

It will now have versions like:
• A.B.C.D, where A, B, C and D are integers.

We continue to provide wireline compatibility with existing SEMP clients. This does not impact the “base path” of the HTTP requests. It will remain as SEMP/v2. The v2 in the path no longer represents the “MAJOR” version of the API itself, it is just part of the URL.

The respective values of A, B, C and D will be synchronized across Legacy SEMP, SEMP and the main broker release version string. That means that versions that used to look like 2.54 may now look like 10.25.21.6000.

The SEMPv2 Swagger Spec files will no longer contain the version in which attributes or other objects were deprecated. In the past, the spec file would contain wording like “Deprecated since 2.12.” It now just says “Deprecated.” This change does not impact the wireline protocol.

When using the Solace Manager Wizards, with multiple brokers, if the brokers have different versions where 1 versions is >= 10.25.21 and the other version is < 10.25.21, the wizard must be initiated from the newer broker. Initiating the wizard from the older broker may produce Javascript failures but should not adversely impact the broker operation beyond the failure of the wizard itself.

Software Brokers no longer use the Disk Key. The outputs of “show message-spool detail” and “show redundancy detail” will display the Disk Key for both Primary and Backup brokers as “Unknown”. Appliance behavior is unchanged.

In response to SEMP requests where the Event Broker is unable to authenticate the requestor, the broker will return a www-authenticate header containing a list of currently enabled authentication methods (basic and/or bearer). Previous broker releases returned only the method used by the failed request.

The SYSTEM_AD_MAX_MSG_CACHE_USAGE* system events are no longer raised as the conditions they monitored are expected behaviour during normal message broker operation and were not useful for troubleshooting or alerting.

The command 'configure/snmp-server/trap/voltage' (and its sub-command ‘shutdown’) has been deprecated and will be removed in a future version of the Appliance Event Broker.   There is no replacement for this command.  The last version which is guaranteed to support this command is 10.27.0. Use of this command during the deprecation period will not impact the behavior of the broker.  This change only impacts the Appliance.  Support for voltage traps and baseboard voltage values has been removed from the output of the CLI command 'show environment' and from SNMP entirely.

Upgrades for appliances now include pre-upgrade checks to verify the flashboot boot device is functioning properly. Upgrades will be blocked if device issues are detected, preventing potential system failures.

The appliance event broker responds to load balancer HTTP health check GET request on “/health-check/direct-active” with a 200 OK response on the static IP address of redundant appliance brokers, even when clients cannot connect to the static IP due to redundancy being enabled.

Within the Broker Manager, the Queue Name column in the Queues list table is now resizable, providing better visibility and usability when working with long queue names.

The Legacy SEMP version strings have changed structure in release 10.25.4.

Previously, legacy SEMP versions used the format:
• For the Appliance: soltr/A_B_C, where A, B, and C were integers.
• For Software Brokers: soltr/A_B_CVMR, where A, B, and C were integers.

Starting in release 10.25.4, legacy SEMP versions use the format:
• For the Appliance: app/A.B.C.D, where A, B, C and D are integers.
• For Software Brokers: broker/A.B.C.D, where A, B, C and D are integers.

We continue to provide wireline compatibility with existing Legacy SEMP clients. Specifying older style versions in requests will continue to work, but as is standard in Legacy SEMP, the reply will always use the most recent schema, and thus the current version as well. The respective values of A, B, C and D will match the broker release version string.



Legacy SEMP client version specification is now deprecated. Legacy SEMP clients were required to specify versions in requests to access deprecated commands, or to avoid future command deprecations. This is no longer needed. Legacy SEMP requests that include deprecated commands will succeed regardless of what version they specify, or if they specify a version at all. The broker will permit but ignore any versions that Legacy SEMP clients transmit. This change in broker behaviour should not impact any Legacy SEMP clients. Requests that worked in the past will continue to work. Some requests that used to fail, may now succeed.

Event broker appliances will now raise the SYSTEM_SERVER_NTP_DOWN event only when all the enabled NTP sources are unreachable.
Conversely, the SYSTEM_SERVER_NTP_UP event will be raised after one of the enabled NTP sources becomes reachable.

In addition, the SYSTEM_SERVER_NTP_DOWN and SYSTEM_SERVER_NTP_UP event texts will no longer include an NTP server name or IP address; the text associated with the SYSTEM_SERVER_NTP_DOWN event will instead be "NTP server list is operationally down" and the text associated with the corresponding SYSTEM_SERVER_NTP_UP event will be "NTP server list is operationally up".

Ssh AllowAgentForwarding and X11Forwarding have been disabled on the Event Broker. This change was made to ensure that the broker is not susceptible to CVE-2025-32728 (https://access.redhat.com/security/cve/cve-2025-32728).

The PubSub+ Software Event Broker erroneously allows more user-created message-VPNs than are officially supported within the broker. This applies to all editions (Enterprise, Standard, and Evaluation). In a future release, this limit will be strictly enforced.

The PubSub+ Software Event Broker needs larger TCP rmem/wmem settings to support multi-node routing neighbors across high RTT WAN links. Original bug: Bug 63008

If the backup appliance in an active-active HA configuration is restarted while the message spool is disabled, re-enabling the message-spool will fail if one or more replay logs exist in the setup. This issue applies to Solace PubSub+ appliances only. Workaround: Set the active-standby redundancy role of the backup appliance to ‘backup’ prior to the restart. After the restart, set the active-standby role back to ‘none’.

SolOS will fail to start up if an invalid SSL certificate is configured via config-keys.