Improper verification of the time certificate in Eclipse Cyclone DDS before v0.10.5 allows attackers to bypass certificate checks and execute commands with System privileges.

In the Eclipse Theia Website repository, the GitHub Actions workflow .github/workflows/preview.yml used pullrequesttarget trigger while checking out and executing untrusted pull request code. This allowed any GitHub user to execute arbitrary code in the repository's CI environment with access to repository secrets and a GITHUBTOKEN with extensive write permissions (contents:write, packages:write, pages:write, actions:write). An attacker could exfiltrate secrets, publish malicious packages to the eclipse-theia organization, modify the official Theia website, and push malicious code to the repository.

In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, inadequate path normalization in the Submodel HTTP API allows an unauthenticated remote attacker to perform a path traversal attack. By supplying a maliciously crafted fileName parameter during a file upload operation, an attacker can bypass intended storage boundaries and write arbitrary files to any location on the host filesystem accessible by the Java process. This can lead to Remote Code Execution (RCE) and complete system compromise.

The network enabled distribution of Kura before 2.1.0 takes control over the device's firewall setup but does not allow IPv6 firewall rules to be configured. Still the Equinox console port 5002 is left open, allowing to log into Kura without any user credentials over unencrypted telnet and executing commands using the Equinox "exec" command. As the process is running as "root" full control over the device can be acquired. IPv6 is also left in auto-configuration mode, accepting router advertisements automatically and assigns a MAC address based IPv6 address.

Eclipse RDF4j version < 2.4.0 Milestone 2 contains a XML External Entity (XXE) vulnerability in RDF4j XML parser parsing RDF files that can result in the disclosure of confidential data, denial of service, server side request forgery, port scanning. This attack appear to be exploitable via Specially crafted RDF file.

In Eclipse p2, installable units are able to alter the Eclipse Platform installation and the local machine via touchpoints during installation. Those touchpoints can, for example, alter the command-line used to start the application, injecting things like agent or other settings that usually require particular attention in term of security. Although p2 has built-in strategies to ensure artifacts are signed and then to help establish trust, there is no such strategy for the metadata part that does configure such touchpoints. As a result, it's possible to install a unit that will run malicious code during installation without user receiving any warning about this installation step being risky when coming from untrusted source.

A user able to create Policy Sets can run arbitrary code by sending malicious Groovy scripts which will escape the configured Groovy sandbox.

Eclipse Keti is a service that was designed to protect RESTfuls API using Attribute Based Access Control (ABAC). In Keti a sandbox escape vulnerability may lead to post-authentication Remote Code execution. This vulnerability is known to exist in the latest commit at the time of writing this CVE (commit a1c8dbe). For more details see the referenced GHSL-2021-063.

Impact DDFFileParser and DefaultDDFFileValidator (and so ObjectLoader) are vulnerable to XXE AttacksProcessing).

DDF file is a LWM2M format used to store LWM2M object description. Leshan users are impacted only if they parse untrusted DDF files (e.g. if they let external users provide their own model), in that case they MUST upgrade to fixed version. If you parse only trusted DDF file and validate only with trusted xml schema, upgrading is not mandatory.

Patches This is fixed in v1.5.0 and 2.0.0-M13.

Workarounds No easy way. Eventually writing your own DDFFileParser/DefaultDDFFileValidator (and so ObjectLoader) creating a DocumentBuilderFactory with : java // For DDFFileParser DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); factory.setFeature(XMLConstants.FEATURESECUREPROCESSING, true); factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // Disable DTDs factory.setXIncludeAware(false); // Disable XML Inclusions factory.setExpandEntityReferences(false); // disable expand entity reference nodes

// For DefaultDDFFileValidator SchemaFactory factory = SchemaFactory.newInstance(XMLConstants.W3CXMLSCHEMANSURI); factory.setFeature(XMLConstants.FEATURESECUREPROCESSING, true); factory.setProperty(XMLConstants.ACCESSEXTERNALDTD, ""); factory.setProperty(XMLConstants.ACCESSEXTERNALSCHEMA, "");

