1. Release Notes Supplement for 7.7.0.1

RTI® Connext® 7.7.0.1 is based on release 7.7.0.

This document supplements the documentation provided with 7.7.0, which you can find in your installation directory, in <NDDSHOME>/doc/manuals, or on the RTI Community Portal.

This document describes changes in 7.7.0.1, for all RTI products that have been updated.

1.1. Released Products/Platforms

Please see the RTI Customer Portal (https://support.rti.com) for a list of available platforms and add-on products for this patch. On the Downloads page, search for 7.7.0.1 releases to see the 7.7.0.1 packages. (See RTI Connext Professional Patches: FAQ and Use Guidelines if you want more information on RTI’s patch process.)

If you want products or platforms that are not in the portal, contact support@rti.com.

Note

Not all products included in a release are available on all platforms. See the Core Libraries Platform Notes in your patch release documentation for supported products by platform.

Unless stated otherwise in the Core Libraries Platform Notes, this release of the Security Plugins supports OpenSSL 3.5.7.

1.2. What’s New in 7.7.0.1

1.2.1. New platforms

This release adds support for the following platform(s):

Table 1.1 New Platform(s)
OS	CPU	Compiler	RTI Architecture Abbreviation
Windows 11	x64	gcc 15.2.0	x64Win64MinGW13gcc15
Android 16	ARM64	clang 21.0.0 (ndk r29)	arm64Android16clang21.0.0ndkr29

For details on using these platforms, see the updated Core Libraries Platform Notes provided with this release.

1.2.2. Performance and Scalability

1.2.2.1. Performance improvement in write() operation when exceeding DataWriter resource limits

This release may significantly improve CPU usage and latency of the write() operation when a DataWriter exceeds certain resource limits.

The improvement applies when any of the following limits are reached:

resource_limits.max_samples
resource_limits.max_samples_per_instance
writer_resource_limits.max_batches

This improvement is more noticeable when these resource limits are configured with large values and in networks where acknowledgments (ACKs) are slow, or when there are DataReaders configured to use NACK-only reliability mode (disable_positive_acks).

1.2.2.2. Improved Persistence Service replication performance with large databases

When a Persistence Service DataReader is re-created with a new synchronization filter, such as after a failover, a matching remote provider no longer scans all samples to respond to the filter change. Instead, it uses in-memory and on-disk database indexes to find the first undelivered sample.

This significantly reduces the cost of re-creating a Persistence Service DataReader in common scenarios, such as when a new application DataWriter matches a Persistence Service replica.

1.2.3. Reliability Protocol and Wire Representation

1.2.3.1. Reduce sample loss on best-effort DataReaders without overhead of Reliability protocol

Best-effort DataReaders can now optionally accept out-of-order samples instead of dropping them. A new out_of_order_delivery_kind DataReaderQos policy controls this behavior with three modes: NO_OUT_OF_ORDER_DELIVERY (default, existing behavior), NO_OUT_OF_ORDER_DELIVERY_PER_INSTANCE (filters only within a single instance), and ALLOW_OUT_OF_ORDER_DELIVERY (no filtering, all samples are delivered regardless of arrival order).

This feature is particularly useful on modern Linux systems where kernel-level parallelism causes frequent UDP packet reordering, or when topics carry a mix of large fragmented and small non-fragmented samples. Previously these scenarios caused unexpectedly high sample loss for best-effort communication. This feature now allows best-effort DataReaders to deliver all received samples, without the additional overhead of the reliability protocol.

See information about the out_of_order_delivery_kind field in RELIABILITY QosPolicy in the Core Libraries User’s Manual in your installation.

1.2.4. APIs

1.2.4.1. New Lifespan configuration prevents delivery of expired samples

Consider the following scenario:

A DataWriter and a DataReader are communicating.
The network is disconnected, but the DataWriter keeps sending samples.
After some time (more than the DataWriter’s lifespan.duration), the network is reconnected.
The DataWriter sends repair samples, which are already expired.
The DataReader receives the samples.

Previously, Connext always calculated the expiration time using the reception timestamp, so the expired samples were always delivered to the application. In this release, this behavior is now configurable as follows:

The LifespanQosPolicy has been added to the DataReaderQos. The duration field has no effect on the DataReader.
A boolean called use_source_timestamp has been added to the LifespanQosPolicy.
- If set to true, Connext calculates the expiration time using either the DataReader’s source timestamp or the DataWriter’s source timestamp.
- If set to false (the default), Connext maintains the previous releases’ behavior; it calculates the expiration time using either the reception timestamp or the time when the sample was added to the DataWriter’s cache.

Now, if you set use_source_timestamp to true on the DataReader, the expired samples will not be delivered to the application; they will be dropped and counted towards the expired_dropped_sample_count.

As another benefit, this configuration makes Connext more compliant with the DDS Specification, which says, “The ‘expiration time’ of each sample is computed by adding the duration specified by the LIFESPAN QoS to the source timestamp. This QoS relies on the sender and receiving applications having their clocks sufficiently synchronized. If this is not the case and the Service can detect it, the DataReader is allowed to use the reception timestamp instead of the source timestamp in its computation of the ‘expiration time.’”

See LIFESPAN QoS Policy in the RTI Connext Core Libraries User’s Manual for more information.

1.2.4.2. Ship rtimonitoring2 library with Python wheel

The rtimonitoring2 native library is now included in the Python wheel. Python users can now use Monitoring Library 2.0 without requiring a separate Connext installation.

1.2.4.3. Easier to adopt Connext in modern Java environments that rely on the Java module path

The release JARs distributed in ${NDDSHOME}/lib/java now include JPMS (Java Platform Module System) module descriptors, allowing them to be placed on the Java module path:

nddsjava.jar — module nddsjava
rticonnextmsg.jar — module rticonnextmsg
rtiroutingservice.jar — module rtiroutingservice
rtirsadapter.jar — module rtirsadapter
distlogdatamodel.jar — module distlog (see note below)

This change makes Connext easier to adopt in modern Java environments by supporting standard JPMS/module-path workflows.

The debug JARs (e.g., nddsjavad.jar) do not include module descriptors, because both release and debug JARs are installed in the same directory, and JPMS disallows two JARs with the same module name on the module path. Debug JARs continue to work on the classpath as before.

Both release and debug JARs remain capable of loading the release or debug native libraries via the com.rti.debug Java property.

Distributed Logger JAR consolidation: distlog.jar has been merged into distlogdatamodel.jar. Customers who previously added both JARs to their classpath should now include only distlogdatamodel.jar.

1.2.5. Usability

1.2.5.1. Improved Remote Debugging performance with Admin Console under certain DDS loads

Under certain high-metric-only event generation conditions (deadline missed, liveliness loss, etc.), the Collector Service WebSocket adapter queued large amounts of unnecessary metric-only events for processing. Remote Debugging does not require metric data, so these events potentially delayed processing the non-metric observables required for Remote Debugging. These metric-only events are now filtered out and not inserted into the processing queues.

1.2.5.2. Faster application detection in Admin Console during remote debugging increases overall operational efficiency

The remote debugging feature in Admin Console now features optimized application detection. To support debugging, Collector Service must subscribe to observables on each newly discovered application. This subscription process has been streamlined to prevent the detection delays previously experienced when launching multiple applications simultaneously.

1.2.5.3. Simplified configuration of security artifacts

You can now configure a single root directory containing your security artifacts and let the Security Plugins automatically derive the locations of the remaining security files from a well-known directory layout.

Instead of individually configuring the paths to the identity certificate, private key, permissions document, governance document, Certificate Authorities (CAs), Certificate Revocation List (CRL), and pre-shared key files, you can now set the dds.participant.trust_plugins.artifacts.path property. The Security Plugins automatically locate the required artifacts based on the DomainParticipant’s domain, participant role, and deployment name.

For applications using the Builtin Security Plugins, you can also configure the dds.participant.trust_plugins.artifacts.deployment_name property to identify the deployment unit whose credentials should be loaded. On Linux, macOS, and Windows systems, this property can be omitted when the artifacts directory contains a single deployment subdirectory, allowing the deployment name to be detected automatically.

This feature simplifies deployment by allowing the same DDS configuration to be reused across multiple deployments. Each deployment only needs to provide its own security artifacts using the standard directory layout, eliminating the need to customize individual security file paths for every deployed instance.

For more information, see Simplified Artifacts Configuration and Security Plugins Global Properties in the RTI Security Plugins User’s Manual.

1.2.6. Dynamic Data

1.2.6.1. Purge global type resources stored in type code factory to reduce memory usage in applications that need it

Connext caches global type resources in the TypeCodeFactory to improve performance by avoiding the cost of recreating type information. For most applications, this cache remains bounded because they use a fixed set of data types or recycle the participant.

If your application dynamically registers and unregisters an unbounded number of types, you can purge these resources once they are no longer needed and the type is unregistered from a given participant. To enable this behavior, set the cleanup_global_type_resources field to DDS_BOOLEAN_TRUE within the DDS_SystemResourceLimitsQosPolicy of the DomainParticipantFactoryQoS.

See SYSTEM_RESOURCE_LIMITS QoS Policy (DDS Extension) in the RTI Connext Core Libraries User’s Manual for more information.

1.2.7. Logging

1.2.7.1. Support for logging remote context in Security Events

The Security Plugins can now include information about the remote entity that triggered a Security Event when the event is caused by the reception of an RTPS message.

When enabled, the logged event includes the remote DomainParticipant GUID, IP address, and port in the remote_guid, remote_ip, and remote_port structured-data fields. This information is available both when Security Events are logged through the Connext Builtin Logging System and when they are distributed over DDS using the Security Logging Builtin Topic (when the SECURITY_TOPIC flag is enabled in logging.mode_mask).

This additional context makes it easier to correlate Security Events with the remote participant responsible for the triggering message, simplifying troubleshooting, security investigations, and event analysis.

Support for this feature is controlled by the new dds.participant.trust_plugins.enable_remote_context property. By default, remote context is enabled for DomainParticipants using the Builtin Security Plugins and disabled for DomainParticipants using the Lightweight Builtin Security Plugins. You can explicitly enable or disable the feature for individual DomainParticipants as needed.

For more information, see Security Events and Logging and Security Plugins Global Properties in the RTI Security Plugins User’s Manual.

1.2.8. Other

1.2.8.1. New standalone Collector Service Lite executable simplifies observability deployments

This Connext Professional release introduces Collector Service Lite, a lightweight version of Collector Service designed for deployments that only require telemetry data forwarding. Unlike the full Collector Service, Collector Service Lite does not include observability backend integrations such as Prometheus, Loki, or OpenTelemetry, allowing it to run natively on all Connext Professional host platforms. This new executable supports the following subset of core Collector Service features:

Telemetry data forwarding: Streamlined forwarding of system telemetry data
Remote Debugging: Full support for Remote Debugging capabilities within Admin Console

The Collector Service Lite executable runs natively on all Connext Professional host platforms. For a complete list of supported platforms, see the Platform Notes in your release installation.

A Collector Service Lite Docker image is also available for Linux AMD64 and ARMv8.

For information, see Collector Service in the Observability Framework User’s Manual.

1.2.8.2. Support for new observable DataReaderQos LifespanQosPolicy in Collector Service

Collector Service has been updated to observe and support the newly introduced LifespanQosPolicy within the DataReaderQos.

In this release, Connext added the LifespanQosPolicy to DataReaderQos to give applications greater control over sample expiration and improve compliance with the DDS Specification. Specifically, the policy introduces a use_source_timestamp boolean:

Source Timestamp Expiration (true): The DataReader calculates the expiration time using the source timestamp. This ensures that stale repair samples—such as those received after a network reconnection that exceeded the lifespan duration—are dropped and counted towards expired_dropped_sample_count rather than delivered to the application.
Reception Timestamp Expiration (false): The DataReader defaults to legacy behavior, calculating expiration based on the reception timestamp or cache arrival time.

To maintain complete observability and alignment with the Core Libraries, Collector Service now fully recognizes this policy. When monitoring Connext applications, Collector Service will accurately capture, report, and display the LifespanQosPolicy configuration of discovered DataReaders, ensuring comprehensive visibility into sample expiration settings across your distributed system.

1.2.8.3. New Collector Service location tag identifies the source of monitor data in large deployments

This release introduces the ability to add a location tag to Collector Service instances. The location_tag is added as a label to all entity presence metrics and as a field to each log message. This new tag enables filtering and sorting observable data by location. The ability to group observable data by location helps to clarify system status to a specific location, which is critical in large systems with multiple Collector Service instances or cloud deployments.

See information about the -locationTag in Passing command-line arguments in the Observability Framework User’s Manual.

1.2.8.4. Reduced CPU and memory utilization for Collector Service or Collector Service Lite when using builtin “Forwarder” profiles

Collector Service includes a set of builtin configuration profiles for various use cases. When a Collector Service or Collector Service Lite instance is configured as a dedicated forwarder, internal processing is now disabled to reduce CPU and memory utilization.

When using a “Forwarder” builtin profile (e.g., NonSecureForwarderWANtoWAN), internal processing and storage are now bypassed. Instead, monitoring data and log samples are simply forwarded on to an upstream Collector Service or Collector Service Lite instance.

When using any other builtin profile, the behavior remains the same; all monitoring data and log samples are processed, and the last value of each metric and observable is cached internally.

See Builtin configuration profiles in the Observability Framework User’s Manual.

1.2.8.5. DDS Spy option for printing product version and entity security information for easier diagnostics

This release introduces an improvement for DDS Spy (rtiddsspy) that logs the DomainParticipant product version as part of the logged new or updated participant information. This capability enhances entity observability, making it easier to analyze and troubleshoot your applications.

Additionally, this release introduces a new command-line option, -showEntitySecurity, for DDS Spy that allows you to inspect the security information of every discovered DomainParticipant, DataWriter, and DataReader. Being able to inspect propagated security information values helps identify incompatibilities that prevent communication.

For example:

17:29:48 New participant    from 172.17.72.147  : guid="0xDFCD91E1,0x6868FBA5,0x9F7B55D6:0x000001C1" name="RTI DDS Spy" partition="*," hostName="RTI-11859" processId="3075" productVersion="7.7.0.0"
security="
{
  "trustInfo": {
    "protection": {
      "bitmask": 2147483655,
      "pluginBitmask": 2147483654
    },
    "algorithm": {
      "signature": {
        "trustChain": {
          "supportedMask": 15,
          "requiredMask": 4
        },
        "messageAuth": {
          "supportedMask": 15,
          "requiredMask": 4
        }
      },
      "keyEstablishment": {
        "sharedSecret": {
          "supportedMask": 7,
          "requiredMask": 2
        }
      },
      "interceptor": {
        "supportedMask": 3,
        "builtinEndpointsRequiredMask": 2,
        "builtinKxEndpointsRequiredMask": 2,
        "userEndpointsDefaultRequiredMask": 2
      }
    }
  }
}
"

See Usage in the RTI DDS Spy User’s Manual for more information.

1.2.8.6. DDS Spy prints Service QoS information for easier diagnostics

This release introduces an improvement to DDS Spy (rtiddsspy) that logs the Service QoS information for every discovered DomainParticipant, DataWriter, and DataReader when showEntityQos is enabled. Being able to inspect propagated Service QoS values helps better identify the discovered application.

For example:

08:56:32 New participant    from 172.17.72.147  : guid="0x01014899,0x59B4C57E,0xFFBDDFE2:0x000001C1" name="RTI Routing Service: default.DefaultDomainRoute#domain1" hostName="RTI-11859" processId="10530" productVersion="7.7.0.0"
qos="
{
  "service": {
    "kind": "ROUTING_SERVICE_QOS"
  }
}
"

See Usage in the RTI DDS Spy User’s Manual for more information.

1.2.8.7. Better concurrency across multiple receive threads on Linux

This release improves how Connext handles concurrent access from multiple receive threads on Linux platforms, reducing thread contention and improving throughput in applications with many receive threads processing data concurrently.

1.2.8.8. Simplified patch installation

Starting in release 7.7.0.1, the patch installation process has been simplified. You no longer need to re-install the base release (e.g., 7.7.0) before installing the patch. RTI now provides a .run or .exe installer for the patch host that you can install directly into a new directory, after which you can install the patch target. Because of this change, a special backup of libraries and of RTI Tools no longer occurs nor needs to occur. The Upgrading to a Patch Release instructions in the RTI Connext Installation Guide have been updated in this release to reflect the new installation process. The previous installation instructions still work for customers who need to install the patch host as a .rtipkg file, rather than a .run or .exe file, because of hardcoded build pipelines.

1.2.9. Third-party software updates

The following third-party software items have been upgraded in this release:

OpenSSL upgraded to 3.5.7
Expat upgraded to 2.8.2
log4j upgraded to 2.25.4
SQLite3 upgraded to 3.53.0

See the Third-Party Software documentation in <NDDSHOME>/doc/manuals/[connext_dds_professional or connext_dds_secure]/release_notes_3rdparty/ for more information.

1.3. What’s Fixed in 7.7.0.1

[Critical]: System-stopping issue, such as a crash or data loss.
[Major]: Significant issue with no easy workaround.
[Minor]: Issue that usually has a workaround.
[Trivial]: Small issue, such as a typo in a log.

1.3.1. Observability Framework / Remote Debugging

1.3.1.1. [Critical] Monitoring commands may have experienced long delays and been processed in bursts

Monitoring commands may have experienced long, cumulative delays and been processed in bursts when a Collector Service operated in forwarding mode, particularly when multiple applications responded or several commands were issued in quick succession. As a result, discovery information may have been delayed or may not have appeared in Admin Console operating in Remote Debugging mode or in RTI Connext Studio when connected to a Cloud Observability Service.

[RTI Issue ID OCA-513]

1.3.1.2. [Critical] When remote debugging, Admin Console failed to receive data from Collector Service over WebSocket when an application crashed

When using Remote Debugging, if an application crashed or shut down ungracefully while its liveliness lease duration was still active, Admin Console would connect but fail to receive data from the Collector Service.

The system would generate an ILL_FORMED response with a generic "Internal Error Encountered" message.
Repeated connection attempts would continue to fail until the dead application’s lease duration officially expired.

Now, under these same conditions, Admin Console receives an ILL_FORMED response with the error message Command response timeout. Admin Console reports the error and continues to receive data from Collector Service.

[RTI Issue ID OCA-482]

1.3.1.3. [Critical] Collector Service crashed or experienced data corruption during service shutdown

A running Collector Service instance could crash or corrupt data during shutdown. This issue was caused by an improper sequence in the destruction of static C++ objects.

[RTI Issue ID OCA-467]

1.3.1.4. [Major] Delayed WebSocket updates when using Remote Debugging

When using the Remote Debugging feature with a forwarding Collector Service configuration profile, repeatedly stopping and starting the upstream Collector Service could corrupt the subscription status. This corruption caused a 5-second block on each event sample, resulting in delayed WebSocket updates.

The forwarding Collector Service no longer enters this blocked state, eliminating the 5-second per-sample delay and ensuring real-time updates.

[RTI Issue ID OCA-483]

1.3.1.5. [Major] Forwarded commands may have automatically been purged before Collector Service could process them

When an Observability Collector Service in forwarding mode received several commands in a quick succession, some of those commands could be autopurged before they were processed, leading to timeouts and commands partially applied (when they were targeted to different applications). Now the autopurge timeout has been extended to prevent this situation.

[RTI Issue ID OCA-499]

1.3.2. Admin Console

1.3.2.1. [Critical] Possible Admin Console application hang

Admin Console, in rare circumstances, could hang and become unresponsive.

[RTI Issue ID ADMINCONSOLE-1523]

1.3.3. Code Generator

1.3.3.1. [Major] QoS file generated in examples did not apply all the elements

The -example, -create examplefiles, and -update examplefiles command-line options generated a QoS file with an incorrect element definition. Although the generated example continued to work, one of the QoS elements was not applied as intended.

[RTI Issue ID CODEGENII-2376]

1.3.3.2. [Major] Potential NullPointerException at startup while initializing logging

Code Generator potentially threw a NullPointerException during startup.

[RTI Issue ID CODEGENII-2366]

1.3.3.3. [Minor] Generated DomainParticipantFactoryQos profile failed to load

The generated example QoS profile for the DomainParticipantFactoryQos, Domain_Participant_Factory_Qos, used an incorrect attribute to set the profile as the default participant factory profile. When this profile was uncommented, the QoS failed to load.

The attribute has been fixed, and Domain_Participant_Factory_Qos now loads without error as the default QoS profile to use for the DomainParticipantFactory.

[RTI Issue ID CODEGENII-2371]

1.3.4. Core Libraries

1.3.4.1. [Critical] Potential Deadlock When Calling DDS_DomainParticipantFactory::set_qos()

An application could deadlock when calling DDS_DomainParticipantFactory::set_qos(). This issue occurred only when Monitoring Library 2.0 was enabled. Monitoring Library 2.0 is enabled by default in Connext 7.7 applications that link against the Connext shared libraries.

[RTI Issue ID CORE-17011]

1.3.4.2. [Critical] Incorrect locators used on newly created DataWriters or DataReaders after a Locator Reachability event and a DomainParticipant QoS update

The fix for RTI Issue ID CORE-15390 was not complete for a scenario involving a DomainParticipant QoS update. When creating a DataWriter or DataReader, the locators to be used for communication may be inherited from a local DomainParticipant’s knowledge of the remote DomainParticipant. If a DomainParticipant QoS was updated after some locators were marked as unreachable but before creating an endpoint, the DataWriter or DataReader might have attempted to use non-reachable locators.

[RTI Issue ID CORE-16835]

1.3.4.3. [Critical] Potential crash during DomainParticipant initialization in weak memory models

In weak memory models, a Connext application could crash, rarely, during DomainParticipant initialization due to memory reordering.

[RTI Issue ID CORE-16771]

1.3.4.4. [Critical] Potential crash if DDS_DomainParticipant_remove_peer was called while the DNS tracker was enabled

There was a race condition that could cause a Connext application to crash if DDS_DomainParticipant_remove_peer was called while the DNS was enabled.

[RTI Issue ID CORE-16742]

1.3.4.5. [Critical] Crash if a builtin participant was created twice

A crash could happen if a Connext application somehow forced the creation of an already created builtin participant. It only happened in some specific cases.

[RTI Issue ID CORE-16739]

1.3.4.6. [Critical] Using map<string, …> with the Modern C++ Protocol Buffers mapping may have caused crashes

A memory management issue affected Modern C++ when Protocol Buffers mapping was used. This occurred when Protocol Buffers definitions utilized map<string, ...> fields. In some cases, re-growing the type could trigger a double-free condition, resulting in application crashes or unexpected termination.

[RTI Issue ID CORE-16735]

1.3.4.7. [Critical] Shared memory communication failed between containers with isolated PID namespaces

In containerized environments, applications running in separate containers may have failed to communicate over shared memory. This issue occurred when the containers shared the IPC namespace but not the PID namespace.

Under these conditions, Connext incorrectly identified the shared memory semaphore as uninitialized, resulting in a failure to attach to the shared memory segment, preventing communication. When this happened, the application logged several warnings such as:

FAILED TO ATTACH | Semaphore set identifier 0x0 has not been initialized.

Note: Isolating the PID namespace is generally not recommended when using shared memory. If you must use this configuration for architectural reasons, you are strictly required to manually set a unique participant_id for each DomainParticipant to successfully establish communication.

[RTI Issue ID CORE-16716]

1.3.4.8. [Critical] Instance state didn’t work when using custom virtual GUIDs

If you configured virtual GUIDs for your endpoints, you may have seen the following error messages:

ERROR [[...] ASSERT REMOTE DW|LC:Security] PRESParticipant_checkRemoteEndpoint:FAILED TO GET | Remote DP (GUID: [...] KIND: MAIN) record in "remoteParticipantSecurity" table.
ERROR [[...] ASSERT REMOTE DW|LC:Security] PRESPsService_assertRemoteEndpointEx:FAILED TO VALIDATE | Remote DW (GUID: [...]) permissions.
ERROR [[...] ASSERT REMOTE DW] PRESPsService_assertRemoteIscWriter:FAILED TO ASSERT | remote instance state consistency writer (failReason: 'PRES_RETURN_ERROR')
ERROR [[...] ASSERT REMOTE DW] PRESPsService_assertRemoteIscEndpoint:FAILED TO ASSERT | remote instance state writer
ERROR [[...] ASSERT REMOTE DW] PRESPsService_assertRemoteEndpointEx:FAILED TO ASSERT | Remote instance state endpoint

These error messages indicated failures asserting the builtin instance state endpoints. Therefore, the instance state consistency feature did not work as intended; when a DataReader recovered liveliness with a DataWriter, instance state was not recovered until a new sample was received for that instance.

[RTI Issue ID CORE-16715]

1.3.4.9. [Critical] Potential crash due to race condition when cleaning up type lookup requests

When TypeLookup Service is used to propragate TypeInformation (default behavior in Connext 7.7.0 and later), it tracks the state of the requests sent on the TypeLookup Service channel internally. A race condition existed where two threads simultaneously accessed one of these requests, potentially resulting in a runtime crash.

[RTI Issue ID CORE-16691]

1.3.4.10. [Critical] Rare race condition led to a crash in weak memory models

On systems with weak memory architectures, memory reordering could have led to crashes in various Connext components.

[RTI Issue ID CORE-16690]

1.3.4.11. [Critical] Inefficient processing of instance state response samples caused performance degradation

When a DataReader reconnected with a DataWriter it had previously lost liveliness with, Connext had to reconcile the state of instances that may have changed while disconnected. The algorithm used to recover instance state was inefficient and could cause high CPU usage and delays when a large number of instances were involved.

This issue only occurred when the DataReader and DataWriter had reliability.instance_state_consistency set to RECOVER_INSTANCE_STATE_CONSISTENCY.

This issue has been resolved, significantly improving performance when DataReaders reconnect to DataWriters after a disconnection.

[RTI Issue ID CORE-16689]

1.3.4.12. [Critical] Discovery may not have completed when using Tools and Infrastructure Services with TypeLookup Service

In applications using the TypeLookup Service, discovery could fail to complete when a type’s complete TypeObject was resolved as a dependency of another top-level type (rather than directly) and the minimal TypeObject could not be used.

This problem affected Tools and Infrastructure Services (such as Routing Service) because they are configured to only use complete TypeObjects to complete discovery and are not able to use minimal types to complete discovery. In this configuration, there was no fallback path to resolve the type through the minimal TypeObject, so discovery would never complete.

This problem did not affect user applications that did not utilize Infrastructure Services like Routing Service.

[RTI Issue ID CORE-16685]

1.3.4.13. [Critical] Possible double-free with shared TypeCodes during garbage collection

A crash could occur when types with shared members were garbage-collected without being explicitly disposed. The fix ensures proper cleanup ordering to prevent the double-free.

[RTI Issue ID CORE-16589]

1.3.4.14. [Critical] Participant deletion may have taken a long time when using asynchronous Publisher for builtin topics

Deleting a DomainParticipant could have taken a long time (up to 10 seconds) when an asynchronous Publisher was enabled for builtin topics. After the 10-second delay, the operation would complete; however, the finalization process was not clean and could result in segmentation faults.

[RTI Issue ID CORE-16521]

1.3.4.15. [Critical] Locator reachability stopped communication with other DataReaders if one of them was deleted

Consider a DomainParticipant with several DataWriters communicating with as many DataReaders on a different DomainParticipant. If the DomainParticipant was using locator reachability, deleting one of the DataReaders would stop communication with the others. The locator reachability feature wrongly processed the deletion of an endpoint by removing its locators from the locator list (even if they were shared with other endpoints), which led the DomainParticipants to interpret that they cannot reach each other. In the fix for this issue, the deletion of one endpoint no longer affects other endpoints that share the same locator.

[RTI Issue ID CORE-16261]

1.3.4.16. [Critical] Requester or Replier creation may have deadlocked when Monitoring Library 2.0 was enabled

Creating a Requester or Replier while Monitoring Library 2.0 processed application resource information may have caused the application to become unresponsive. This issue affected Request-Reply APIs in all supported languages and was more likely in Connext 7.7, where Monitoring Library 2.0 is enabled by default.

[RTI Issue ID MONITOR-792]

1.3.4.17. [Critical] Late joiner DataReader may not have received all historical samples from durable DataWriters with required subscriptions

A late-joining DataReader may not have received all the historical samples from a DataWriter if all the following was true:

The DataWriter was configured to use durable writer history.
The DataWriter was restarted; it loaded the previous state but had not written a sample of its own.
The DataWriter had required subscriptions configured but had not delivered the samples to any of them yet.
The DataReader resource limits configured max_samples to a value that was smaller than the total of historical samples.

In this case, the DataReader may have stopped receiving historical samples if its queue filled before receiving all of the historical data. The DataReader would not receive any data, even if the samples were taken from the queue, until a new sample was written by the DataWriter. The DataReader now continues receiving historical samples when samples get taken from the queue, as expected.

[RTI Issue ID CORE-16569]

1.3.4.18. [Critical] Locator reachability updates may not have been received by all DomainParticipants

In scenarios where more than two DomainParticipants were using locator reachability, the locator reachability update messages sent through the service request channel may not have been received by all the DomainParticipants if samples were sent to several of them in quick succession. In the fix for this issue, all the DomainParticipants receive the locator reachability updates.

[RTI Issue ID CORE-16398]

1.3.4.19. [Critical] Possible crash or precondition when logger finalized before DomainParticipant created

An application could crash (if using release libraries) or trigger a precondition error (if using debug libraries) when the following occurred: the application used the C or Traditional C++ APIs that installed a custom logger device, finalized the DomainParticipantFactory without having created a DomainParticipant, and then finalized the logger (in C++) or set the logger device to NULL (in C). The logger does not get completely initialized if a DomainParticipant is not created and the DomainParticipantFactory finalizes the logger as part of its finalize method. The described sequence of calls left the logger in an inconsistent state, and further calls to the logger API triggered the issue. Now the logger is properly finalized with the factory and calls to the logger API after that (while not required for cleanup) will not crash.

Note

This fix changes the behavior of the finalize_instance API in traditional C++. That API does not uninstall the logger device anymore. If you were using that API to uninstall the logger device and manually releasing its memory, that will lead to a crash. You have to uninstall the device using set_logger_device, providing NULL as a parameter, or finalize the DomainParticipantFactory before releasing the memory of the logger device object.

[RTI Issue ID CORE-16779]

1.3.4.20. [Critical] ABI incompatibility prevented Modern C++ applications from building with C++20

An Application Binary Interface (ABI) mismatch prevented Modern C++ applications from building successfully with C++20. Specifically, in an internal shared-pointer operation requiring atomic access (present in an implementation header), application code compiled as C++20 used a different data representation than the C++11/14-compiled Connext libraries.

Your application code would expect the C++20 implementation, while the Connext libraries used the pre-C++20 implementation. This structural difference led to incompatibility and potential undefined behavior when the application interacted with the Connext shared libraries.

This issue has been resolved. Connext now consistently uses the pre-C++20 representation, eliminating the ABI mismatch. Please note that C++26 is not supported, since this compatibility fix relies on pre-C++20 atomic shared-pointer APIs that are removed in the C++26 standard.

[RTI Issue ID CORE-17013]

1.3.4.21. [Critical] Potential crash working with Status Conditions

A crash could have happened, especially in weak memory architectures like ARM, when using Status Conditions from different threads: for example, using the DDS_StatusCondition_set_enabled_statuses at the same time that samples were taken or read from an associated DataReader.

[RTI Issue ID CORE-16612]

1.3.4.22. [Major] Floating-point-to-string algorithm used by DDS_DynamicDataFormatter introduced precision errors

The floating-point conversion method used by the DDS_DynamicDataFormatter_to_***() function was showing larger than expected errors (last 1-2 significant digits) when converting doubles.

[RTI Issue ID CORE-16983]

1.3.4.23. [Major] Some samples needing fragmentation could not be sent when using Header Extension

Connext did not properly account for the overhead required per sample when using the Header Extension submessage. This could have led to situations in which samples that needed to be fragmented could not be sent because there was not enough reserved space for the user data in the serialization buffer. Now, the overhead for the Header Extension submessage is properly accounted for.

[RTI Issue ID CORE-13810]

1.3.4.24. [Major] Multicast locators were not correctly identified for custom UDPv4 transports using a non-default network address

When a custom UDPv4 transport was configured with a non-default network address, Connext could fail to recognize a locator as multicast. The check assumed the locator’s leading 12 bytes (the IPv4-mapped prefix) were always zero, which is not true when a non-default network address is used, causing a false negative.

[RTI Issue ID CORE-16443]

1.3.4.25. [Major] Using multicast led to “!goto WR srw remote reader” log messages

Consider the following scenario:

A reliable DataWriter W discovers a reliable DataReader R1.
After initial discovery, W detects that R1 has gained a new multicast locator.
W is communicating with another reliable DataReader on the same multicast locator (R2).
Later, W stops communicating with R1.

At this point, when W sent a message to R2 over multicast, W generated a log message containing the following:

!goto WR srw remote reader

From here, there were two possibilities:

If W was using synchronous publishing, then the log message was a WARNING from the internal function COMMENDSrWriterService_updateWriteStatistics, and there were no other consequences.
If W was using asynchronous publishing, then the log message was an ERROR from the internal function COMMENDSrWriterServiceMatchedStats_updateRemoteReader, and the asynchronous publishing thread would fail to write data for some topics.
- If W happened to be a builtin endpoint discovery DataWriter (configured to use asynchronous publishing via publication_writer_publish_mode or subscription_writer_publish_mode), then endpoint discovery would fail to complete.

This problem has been fixed by removing the underlying condition that led to the log message being printed.

[RTI Issue ID CORE-16185]

1.3.4.26. [Major] LifespanQosPolicy’s behavior was inconsistent with DDS specification and documentation

There were two problems with the LifespanQosPolicy:

The documented behavior was not compliant with the OMG DDS Specification (OMG Data Distribution Service (DDS) standard API, version 1.4), which says, “The ‘expiration time’ of each sample is computed by adding the duration specified by the LIFESPAN QoS to the source timestamp. This QoS relies on the sender and receiving applications having their clocks sufficiently synchronized. If this is not the case and the Service can detect it, the DataReader is allowed to use the reception timestamp instead of the source timestamp in its computation of the ‘expiration time.’” In the specification, using the source timestamp is required and using the reception timestamp is optional. In the documented behavior of previous releases of Connext, using the reception timestamp was required and using the source timestamp was unsupported.
The actual behavior on the DataWriter when using Durable Writer History did not match the documented behavior. The actual behavior used the source timestamp instead of the time when the sample was added to the DataWriter’s cache.

This release fixes both problems by adding a new configuration to the Lifespan QoS policy. For more details, see “New Lifespan configuration prevents delivery of expired samples” in the What’s New section.

[RTI Issue ID CORE-16093]

1.3.4.27. [Major] Inefficient return_loan performance when creating multiple TopicQueries simultaneously

When a TopicQuery is created, a DataReader creates a separate queue for the samples that are sent in response to the TopicQuery. The DataReader::return_loan operation unnecessarily iterated through every TopicQuery queue instead of just the TopicQuery queues of the samples in the sample array that was being returned.

[RTI Issue ID CORE-16578]

1.3.4.28. [Major] Registered DynamicTypes in Modern C++ API were not cleaned up upon unregistration

When a DynamicType was registered in the Modern C++ API, its type support was attached to the participant and remained there until the participant was closed. Now, explicitly calling unregister_type() will properly remove the type support from the participant, freeing memory that would otherwise be retained.

[RTI Issue ID CORE-16566]

1.3.4.29. [Major] Existing DataReaders and DataWriters did not start using multicast after a network interface gained multicast capability

A DataReader’s or DataWriter’s multicast locator was treated as immutable once the entity was enabled. If a DomainParticipant was created before any multicast-capable network interface was available, and a multicast-capable interface came up later, already-enabled DataReaders and DataWriters kept using their original locators and never started communicating over multicast.

In addition, multicast initial peers that were skipped when the DomainParticipant was enabled were never reprocessed later. Then, the required multicast discovery destinations were never created.

[RTI Issue ID CORE-16529]

1.3.4.30. [Major] on_offered_incompatible_qos/on_requested_incompatible_qos was not delivered for endpoints matched with incompatible QoS while type resolution was pending

When a DataWriter and DataReader were using different types, and their QoS was incompatible, the on_offered_incompatible_qos and on_requested_incompatible_qos callbacks may not have been triggered. This issue could only occur in applications using TypeObjectV2 as the type representation (which is the default in Connext 7.7.0 and later).

The incompatible QoS status and listener callbacks are now delivered even while type resolution is still pending.

[RTI Issue ID CORE-16976]

1.3.4.31. [Major] DDS Spy did not report participant QoS updates

DDS Spy (rtiddsspy) did not report updates to discovered DomainParticipants when mutable participant information changed, such as partition changes or source locator updates.

As a result, changes to a DomainParticipant’s mutable QoS policies, including adding or modifying partitions, were not detected or displayed. rtiddsspy now prints an Updated participant message when participant partitions or source locators change, consistent with how endpoint updates are reported.

[RTI Issue ID CORE-16831]

1.3.4.32. [Major] DDS Spy failed to discover DomainParticipants and endpoints with the default (empty) partition

DDS Spy printed “Failed to allocate memory for partitions” errors and failed to discover DomainParticipants and endpoints when their partition QoS included a non-empty sequence containing the default (empty-string) partition.

[RTI Issue ID CORE-16793]

1.3.4.33. [Major] Incomplete fragmented samples may not have been reported via on_sample_lost if fragments were the first received samples from a remote DataWriter and were immediately followed by a GAP

A best-effort DataReader reports samples that are lost via on_sample_lost when a sample is received with a sequence number higher than the last received highest sequence number or when a GAP is received invalidating a range of sequence numbers.

Lost samples were not reported by the DataReader in the following case:

The DataReader received incomplete fragments before receiving any other samples from a remote DataWriter.
The DataReader then received a GAP (before receiving the complete fragmented sample or receiving any other full samples), which invalidated the incomplete fragments from the same remote DataWriter.

This issue has been resolved, and these lost samples will now be reported through on_sample_lost even in this case.

[RTI Issue ID CORE-16722]

1.3.4.34. [Major] Duplicate log delivery occurred when a custom logging output device was installed and DomainParticipantFactory QoS was updated

When a custom logging output device was installed and the DomainParticipantFactory QoS was subsequently updated, log messages were delivered twice—once to the custom output device and once to standard output. Log messages are now delivered exactly once.

[RTI Issue ID CORE-16719]

1.3.4.35. [Major] Error messages and missing Header Extensions when enabling Header Extension

The RTPS Header Extension (HE) provides a standardized way to include additional metadata in an RTPS message, such as:

message length (enabled by setting dds.participant.wire_protocol.enable_message_length_header_extension to true)
timestamp (enabled by setting dds.participant.wire_protocol.enable_timestamp_header_extension to true)
CRC/Checksum (enabled by setting WireProtocolQosPolicy::compute_crc to true)

When any of these features were enabled along with RTPS protection, it was possible to see an error similar to the following in your application:

MIGGeneratorContext_beginHeaderExtension:INSUFFICIENT SPACE FAILURE | Message size. New submessage size: 12. Current message size: 20. Effective maximum message size: 65507.  If this problem persists, consider increasing 'message_size_max'

This error occurred because some state related to previously sent messages was not reset properly. As a result, the Header Extension was no longer present in the RTPS message following this error. Any applications requiring CRC checks could no longer guarantee that every message contained a checksum.

The state for the Header Extension submessage is now correctly reset between RTPS messages, avoiding the error message and the missing Header Extension submessages.

[RTI Issue ID CORE-16625]

1.3.4.36. [Major] Constant (<const>) referencing a qualified enumerator name failed to load from an XML type

Loading an XML type definition failed when a <const> defined a constant of an enumeration type using a qualified enumerator name (for example, value="test::EnumType::EnumType2"). Parsing failed with an error indicating the enumerator name was unknown, and because the constant could not be evaluated, the entire XML file failed to load. This affected XML produced by rtiddsgen -convertToXml as well as hand-written XML, and applied to any component that loads XML types, including XML-Based Application Creation and the RTI Infrastructure Services. The problem occurred whether or not the enumeration was declared inside a module.

The XML parser now resolves a qualified enumerator name in a <const> value, such as Module::Enum::Enumerator.

[RTI Issue ID CORE-14320]

1.3.4.37. [Major] Monitoring Library 2.0 collected periodic metrics when Collector Service was not running

When Monitoring Library 2.0 was enabled, periodic metrics were always collected and published, even when Collector Service was not available to consume them. This issue negatively affected out-of-the-box performance.

[RTI Issue ID MONITOR-776]

1.3.4.38. [Major] DDS_DynamicData::from_string failed parsing a JSON string with unknown members

DDS_DynamicData::from_string failed when parsing a JSON object containing members that were not part of the DynamicData type. For appendable or mutable types, however, unknown members should be ignored, according to the Extensible Types assignability rules.

For example:

@appendable
struct Position2D {
    int32 x;
    int32 y;
};

@appendable
struct Position3D : Position2D {
    int32 z;
};

Previously, calling DDS_DynamicData::from_string on a DynamicData object of type Position2D with a JSON sample for Position3D, such as:

{
    “x”: 100,
    “y”: 200,
    “z”: 300
}

failed because the z member is not part of Position2D.

Now, the unknown z member is correctly ignored, and the DynamicData object is initialized with x equal to 100 and y equal to 200.

[RTI Issue ID CORE-16887]

1.3.4.39. [Minor] Best Effort DataReaders dropped samples that were newer than the last fully reassembled sample when hitting max_fragments_per_remote_writer

Best-effort DataReaders track the highest sequence number of all fully received samples to determine which samples to drop. If a DataReader receives partial fragments of samples 3, 4, and 5 (but not all fragments, so they cannot yet be reassembled) and then receives a full non-fragmented sample 2, the DataReader should still accept sample 2. This was true as long as the DataReader had not hit the fragmented samples resource limits. However, when the DataReader had already reached the max_fragments_per_remote_writer resource limit, it was no longer able to receive older samples. If max_fragments_per_remote_writer were set to 2 with the example above, the DataReader dropped sample 2 (even though it was still higher than the highest fully received sequence number). This has been resolved; the DataReader now correctly accepts sample 2 in this case.

[RTI Issue ID CORE-16775]

1.3.4.40. [Minor] DDS_DataReaderProtocolStatus.dropped_fragment_count incremented twice when a DataReader received a fragmented sample with a sequence number lower than all previously received fragments and it had already received max_fragmented_samples_per_remote_writer

DDS_DataReaderProtocolStatus.dropped_fragment_count tracks the number of fragmented samples that a DataReader receives and drops (due to already receiving the sample or hitting resource limits). It is incremented once for every fragment that is dropped. A DataReader configures the number of fragmented samples it is able to track with max_fragmented_samples_per_remote_writer.

A DataReader would incorrectly increment dropped_fragment_count twice in the following case:

The DataReader had already received max_fragmented_samples_per_remote_writer fragments from a single remote writer (and had not reassembled them).
The DataReader then received another fragmented sample with a sequence number lower than all previously received fragments.

The DataReader will now update dropped_fragment_count only once in this case.

[RTI Issue ID CORE-16773]

1.3.4.41. [Minor] DDS_DataReaderProtocolStatus.last_committed_sample_sequence_number not updated on best-effort DataReaders when using fragmentation

The DDS_DataReaderProtocolStatus.last_committed_sample_sequence_number QoS setting was not updated when the last received sample was a reassembled fragmented sample and the reader was a best-effort DataReader. The last_committed_sample_sequence_number was only updated when receiving a non-fragmented sample. The last_committed_sample_sequence_number setting is now updated for both non-fragmented and fragmented samples (once the fragments are fully reassembled).

[RTI Issue ID CORE-16731]

1.3.4.42. [Minor] Unexpected “get remote reader” warning in DataWriters configured for APPLICATION_ACKNOWLEDGMENT

You may have seen a warning similar to the following on a DataWriter configured with writer_qos.reliability.acknowledgment_kind set to DDS_APPLICATION_AUTO_ACKNOWLEDGMENT_MODE or DDS_APPLICATION_EXPLICIT_ACKNOWLEDGMENT_MODE:

WARNING [0xFD1509BF,0xA0B1D0E9,0x1038CDF2:0x00000000|REMOVE REMOTE DR 0xD2699588,0x10DF3A77,0x36F7DEF1:0x80000307|REMOVE REMOTE DR] WriterHistoryOdbcPlugin_assertAppAck:!get remote reader

This warning could appear when a matching DataReader configured with reader_qos.reliability.acknowledgment_kind set to DDS_PROTOCOL_ACKNOWLEDGMENT_MODE was deleted.

This warning was benign and did not affect system behavior. It has been corrected in this release.

[RTI Issue ID CORE-16672]

1.3.4.43. [Minor] DDS Spy could print endpoint creation before participant creation

When a new DomainParticipant was discovered together with its endpoints (DataWriters or DataReaders), DDS Spy could report the endpoint creation before reporting the DomainParticipant creation. This produced confusing output because it appeared as if endpoints belonged to an unknown participant.

The processing order has been corrected so that participant creations are always reported before their endpoints.

[RTI Issue ID CORE-16662]

1.3.4.44. [Minor] A reliable writer’s FlowController failed to control the data flow over UDPv4 for a SHMEM_REF type

Consider the following scenario:

A DomainParticipant DP1 is using the Zero Copy transfer over shared memory transport. DP1 uses both SHMEM (for communicating within the same machine) and UDPv4 (for communicating with other machines).
DP1 has a reliable DataWriter of a data type annotated with @transfer_mode(SHMEM_REF). This DataWriter uses a FlowController and sets publish_mode.kind to ASYNCHRONOUS_PUBLISH_MODE_QOS.
A DomainParticipant DP2 communicates with DP1 using SHMEM.
A DomainParticipant DP3 communicates with DP1 using UDPv4.

The FlowController settings did not take effect correctly when the DataWriter was sending full samples to DP3. The FlowController controlled the flow as if the DataWriter were sending sample references to DP2. This behavior resulted in the DataWriter sending full samples to DP3 much faster than expected.

[RTI Issue ID CORE-16505]

1.3.4.45. [Minor] DDS_DomainParticipantFactory_set_qos did not correctly apply programmatic logging verbosity when a default XML QoS profile was present

This issue was fixed in release 7.1.0, but not documented at that time.

DDS_DomainParticipantFactory_set_qos now correctly applies the programmatic logging verbosity even when a default <participant_factory_qos> XML profile contains a <logging> tag. Previously, the XML verbosity was always applied last, overriding the programmatic setting.

[RTI Issue ID CORE-11664]

1.3.4.46. [Minor] Updated Optimization.Transport.LargeBuffers QoS snippet to align with higher default socket buffer sizes

The default UDP socket buffer sizes were increased as part of an improvement. Previously, applying the BuiltinQosSnippetLib::Optimization.Transport.LargeBuffers QoS snippet unintentionally lowered send and receive buffer sizes below these new defaults. This issue has been resolved by updating the snippet to reflect the new default socket buffer sizes.

[RTI Issue ID CORE-17003]

1.3.4.47. [Minor] Monitoring Library 2.0 verbosity could not be set above ERROR

This issue was fixed in release 7.7.0, but not documented at that time.

There was no way to configure the Monitoring Library 2.0 verbosity to a level higher than ERROR (the default) using the Logger APIs, such as NDDSConfigLogger::set_verbosity or NDDSConfigLogger::set_verbosity_by_category in traditional C++ (or their equivalents in other languages).

Now, the Monitoring Library 2.0 verbosity can be configured using the NDDS_CONFIG_LOG_CATEGORY_ENTITIES log category.

[RTI Issue ID MONITOR-749]

1.3.4.48. [Trivial] Error logged in PRESPsService_writerActivityListenerOnRemoteReaderActive

The following log message was logged when receiving a message from a remote reader that had been marked as “inactive” (due to inactivate_nonprogressing_readers being set to TRUE and max_heartbeat_retries being exceeded) from a remote participant that had just lost liveliness:

ERROR [0x000002D6,0x000002D6,0x000002D6:0x000004C2{Entity=DW,Domain=0}|LIVELINESS CHANGE] PRESPsService_writerActivityListenerOnRemoteReaderActive:!goto WR pres psRemoteReader

This error message was harmless and could be safely ignored. It has been changed to the REMOTE log level.

[RTI Issue ID CORE-14940]

1.3.4.49. [Trivial] WARNING log messages occurred for conditions that are expected under normal operation

Collector Service inadvertently generated WARNING log messages like the following for conditions that were expected under normal operation:

WARNING RTI_MonitoringPeriodicMetricCollector_collectAndPublish:FAILED TO GET | Metric group with index 57. For resource (GUID: 0x730565AA,0xB535EE5D,0x455D6432:0x2B8CB1E9) WARNING RTI_MonitoringPeriodicMetricCollector_collectAndPublish:FAILED TO GET | Metric group with index 60. For resource (GUID: 0x730565AA,0xB535EE5D,0x455D6432:0x2B8CB1E9) WARNING RTI_MonitoringPeriodicMetricCollector_collectAndPublish:FAILED TO GET | Metric group with index 63. For resource (GUID: 0x730565AA,0xB535EE5D,0x455D6432:0x2B8CB1E9) WARNING RTI_MonitoringPeriodicMetricCollector_collectAndPublish:FAILED TO GET | Metric group with index 66. For resource (GUID: 0x730565AA,0xB535EE5D,0x455D6432:0x2B8CB1E9)

These log messages have been removed.

[RTI Issue ID MONITOR-775]

1.3.5. Persistence Service

1.3.5.1. [Critical] Persistence Service crash when synchronization is enabled

Persistence Service could crash when:

the <enable> tag in <data_synchronization> was set to true,
the service selected a new synchronization provider for a persistence group, and
the service recreated the synchronization DataReader while the read thread was processing data from the previous provider

This race condition could occur regardless of the <single_subscriber> setting.

[RTI Issue ID PERSISTENCE-538]

1.3.5.2. [Critical] Persistence Service could fail to process durable subscriptions if an UNREGISTER durable subscription sample was received before other samples

When using Durable Subscriptions, Persistence Service may have skipped processing of Durable Subscription updates if an UNREGISTER was received before all the samples were processed.

[RTI Issue ID PERSISTENCE-521]

1.3.5.3. [Major] Persistence Service synchronization did not work with default partition configuration

In release 7.7.0, Persistence Service synchronization enabled by setting <data_synchronization>/<enable> to true did not work with the default (empty) partition configuration. As a result, the data was not replicated across different instances of Persistence Service.

[RTI Issue ID PERSISTENCE-530]

1.3.5.4. [Major] High CPU usage when HTTP health check server enabled on Linux systems

On Linux systems, enabling the optional HTTP health check server using the -healthCheckPort option could cause Persistence Service to consume an entire CPU core. This issue could occur after the server ran for several seconds.

[RTI Issue ID PERSISTENCE-542]

1.3.6. Recording Service

1.3.6.1. [Critical] On Windows, fileset rollover could corrupt a segment file when file deletion failed

When using filesets with <overwrite_policy_kind> set to OVERWRITE on Windows systems, Recording Service could fail to delete the oldest file in the set, resulting in a corrupted recording. This issue was typically triggered internally if <rollover><file_size_limit> was set, or externally by another application (such as anti-virus software) locking the file.

[RTI Issue ID RECORD-1586]

1.3.6.2. [Critical] SQLite memory growth in Recording Service’s discovery database file

Recording Service provided no control over the initialization and settings of the Discovery DB file, and this could lead to memory growing out of acceptable, application-dependent bounds.

A new XML configuration setting has been added: discovery_sql_initialization_string. This new setting is akin to the sql_initialization_string used for user-data files.

Apart from this, the default initialization of both user-data files and the discovery file uses the following pragmas: PRAGMA SYNCHRONOUS = OFF; PRAGMA JOURNAL_MODE = MEMORY; PRAGMA cache_size = -2048;. The addition of the cache_size pragma is intended to reduce the size of the cache out-of-the-box.

[RTI Issue ID RECORD-1583]

1.3.6.3. [Critical] Possible crash or corruption in Recording Service when shutting down service

A running Recording Service instance could have crashed or gotten corrupted when shutting down because of how static C++ destruction was handled by the service. This behavior could be more problematic when running the service as a library.

[RTI Issue ID RECORD-1578]

1.3.7. Routing Service

1.3.7.1. [Critical] Memory growth in Routing Service when using builtin reader caches

Routing Service did not auto-purge disposed instances when storing data in the internal builtin reader caches. This problem manifested in services that route discovery data from inputs to outputs, like Recording Service, resulting in a memory growth over time.

[RTI Issue ID ROUTING-1410]

1.3.7.2. [Critical] Data races on architectures with weak memory models

On systems with weak memory architectures, such as Arm® and PowerPC®, data races could have led to undefined behavior or crashes in Routing Service.

[RTI Issue ID ROUTING-1425]

1.3.8. Cloud Discovery Service

1.3.8.1. [Major] Excessive bandwidth usage with Real-Time WAN Transport on Windows

This issue was fixed in release 7.7.0, but not documented at that time.

Cloud Discovery Service may have sent redundant participant announcements to applications using the RTI Real-Time WAN Transport. This issue occurred only on Windows systems and could result in unnecessary bandwidth usage.

[RTI Issue ID CDS-283]

1.3.9. Security Plugins

1.3.9.1. [Critical] Security Plugins incorrectly rejected valid identity chains

This release fixes a bug where the Security Plugins incorrectly rejected identity chains containing certificates signed with different digest algorithms (even if they were allowed by the Governance Document). You would have seen log messages similar to the following:

ERROR [CREATE DP|LC:Discovery,Security] RTI_Security_CertHelper_logIncompatibleDigest:!Found sha256 digest type when sha384 digest type was expected: The Certificate Authority's public key is of type id-ecPublicKey and curve secp384r1
ERROR [CREATE DP|LC:Discovery,Security] RTI_Security_CertHelper_checkCrlAndVerifyCert:!invalid digest type
ERROR [CREATE DP|LC:Discovery,Security] RTI_Security_CertHelper_verifyCertificate:{"[..] {"plugin_class":"RTI:Common"},{"plugin_method":"RTI_Security_CertHelper_verifyCertificate"}]}],"m":"subject name: [...] issuer name: [...]"}}
ERROR [CREATE DP|LC:Discovery,Security] RTI_Security_Authentication_validateCertificateChain:{[...]{"plugin_class":"DDS:Auth:PKI-DH"},{"plugin_method":"RTI_Security_Authentication_validateCertificateChain"}]}],"m":"Identity verification failed. Make sure it was signed by the right authority."}}

