Marta Rybczynska

**Name of the Vulnerable Software and Affected Versions** Eclipse Dataspace Components versions 0.1.3 through 0.9.0 **Description** The issue concerns the Connector component in Eclipse Dataspace Components, which is responsible for filtering datasets that another party can see in a requested catalog. However, there is a possibility to request a single dataset without the correct filtering, potentially allowing parties to see datasets they should not have access to and exposing sensitive information. Exploiting this issue requires knowing the ID of a restricted dataset, but some IDs may be guessed through automated attempts. **Recommendations** For Eclipse Dataspace Components versions 0.1.3 through 0.9.0, patch immediately to mitigate risks. As a temporary workaround, consider restricting access to the `DatasetResolverImpl` function until a patch is available. Avoid using the affected code in the `DatasetResolverImpl` function, specifically lines 76-79, until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Eclipse Dataspace Components versions 0.5.0 through 0.9.0 **Description** The issue is related to the ConsumerPullTransferTokenValidationApiController component, which has inadequate authentication procedures. This allows a remote attacker to bypass the token expiration check. The vulnerability requires a dataplane configured to support http proxy consumer pull and includes the module "transfer-data-plane". The affected code was marked deprecated from version 0.6.0 in favor of Dataplane Signaling and was removed in version 0.9.0. **Recommendations** For Eclipse Dataspace Components versions 0.5.0 through 0.8.0, update to version 0.9.0 or later to resolve the issue. For Eclipse Dataspace Components version 0.9.0, no action is required as the vulnerable code has been removed. As a temporary workaround, consider disabling the `ConsumerPullTransferTokenValidationApiController` function until a patch is available. Restrict access to the `transfer-data-plane` module to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Eclipse Memory Analyzer versions 0.7 to 1.14.0 **Description** The issue arises from the lack of filtering in report definition XML files to prohibit document type definition (DTD) references to external entities. If a user uses a malicious report definition XML file containing an external entity reference to generate a report, Eclipse Memory Analyzer may access external files or URLs defined via a DTD in the report definition. **Recommendations** For Eclipse Memory Analyzer versions 0.7 to 1.14.0, as a temporary workaround, consider disabling the use of external entity references in report definition XML files until a patch is available. Restrict access to report definition XML files to minimize the risk of exploitation. Avoid using report definition XML files from untrusted sources. At the moment, there is no information about a newer version that contains a fix for this vulnerability.

**Name of the Vulnerable Software and Affected Versions** Eclipse OpenJ9 versions prior to 0.41.0 **Description** The issue is related to a denial of service caused by a flaw when a shutdown signal (SIGTERM, SIGINT or SIGHUP) is received before the JVM has finished initializing. This can lead to an infinite busy hang on a spinlock or a segmentation fault. A local authenticated attacker could exploit this by sending a specially crafted request. **Recommendations** For Eclipse OpenJ9 versions prior to 0.41.0, update to version 0.41.0 or later to resolve the issue. As a temporary workaround, consider implementing signal handling mechanisms to prevent shutdown signals from being received before the JVM has finished initializing. Restrict access to the JVM during the initialization phase to minimize the risk of exploitation.

**Name of the Vulnerable Software and Affected Versions** Eclipse Parsson versions prior to 1.1.4 Eclipse Parsson versions prior to 1.0.5 **Description** Parsing JSON from untrusted sources can lead to exploitation due to edge cases in Java's built-in support for parsing numbers with large scales, resulting in unexpectedly large processing times. **Recommendations** For Eclipse Parsson versions prior to 1.1.4, update to version 1.1.4 or later to mitigate the risk. For Eclipse Parsson versions prior to 1.0.5, update to version 1.0.5 or later to mitigate the risk.