References - https://owasp.org/www-community/vulnerabilities/XMLExternalEntity(XXE)Processing - https://cheatsheetseries.owasp.org/cheatsheets/XMLExternalEntityPreventionCheatSheet.html - https://semgrep.dev/docs/cheat-sheets/java-xxe/ - https://community.veracode.com/s/article/Java-Remediation-Guidance-for-XXE

In Eclipse ThreadX NetX Duo before 6.4.0, if an attacker can control parameters of portablealignedalloc() could cause an integer wrap-around and an allocation smaller than expected. This could cause subsequent heap buffer overflows.

Eclipse Target Management: Terminal and Remote System Explorer (RSE) version <= 4.5.400 has a remote code execution vulnerability that does not require authentication.

The fixed version is included in Eclipse IDE 2024-03

In Eclipse Mosquitto, from version 1.3.2 through 2.0.18, if a malicious broker sends a crafted SUBACK packet with no reason codes, a client using libmosquitto may make out of bounds memory access when acting in its onsubscribe callback. This affects the mosquittosub and mosquittorr clients.

In Eclipse GlassFish since version 6.2.5 it is possible to perform a Server Side Request Forgery attack in specific endpoints.

In FileX before 6.4.2, the file support module for Eclipse Foundation ThreadX, there was a possible buffer overflow in the FileX RAM disk driver. It could cause a remote execurtion after receiving a crafted sequence of packets

In NetXDuo version before 6.4.4, a networking support module for Eclipse Foundation ThreadX, in the DHCPV6 client there was an unchecked index extracting the server DUID from the server reply. With a crafted packet, an attacker could cause an out of memory read.

OpenMQ exposes a TCP-based management service (imqbrokerd) that by default requires authentication. However, the product ships with a default administrative account (admin/ admin) and does not enforce a mandatory password change on first use. After the first successful login, the server continues to accept the default password indefinitely without warning or enforcement.

In real-world deployments, this service is often left enabled without changing the default credentials. As a result, a remote attacker with access to the service port could authenticate as an administrator and gain full control of the protocol’s administrative features.

An unsafe parsing of OpenMQ's configuration in OpenMQ versions <6.5.2 and <6.9.0, allows a remote attacker to read arbitrary files from a MQ Broker's server. A full exploitation could read unauthorized files of the OpenMQ’s host OS. In some scenarios RCE could be achieved. This is fixed in OpenMQ 6.5.2, 6.9.0, and in GlassFish 7.0.26, 7.1.1, and 8.0.2.

In Eclipse BaSyx Go Components versions up to and including 1.0.0, ABAC-enabled deployments are vulnerable to an authorization bypass caused by inconsistent trailing-slash handling between the ABAC middleware and the HTTP router.

The shared router configuration used Chi's middleware.StripSlashes, so a request such as GET /shells/ was dispatched to the registered GET /shells route. However, the ABAC middleware evaluated the original request path including the trailing slash. If ABAC route lookup did not find a matching slash-suffixed route, the request was passed onward and the router then stripped the slash and executed the protected handler without the intended ABAC authorization decision and without the expected ABAC query filters.

An unauthenticated or unauthorized network attacker could append a trailing slash to protected API routes to reach handlers that should have been denied by ABAC policy. Depending on the exposed component, HTTP method, and deployed policy, this could allow unauthorized read, create, update, delete, or upload operations.

The issue affects ABAC-enabled deployments of services that use the shared router and ABAC middleware, including AAS Repository, Submodel Repository, AAS Registry, Submodel Registry, Concept Description Repository, Discovery, AAS Environment upload, and related services. The issue is fixed in Eclipse BaSyx Go Components v1.0.1.

IBM JDK 8 SR5 FP30 (8.0.5.30) and IBM JDK 7R1 SR4 FP40 (7.1.4.40) fix a flaw described by upstream as:

Eclipse OpenJ9 is vulnerable to a buffer overflow, caused by improper bounds checking by the jiosnprintf() and jiovsnprintf() functions. By sending an overly long argument, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash.

OpenJ9 upstream bug and commit:

https://bugs.eclipse.org/bugs/showbug.cgi?id=543659 https://github.com/eclipse/openj9/commit/0971f22d88f42cf7332364ad7430e9bd8681c970

References:

https://www-01.ibm.com/support/docview.wss?uid=ibm10873332 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateMarch2019

IBM JDK 8 SR5 FP30 (8.0.5.30) fixes a flaw described by upstream as:

Eclipse OpenJ9 could allow a remote attacker to execute arbitrary code on the system, caused by the failure to omit a null check on the receiver object of an Unsafe call when accelerating it. An attacker could exploit this vulnerability to execute arbitrary code on the system.

OpenJ9 upstream bug:

https://bugs.eclipse.org/bugs/showbug.cgi?id=544019

Related OpenJ9 upstream commit seems to be:

https://github.com/eclipse/openj9/commit/531d3f96fe9cdcf6baad9f6d6837be8fbc805d8d

References:

https://www-01.ibm.com/support/docview.wss?uid=ibm10873332 https://developer.ibm.com/javasdk/support/security-vulnerabilities/#IBMSecurityUpdateMarch2019

In Eclipse RAP versions from 3.0.0 up to and including 3.25.0, Remote Code Execution is possible on Windows when using the FileUpload component.

The reason for this is a not completely secure extraction of the file name in the FileUploadProcessor.stripFileName(String name) method. As soon as this finds a / in the path, everything before it is removed, but potentially \ (backslashes) coming further back are kept.

For example, a file name such as /..\..\webapps\shell.war can be used to upload a file to a Tomcat server under Windows, which is then saved as ..\..\webapps\shell.war in its webapps directory and can then be executed.

Eclipse OpenJ9 is vulnerable to a stack-based buffer overflow when the virtual machine or JNI natives are converting from UTF-8 characters to platform encoding. By sending an overly long string, a remote attacker could overflow a buffer and execute arbitrary code on the system or cause the application to crash.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by a flaw when handling more than one Content-Length headers. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

Eclipse Jetty is vulnerable to HTTP request smuggling, caused by improper handling of Chunked Transfer-Encoding chunk size. By sending a specially-crafted request, an attacker could exploit this vulnerability to poison the web cache, bypass web application firewall protection, and conduct XSS attacks.

An XML External Entity vulnerability was found in vertx-web before 3.5.4. The function isValid didn't provide any XXE protection when parsing an XML document.

Upstream issue:

https://github.com/vert-x3/vertx-web/issues/1021

References:

https://bugs.eclipse.org/bugs/showbug.cgi?id=539568

Upstream patches:

https://github.com/vert-x3/vertx-web/pull/1022/commits/d814d22ade14bafec47c4447a4ba9bff090f05e8 https://github.com/vert-x3/vertx-web/pull/1022/commits/26db16c7b32e655b489d1a71605f9a785f788e41

Eclipse Openj9 could allow a remote attacker to gain elevated privileges on the system, caused by not throwing IllegalAccessError for MethodHandles that invoke inaccessible interface methods. By persuading a victim to execute a specially-crafted program under a security manager, an attacker could exploit this vulnerability to gain elevated privileges and execute arbitrary code on the system.

In versions prior to 1.1 of the Eclipse Paho MQTT C Client, the client does not check remlen size in readpacket.

In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the StaticHandler uses external input to construct a pathname that should be within a restricted directory, but it does not properly neutralize '\' (forward slashes) sequences that can resolve to a location that is outside of that directory when running on Windows Operating Systems.

In Eclipse Vert.x 3.4.x up to 3.9.4, 4.0.0.milestone1, 4.0.0.milestone2, 4.0.0.milestone3, 4.0.0.milestone4, 4.0.0.milestone5, 4.0.0.Beta1, 4.0.0.Beta2, and 4.0.0.Beta3, StaticHandler doesn't correctly processes back slashes on Windows Operating systems, allowing, escape the webroot folder to the current working directory.

In Eclipse Theia 0.1.1 to 0.2.0, it is possible to exploit the default build to obtain remote code execution (and XXE) via the theia-xml-extension. This extension uses lsp4xml (recently renamed to LemMinX) in order to provide language support for XML. This is installed by default.