Identity chains with mixed digest algorithms are now properly validated.

[RTI Issue ID SEC-3010]

1.3.9.2. [Critical] Memory leak when deleting a DataWriter or DataReader using PersistentStorageSettings

When using the Builtin Security Plugins, there was a memory leak in the internal function DDS_PersistentStorageSettings_fromPresentationQos when deleting a DataWriter or DataReader that used non-NULL string values within DataWriterQos or DataReaderQos durability.storage_settings. Continuously creating and deleting DataWriters or DataReaders with that configuration led to unbounded memory growth.

[RTI Issue ID SEC-2968]

1.3.9.3. [Critical] Segmentation fault when origin authentication was applied to submessages only

Consider the following scenario:

The Governance tag <rtps_protection_kind> was set to a value that did NOT contain WITH_ORIGIN_AUTHENTICATION.
A different Governance tag (for example, <metadata_protection_kind>) was set to a value that did contain WITH_ORIGIN_AUTHENTICATION.
The cryptography.max_receiver_specific_macs property was set to a value other than AUTO.

In this scenario, you may have experienced a segmentation fault in the internal function RTI_Security_Cryptography_serializeReceiverSpecificMacs while sending a message. This problem occurred when the number of destinations of the message exceeded the max_receiver_specific_macs value.

This problem only affected version 7.7.0.

[RTI Issue ID SEC-2955]

1.3.9.4. [Critical] Instance state consistency failed after reconnection in secure systems with key revisions enabled

In secure systems with key revisions enabled, Connext participants may have failed to re-authenticate with each other following a reconnection or rediscovery event, preventing the instance state consistency feature from functioning correctly. This failure occurred because the internal endpoints responsible for synchronization could not rediscover one another, potentially leading to a DataReader’s instance state not being correctly updated—such as missing disposal or unregistration notifications—and resulting in inconsistent data states across the network.

[RTI Issue ID SEC-2951]

1.3.9.5. [Major] Error messages and missing Header Extensions when enabling Header Extension and Submessage Protection

The RTPS Header Extension (HE) provides a standardized way to include additional metadata in an RTPS message, such as:

message length (enabled by setting `dds.participant.wire_protocol.enable_message_length_header_extension` to true)
timestamp (enabled by setting `dds.participant.wire_protocol.enable_timestamp_header_extension` to true)
CRC/Checksum (enabled by setting `WireProtocolQosPolicy::compute_crc` to true)

When any of these features were enabled along with Submessage Protection (e.g., by setting metadata_protection_kind to a value other than NONE in the Governance Document), the application could encounter the following error:

ERROR MIGGeneratorContext_beginHeaderExtension:INSUFFICIENT SPACE FAILURE | Gather send buffers and scratch buffer.
New buffer size: 12. Current scratch buffer size: 0. Maximum scratch buffer size: 65507.
Extra gather buffer count: 0. Current gather buffer index: 1. Maximum gather buffer count: 16.
If this problem persists, consider increasing 'gather_send_buffer_count_max'.

Although the error message suggested increasing gather_send_buffer_count_max, the root cause was not that this value was too small; the root cause was that the internal implementation didn’t correctly keep track of the number of gather send buffers in use. Therefore, increasing gather_send_buffer_count_max may have temporarily alleviated the problem, but now that the problem has been fixed, increasing gather_send_buffer_count_max is no longer necessary.

[RTI Issue ID SEC-2986]

1.3.9.6. [Major] No endpoint discovery when using Lightweight Security and TypeObject v2

When using the Lightweight Builtin Security Plugins combined with TypeObject v2 (the Connext default), endpoint discovery did not complete when type information exchange was required to complete matching. This problem affected scenarios where endpoints use different but assignable types, as well as scenarios where the application explicitly requires type resolution from remote DomainParticipants. Such applications include DynamicData applications, DDS Spy, and Routing Service.

[RTI Issue ID SEC-2962]

1.3.9.7. [Major] Intraparticipant communication failed when origin authentication was applied to messages

If the Governance tag <rtps_protection_kind> was set to a value containing WITH_ORIGIN_AUTHENTICATION, and the cryptography.max_receiver_specific_macs property was set to a value other than AUTO, then the DomainParticipant may have failed to receive messages that were sent from itself. This problem occurred when the message was sent to itself as well as to other DomainParticipants, and the number of destinations of the message exceeded the max_receiver_specific_macs value. The following error message accompanied the reception failure:

RTI_Security_Cryptography_verifyReceiverSpecificMac:OpenSSL function EVP_DecryptFinal_ex (GMAC) failed with error: (error details not available)

This problem only affected version 7.7.0.

[RTI Issue ID SEC-2952]

1.3.10. Monitor

1.3.10.1. [Critical] Possible Monitor application hang

An application hang could have occurred in the Monitor UI, characterized by 100% CPU utilization on a single thread. The issue was triggered by an extremely rare GUID collision.

[RTI Issue ID MONITOR-769]

1.3.10.2. [Minor] Monitor failed to launch if third-party libraries were patched

If a patch contained updated versions of dependent third-party libraries, Monitor failed to launch.

[RTI Issue ID MONITOR-785]

1.4. Vulnerabilities Fixed in 7.7.0.1

The following vulnerabilities are fixed in this release.

For the most up-to-date security information regarding RTI products, we recommend cross-referencing these release notes with the RTI Vulnerability Management web page. That web page is updated periodically and provides the latest security data through two distinct resources:

RTI Security Bulletins cover vulnerabilities that affect RTI code. The bulletins provide the most recent vulnerability details, including severity levels and the specific releases that contain the fixes.
VEX Documents cover vulnerabilities found in third-party components used by RTI products. Whereas these release notes show vulnerabilities that affect RTI products and that have been fixed, the VEX documents also include vulnerabilities that RTI has assessed to find no impact on RTI products.

1.4.1. [Critical] Potential NULL pointer dereference in Connext Professional applications when parsing malicious XML configuration files

Connext Professional applications were vulnerable to a NULL pointer dereference when parsing specially crafted XML configuration files. This vulnerability, tracked as CVE-2026-32776, existed in the Expat third-party library. An attacker with local file system access could exploit this by providing a malicious XML configuration file, leading to an application crash (Denial of Service). The issue was fixed by upgrading Expat to version 2.7.5.

User Impact without Security

Not remotely exploitable through RTPS messages. The XML parser’s external entity handling prevents the vulnerable code path from being reached via network-delivered XML.
Exploitable through a compromised local file system containing malicious XML files.
A NULL pointer dereference in Expat can be triggered when processing specially crafted DTD content, leading to an application crash (Denial of Service). There is no confidentiality or integrity impact.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 6.8 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.
Security Plugins do not change the attack surface for this vulnerability. The RTPS network attack vector is already non-exploitable regardless of Security Plugins. For Governance and Permissions documents, cryptographic signature verification provides additional defense-in-depth. However, standard QoS and configuration files are not signed, so the local attack surface remains unchanged.

[RTI Issue ID CORE-16629]

1.4.2. [Critical] Potential infinite loop in Connext Professional applications when parsing malicious XML

Connext Professional applications were vulnerable to a denial-of-service attack when parsing specially crafted XML documents. This vulnerability, tracked as CVE-2026-32777, existed in the Expat third-party library. An attacker could exploit this by providing a malicious XML configuration file, causing the application’s parsing thread to enter an infinite loop. This leads to 100% CPU usage and makes the application unresponsive. The issue was fixed by upgrading Expat to version 2.7.5.

User Impact without Security

Not remotely exploitable through RTPS messages. The XML parser’s external entity handling prevents the vulnerable code path from being reached via network-delivered XML.
Exploitable through a compromised local file system containing malicious XML files (e.g., QoS profiles).
An infinite loop in Expat can be triggered when processing specially crafted DTD content, resulting in 100% CPU exhaustion for the affected thread and a Denial of Service (DoS) where the application hangs and becomes unresponsive.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 6.8 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16631]

1.4.3. [Critical] Potential shared memory namespace collision in Connext applications using large domain IDs

A potential Shared Memory namespace collision could occur with large domain IDs and affect the confidentiality, integrity and/or availability of a Connext application.

User Impact without Security

Exploitable only locally on an application using Shared Memory.
Confidentiality, integrity, and availability were affected.
CVSS v3.1 Base Score: 7.0 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0 Base Score: 7.3 HIGH
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

User Impact with Security

No impact.

[RTI Issue ID CORE-13448]

1.4.5. [Critical] Potential hash-collision denial of service in Connext Professional applications when parsing malicious XML configuration files

Connext Professional applications were vulnerable to a denial-of-service attack when parsing specially crafted XML documents. This vulnerability, tracked as CVE-2026-41080, existed in the Expat third-party library. In the default configuration, the attack vector was local: a malicious XML configuration file (for example, a QoS profile, an Infrastructure Services configuration file, or an XML-Based Application-Creation file), when processed, could drive the parsing thread to 100% CPU and leave the application unresponsive during configuration load. A network attack vector existed only for an Infrastructure Service that had Remote Administration explicitly enabled (off by default) and XML schema validation disabled. There was no confidentiality or integrity impact. The bundled Expat third-party library has been upgraded to version 2.8.2.

User Impact without Security

In the default configuration, the attack vector is local. A Connext Professional application processes XML only from local files and application-supplied strings — QoS profile files, Infrastructure Services configuration files, and XML-Based Application-Creation files. On-the-wire DDS traffic (discovery and user data) is CDR-serialized and never reaches the XML parser, so an ordinary network peer could not deliver XML to the affected parser (Expat).
An algorithmic-complexity weakness in Expat’s symbol-table hashing (CWE-331) could be triggered by a document containing many crafted element, attribute, or entity names, driving the parsing thread to 100% CPU and causing a Denial of Service in which the application hung during configuration load. There was no confidentiality or integrity impact.
A network attack vector exists only in a non-default configuration: an Infrastructure Service (for example, Routing Service) that has Remote Administration explicitly enabled (off by default) and XML schema validation disabled. Even then, the remote content is first parsed and schema-validated by a separate library (libxml2); only a regenerated, schema-bounded QoS document is passed to Expat, so attacker-chosen names reached Expat only when validation had been turned off. See “Mitigations.”
CVSS v3.1 Base Score: 4.7 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 5.7 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact and same local attack vector as described in “User Impact without Security.” Deploying Security Plugins does not change the base score — the realistic vector is already local — but it provides defense-in-depth that closes the non-XSD-validation network path.
RTPS protection (authentication and encryption) prevents an unauthorized network peer from reaching the Remote Administration topics, so the non-default network path cannot be exercised by an unauthorized peer; authorized administrative participants continue to use Remote Administration normally.
The Permissions Document received during the DDS Security authentication handshake — itself XML parsed by the middleware — is verified against the Permissions CA, so only an attacker holding the Permissions CA’s private key could deliver malicious XML through that path.
CVSS v3.1 Base Score: 4.7 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 5.7 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Mitigations

Restrict permissions for writing to the configuration files your Connext application uses, to prevent the Local Attack Vector.
Use Security Plugins RTPS protection to prevent the Network Attack Vector. RTPS protection authenticates and encrypts DDS traffic, so an unauthorized network peer cannot reach Remote Administration topics; authorized administrative participants continue to use Remote Administration normally. The Permissions Document received during the DDS Security authentication handshake is additionally verified against the Permissions CA, so only an attacker holding the Permissions CA’s private key could deliver malicious XML through that network path.

[RTI Issue ID CORE-16732]

1.4.6. [Critical] Potential out-of-bounds write in Connext Professional applications when updating locators

An out-of-bounds write in a Connext application could have occurred while populating a malicious locator.

User Impact without Security

Exploitable by populating malicious locators.
Integrity and availability were affected. Getting arbitrary code execution was possible.
CVSS v3.1 Base Score: 6.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L
CVSS v4.0 Base Score: 6.9 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N

User Impact with Security

There is no impact when enabling certain Security features; see Mitigations for more information.

Mitigations

To prevent the network attack vector, there are two options:

Don’t call DDS_DomainParticipant_take_discovery_snapshot.
Use Security Plugins RTPS protection to avoid receiving malicious locators from unknown participants.

[RTI Issue ID CORE-16741]

1.4.7. [Critical] Potential out-of-bounds read in Connext Professional applications when internal logging properties set in the QoS configuration

A local QoS configuration file containing non-default properties could trigger a type confusion flaw in the logging infrastructure. Exploitation of this vulnerability may have caused the application to crash during startup, resulting in a denial-of-service condition.

User Impact without Security

A vulnerability in Connext Professional applications could have resulted in the following:

Type confusion and invalid pointer dereference when creating a DomainParticipant with internal properties set to non-default values.
Exploitable by overwriting the QoS profile on the file system.
Potential crash (denial of service) of the Connext application during DomainParticipant creation.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 5.1 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16825]

1.4.8. [Critical] Potential double-free when deleting a Topic for the second time after creating and finding the Topic

Consider the following scenario:

You create a Topic.
You find the Topic using the find_topic API.
You delete the found Topic.
You delete the created Topic.

If an attacker changed your QoS configuration file in a particular way, then the second deletion led to a double-free on the heap.

User Impact without Security

A vulnerability in Connext applications could have resulted in the following:

Heap buffer overread and overwrite when deleting a Topic.
Exploitable by overwriting the QoS profile on the file system.
Potential impact on the integrity of Connext applications.
Potential crash in the application.
CVSS v3.1 Base Score: 7.1 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H
CVSS v4.0 Base Score: 6.9 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16845]

1.4.9. [Critical] Potential out-of-bounds read in Connext Professional applications when a particular field was set in the QoS configuration

Consider the following scenario:

You create a Subscriber with a PresentationQosPolicy.access_scope of GROUP_PRESENTATION_QOS.
You create a best-effort DataReader in the Subscriber.
Then, you create a reliable DataReader in the same Subscriber.
The reliable DataReader is matched with a DataWriter.
The DataWriter writes a sample.

If an attacker changed your local QoS configuration file in a particular way, then the reliable DataReader experienced an out-of-bounds read when receiving the sample. Exploitation of this vulnerability may have caused the application to crash during steady state, resulting in a denial-of-service condition.

User Impact without Security

A vulnerability in Connext Professional applications could have resulted in the following:

Invalid pointer dereference when a reliable DataReader with a non-default QoS configuration received a sample.
Exploitable by overwriting the QoS profile on the file system.
Potential crash (denial of service) of the Connext application during sample reception.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 5.1 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16855]

1.4.10. [Critical] Potential denial of service in Connext applications using the Java API

The Connext Java API was affected by a vulnerability that could have caused the application to reject samples by receiving multiple specific malicious messages.

User Impact without Security

A vulnerability in Connext Professional applications that use the Java API could have resulted in the following:

Exploitable by sending malicious samples.
Potential denial of service of the Connext application using the API after a specific number of malicious messages.
CVSS v3.1 Base Score: 7.5 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 8.7 HIGH
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

There is no impact when enabling certain Security features; see Mitigations for more information.

Mitigations

Use Security Plugins RTPS protection to avoid receiving malicious messages.

[RTI Issue ID CORE-16871]

1.4.11. [Critical] Potential denial of service in Connext Professional applications when parsing malicious XML configuration files

Connext Professional applications were vulnerable to a denial-of-service attack when parsing specially crafted XML documents. This vulnerability, tracked as CVE-2026-45186, existed in the Expat third-party library. In the default configuration, the attack vector was local: a malicious XML configuration file (for example, a QoS profile), when processed, could drive the parsing thread to 100% CPU and left the application unresponsive during configuration load. There was no confidentiality or integrity impact. The bundled Expat third-party library has been upgraded to version 2.8.2.

User Impact without Security

The attack vector was local only. An XML file containing a Document Type Definition (DTD) could trigger an algorithmic-complexity weakness that drove the parsing thread to 100% CPU and caused a Denial of Service in which the application hung during configuration load. There was no confidentiality or integrity impact.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 6.8 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security.”

[RTI Issue ID CORE-16923]

1.4.12. [Critical] Potential out-of-bounds read in Connext Professional applications when internal properties set in the QoS configuration

A local QoS configuration file containing non-default properties could have triggered a type confusion flaw in the logging infrastructure. Exploitation of this vulnerability may have caused the application to crash during startup, resulting in a denial-of-service condition.

User Impact without Security

A vulnerability in Connext Professional applications could have resulted in the following:

Type confusion and invalid pointer dereference when enabling a DataWriter with internal properties set to non-default values.
Exploitable by overwriting the QoS profile on the file system.
Potential crash (denial of service) of the Connext application during DataWriter enabling.
CVSS v3.1 Base Score: 5.5 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 6.8 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16924]

1.4.13. [Critical] Potential denial of service in 64-bit Connext Professional applications when parsing malicious XML configuration files

On 64-bit targets, Connext Professional applications were vulnerable to a denial-of-service attack when parsing specially crafted local XML configuration files. This vulnerability, tracked as CVE-2026-56407, existed in the Expat third-party library. An integer overflow in Expat’s entity-length handling, triggered by a crafted local DTD with an oversized <!ENTITY> value, caused an out-of-bounds read that crashed the parsing component during configuration load. The attack vector was local: a malicious XML configuration file (for example, a QoS profile). 32-bit builds were not affected. There was no confidentiality or integrity impact. The bundled Expat third-party library has been upgraded to version 2.8.2.

User Impact without Security

An integer-overflow weakness in Expat could have resulted in the following:

Out-of-bounds read resulting in a crash of the parsing component during configuration load (Denial of Service). There was no confidentiality or integrity impact.
32-bit builds were not affected: their maximum object size equals the overflow threshold, so the oversized entity buffer could not be allocated and parsing failed cleanly before the cast.
CVSS v3.1 Base Score: 4.7 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
CVSS v4.0 Base Score: 5.7 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16974]

1.4.14. [Critical] Potential heap-based buffer overflow in 64-bit Connext Professional applications when parsing malicious XML configuration files

On 64-bit targets, Connext Professional applications were vulnerable to a memory-corruption attack when parsing specially crafted local XML configuration files. This vulnerability, tracked as CVE-2026-56132, existed in the Expat third-party library. A heap-based buffer overflow in Expat’s handling of XML DTD element content-model declarations, triggered by a crafted local XML configuration file, could corrupt heap memory and crash the parsing component during configuration load. The attack vector was local: a malicious XML configuration file (for example, a QoS profile, an Infrastructure Services configuration file, or an XML-Based Application-Creation file). 32-bit builds were not affected. There was no confidentiality impact. The bundled Expat third-party library has been upgraded to version 2.8.2.

User Impact without Security

An integer-overflow weakness in Expat could have resulted in the following:

Out-of-bounds read resulting in a crash of the parsing component during configuration load (Denial of Service).
No confidentiality impact.
32-bit builds not affected.
CVSS v3.1 Base Score: 5.3 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H
CVSS v4.0 Base Score: 5.8 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID CORE-16975]

1.4.15. [Critical] Potential log loss in Distributed Logger DDSAppender when using XmlLayout

Distributed Logger was affected by a vulnerability in Apache Log4j Core version 2.25.3 where XmlLayout failed to sanitize characters forbidden by the XML 1.0 specification. This vulnerability affected applications that use log4j and have configured the shipped Distributed Logger DDSAppender for integrating log4j logging with Distributed Logger. When certain forbidden characters were present in log messages or MDC (Mapped Diagnostic Context) values and XmlLayout was configured, the XmlLayout produced invalid XML output.

Applications using log4j with the Distributed Logger DDSAppender and XmlLayout configured may have experienced:

With Woodstox on classpath: An exception thrown during the logging call, preventing the log event from being delivered to the DDSAppender, resulting in silent log loss with no error visible to the application.
With JRE’s built-in StAX: Forbidden characters silently written to output, producing malformed XML that may be rejected by log-processing systems.

User Impact without Security

Although Distributed Logger doesn’t use log4j directly, it is affected by this vulnerability because RTI provides a custom log4j appender (DDSAppender) which might be configured to use the XmlLayout. Also, RTI ships log4j as a Distributed Logger dependency:

Log-processing pipeline disruption when logging messages with forbidden XML 1.0 characters through log4j using XmlLayout.
Exploitable if an attacker injects an input that generates a malformed XML.
CVSS v3.1 Base Score: 5.3 MEDIUM
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
CVSS v4.0 Base Score: 6.9 MEDIUM
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID DISTLOG-264]

1.4.16. [Critical] Potential out-of-bounds read in RTI Recording Service during its initialization

Unauthorized access to uninitialized heap bytes in Recording Service could have occurred during its initialization.

User Impact without Security

A vulnerability in Recording Service while initializing could have resulted in the following:

Access of uninitialized heap bytes while executing a malicious SQLite statement.
Exploitable by providing a malicious XML document to Recording Service during startup. Not remotely exploitable.
Potential impact on the confidentiality of the machine running Recording Service.
CVSS v3.1 Base Score: 5.5 Medium
CVSS v3.1 Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
CVSS v4.0 Base Score: 6.8 Medium
CVSS v4.0 Vector: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:L/SA:L

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID RECORD-1584]

1.4.17. [Critical] Potential heap buffer overflow in Security Plugins when simultaneously parsing multiple Permissions Documents

An out-of-bounds read and write on the heap could have occurred while simultaneously parsing multiple Permissions Documents.

User Impact without Security

Not applicable (affects a security-specific product/feature only).

User Impact with Security

A vulnerability in the Connext application could have resulted in the following:

Heap buffer overread and overwrite while simultaneously parsing multiple Permissions Documents.
Exploitable over the network by an attacker with identity credentials that allow it to successfully pass authentication.
Also exploitable by overwriting the Permissions Document file on the file system.
Exploitable only when a race condition was won.
Potential impact on confidentiality and integrity of Connext application.
Potential crash of Connext application.
CVSS v3.1 Base Score: 8.8 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0 Base Score: 7.7 HIGH
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

[RTI Issue ID SEC-2985]

1.4.18. [Critical] Potential use-after-free in RTI Security Plugins for OpenSSL when parsing Permissions Document

The RTI Security Plugins depended on OpenSSL 3.5.5, which is known to be affected by the CVE-2026-45447 publicly disclosed vulnerability.

This vulnerability has been fixed by upgrading OpenSSL to the latest stable version, 3.5.7.

User Impact without Security

Not applicable (affects a security-specific product/feature only).

User Impact with Security

Exploitable use-after-free in the RTI Security Plugins when parsing a Permissions Document.
CVSS v3.1 Base Score: 8.8 High
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS 4.0 Base Score: 8.7 High
CVSS 4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

[RTI Issue ID SEC-3006]

1.4.19. [Critical] Potential Denial of Service in RTI Security Plugins for OpenSSL when parsing OCSP response

The RTI Security Plugins depended on OpenSSL 3.5.5, which is known to be affected by the CVE-2026-34180 publicly disclosed vulnerability.

This vulnerability has been fixed by upgrading OpenSSL to the latest stable version, 3.5.7.

User Impact without Security

Not applicable (affects a security-specific product/feature only).

User Impact with Security

Exploitable heap buffer over-read in the RTI Security Plugins when parsing an OCSP response.
CVSS v3.1 Base Score: 7.5 High
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CVSS 4.0 Base Score: 8.7 High
CVSS 4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

[RTI Issue ID SEC-3007]

1.4.20. [Critical] Potential out-of-bound copy when parsing a WebSocket request

Improper buffer bound check when parsing a WebSocket request could affect the availability of Web Integration Service.

User Impact without Security

A vulnerability in Web Integration Service while parsing a malicious WebSocket request could have resulted in the following:

Availability of the service affected (denial of service).
CVSS v3.1 Base Score: 8.6 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:H
CVSS v4.0 Base Score: 8.8 HIGH
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:H/SC:N/SI:N/SA:N

User Impact with Security

Same impact as described in “User Impact without Security” above.

[RTI Issue ID WEBINT-375]

1.4.21. [Critical] Potential heap-based buffer overflow in Connext Professional applications when receiving samples containing unbounded strings

Connext Professional applications could have experienced a heap-based buffer overflow when a DataReader copied a received sample if an internal memory allocation failed during the copy. The operation reported success, so the condition was not detectable by the application. The likely result was memory corruption and a crash.

This affected applications using a data type generated with unbounded string support and the copy-based read/take API with a sample structure reused across successive calls.

User Impact without Security

Exploitation impact — Overflow Buffers (CAPEC-100): a remote Publisher could have caused an out-of-bounds heap write in a subscribing application, controlling both the length and the contents of what was written. The likely result was memory corruption and a crash.
Attack vector — network: an ordinary Publisher on the same domain and Topic reached the affected code; no administrative interface, non-default configuration, or local file access was involved.
Security-triad impact: Integrity — the write’s length and contents were attacker-controlled, and the operation reported success, so the application could neither detect nor handle the corruption. Availability — likely memory corruption and a crash. Confidentiality — no impact.
Conditions for exploitability: a data type generated with unbounded string support; an application using the copy-based read/take API with a sample structure reused across successive calls; and a single memory allocation failing at the time of the copy — a condition outside the attacker’s control. Exposure is limited to the C and Traditional C++ APIs.
CVSS v3.1 Base Score: 7.4 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
CVSS v4.0 Base Score: 8.3 HIGH
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N

User Impact with Security

There is no impact when enabling certain security features; see Mitigations for more information.

Mitigations

Use Security Plugins RTPS protection to prevent a Network Attack Vector.

[RTI Issue ID CORE-17021]

1.4.22. [Major] Potential information disclosure and memory corruption in DDS Spy

A malicious request sent to DDS Spy could lead to information disclosure or memory corruption.

User Impact without Security

A vulnerability in DDS Spy could have resulted in the following:

Only DDS Spy was affected.
Exploitable by making DDS Spy print a malicious type.
CVSS v3.1 Base Score: 8.1 HIGH
CVSS v3.1 Vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
CVSS v4.0 Base Score: 9.2 CRITICAL
CVSS v4.0 Vector: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

User Impact with Security

There was no impact when enabling certain security features; see Mitigations for more information.

Mitigations

Use Security Plugins RTPS protection to avoid receiving malicious locators from unknown participants.

[RTI Issue ID CORE-16740]

1.5. Important Corrections in this Document

Some errors exist in the original version of this document that gets installed with the 7.7.0.1 patch; these have been corrected in this version of the document:

The new features, “XML files containing tryConstruct annotation no longer fail to load” and “Expanded writer-side filtering support for better scalability, when using a finite LivelinessQos::lease_duration and AUTOMATIC LivelinessQos::kind,” are mistakenly documented in “What’s New in 7.7.0.1” in the 7.7.0.1 installation. These features are not included in 7.7.0.1 (and they are not documented in this version of the document).
The version of the Core Libraries Platform Notes installed with 7.7.0.1 mistakenly says that the new platform x64Win64MinGW13gcc15 supports Collector Service Lite and does not support Monitoring Library 2.0. In fact, it does not support Collector Service Lite and does support Monitoring Library 2.0. The Core Libraries Platform Notes on community have the correct information.
The fix for CORE-16887 was mistakenly not documented in the version of this document installed with 7.7.0.1. It is included in this version of the document, along with its upgrade consideration, DDS_DynamicData::from_string now ignores unknown members for appendable and mutable types.

1.6. Compatibility and Upgrade Information

1.6.1. Public header files

Some patches contain public header file changes. Even if a patch does not contain public header file changes, a previous patch in the series may have public header file changes. Therefore, you should always install your patch in a clean directory (do not install it on top of your current installation) to avoid header file and library incompatibilities. To do this:

Install the patch release host executable in a new directory.

Note

The fourth digit of the patch version is not included in your new (rti_connext_dds-7.7.0) installation folder name. You can confirm that you have successfully installed the patch by checking rti_versions.xml in the rti_connext_dds-7.7.0 folder.

Install the patch release target package.

Install add-ons: host first, then target.

See “Upgrading to a Patch Release” in the RTI Connext Professional Installation Guide in your patch installation (<NDDSHOME>/doc/manuals/connext_dds_professional/installation_guide) for more information.

1.6.2. Code generation

Some patches require code regeneration or contain a previous patch in the series that required code regeneration. Therefore, use the Code Generator provided with 7.7.0.1 to regenerate code. (You should see a message that you are using rtiddsgen 4.7.0.1 while regenerating the code.)

1.6.3. Updating the C# and Python APIs

To update the C# API, if the patch includes it, install the rti_dotnet_support-<version>.rtipkg package. Do not download the NuGet packages from nuget.org; those are for license-managed (lm) bundles only, which are not always available for patch releases. See Installing Commercial Python, C#, or Ada Packages in the RTI Connext Professional Installation Guide.

The Python API is installed as part of the Core host package or, for some platforms (if the patch includes them), it might be a separate rti_connext_python_support-<version>-<arch>.zip bundle. Do not install the Python API from pypi.org; that method is for license-managed (lm) bundles only, which are not always available for patch releases. See Installing Commercial Python, C#, or Ada Packages in the RTI Connext Professional Installation Guide.

1.6.4. Remote debugging interoperability

Admin Console in 7.7.0 cannot interoperate in remote debugging mode with applications using newer 7.7 patch releases, starting with 7.7.0.1. You must upgrade Admin Console to the same or a later patch release to restore remote debugging compatibility.

When Admin Console 7.7.0 receives remote debugging information from an application using Connext 7.7.0.1 or later libraries, it may report errors similar to the following:

2026-06-18 10:13:14,195 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicData2StructPlugin_getMemberInfo: Cannot find a member (name = "out_of_order_delivery_kind", id = 0) in type DDS::Monitoring::ReliabilityQosPolicy
2026-06-18 10:13:14,198 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicData2_get_member_info:!get_member_info
2026-06-18 10:13:14,199 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicDataParser_parse_json_node:!get member info out_of_order_delivery_kind
2026-06-18 10:13:14,199 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicDataParser_parse_json_node:!parse json node qos_reliability
2026-06-18 10:13:14,199 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicDataParser_parse_json_node:!parse json node data_writer
2026-06-18 10:13:14,200 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicDataParser_parse_json_node:!parse json node value
2026-06-18 10:13:14,200 : ERROR : com.rti.tools.console.entitymodel.util.Log4jLoggerDevice.write(Log4jLoggerDevice.java:102) : - ERROR DDS_DynamicDataFormatter_from_json_w_params:!parse json node

1.6.5. Locator reachability interoperability

The fix for CORE-16398, [Critical] Locator reachability updates may not have been received by all DomainParticipants, introduces a breaking interoperability with previous releases.

The fix for the issue required modifing the internal implementation of the locator reachability channel. As a result, this feature is no longer interoperable between versions that include the CORE-16398 fix and versions that do not.

If your deployment contains a mix of applications, where some use a Connext version that includes the fix and others use an older Connext version:

Applications running the newer Connext version will continue to work correctly and will receive locator reachability updates from old and new versions.

Applications running older Connext versions will not be able to process data received through the locator reachability channel from newer versions of Connext. The older applications will report errors similar to the following:

ERROR [0x0101413D,0x4A0F2C73,0x1CC176A0:0x00020087{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101A34E,0x48E7A84B,0x8B1ED707:0x00020082] PRESPsService_dispatchLocatorReachability:FAILED TO UPDATE | participant locator reachability
ERROR [0x0101413D,0x4A0F2C73,0x1CC176A0:0x00020087{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101A34E,0x48E7A84B,0x8B1ED707:0x00020082] PRESPsService_dispatchLocatorReachabilitySample:!dispatch
ERROR [0x0101413D,0x4A0F2C73,0x1CC176A0:0x00020087{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101A34E,0x48E7A84B,0x8B1ED707:0x00020082] PRESPsService_dispatchBuiltinChannelSample:Failed to dispatch DDSServiceRequest request
ERROR [0x0101413D,0x4A0F2C73,0x1CC176A0:0x00020087{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101A34E,0x48E7A84B,0x8B1ED707:0x00020082] PRESParticipant_dispatchBuiltinChannelSample:!dispatch
ERROR [0x0101413D,0x4A0F2C73,0x1CC176A0:0x00020087{Entity=DR,MessageKind=DATA}|RECEIVE FROM 0x0101A34E,0x48E7A84B,0x8B1ED707:0x00020082] DDS_ServiceRequestChannel_onDataAvailable:!dispatch service requests

1.6.6. API compatibility

1.6.6.1. distlog.jar merged into distlogdatamodel.jar

As a result of the JPMS (Java Platform Module System) module descriptors new feature, distlog.jar no longer ships as a separate file. Its contents have been merged into distlogdatamodel.jar, which was already a required classpath entry.

Therefore, remove distlog.jar from your classpath. Keep (or add) distlogdatamodel.jar.

1.6.6.2. Using JARs on the module path

The release JARs now include JPMS module descriptors and can be used on the Java module path (--module-path). The module names are as follows:

JAR file	JPMS module name
`nddsjava.jar`	`nddsjava`
`rticonnextmsg.jar`	`rticonnextmsg`
`rtiroutingservice.jar`	`rtiroutingservice`
`rtirsadapter.jar`	`rtirsadapter`
`distlogdatamodel.jar`	`distlog`

The debug JARs (nddsjavad.jar, etc.) do not carry JPMS module descriptors and cannot be placed on the module path. They continue to work on the classpath. Both release and debug JARs select the release or debug native libraries via the com.rti.debug Java property; you do not need the debug JAR to use debug native libraries.

It is recommended that you stop using the debug JARs, since they are deprecated and will be removed in a future release. The release JARs are equivalent when using com.rti.debug=1.

1.6.6.3. DDS_DynamicData::from_string now ignores unknown members for appendable and mutable types

Applications that relied on DDS_DynamicData::from_string’s failing when a JSON object contained unknown members may observe a change in behavior after upgrading to this release. For appendable and mutable types, the presence of additional JSON members no longer causes the operation to fail, due to the fix for CORE-16887, [Major] DDS_DynamicData::from_string failed parsing a JSON string with unknown members.

If your application uses this failure to validate that a JSON object exactly matches the target type, you should add explicit validation for unexpected members before calling DDS_DynamicData::from_string.