Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, SessionEventLoop.run catches only InterruptedException, and SessionEventLoopGroup does not restart a terminated loop. An MQTT command that raises an uncaught exception can terminate an event loop shared by multiple client sessions, preventing every co-located client from processing PUBLISH, SUBSCRIBE, PUBACK, and other commands. An attacker can select client IDs that map across the available loops to disrupt session processing for the entire broker. This issue is fixed in version 0.18.1.

In Eclipse iceoryx2 versions greater than v0.8.0, the StaticString exposes its contents as mutable bytes through safe APIs, while String::asstr() converts those bytes into a Rust string slice without validating UTF-8. An application can therefore create an invalid &str and trigger undefined behavior using entirely safe Rust.

In Eclipse Ankaios versions 0.6.0 to before 1.0.4, LogRule::matches in the agent control-interface authorizer stops at the first wildcard pattern in a single rule instead of evaluating later entries, which can cause deny LogRule entries to be skipped and allow unauthorized access to another workload's logs.

In Eclipse Ankaios versions 0.1.0 through 1.0.2, the agent creates workload files and Control Interface named pipes (FIFOs) under a predictable path derived from the agent name and a hash of the workload's runtime configuration. If a directory or FIFO already exists at that path when the agent (re)starts, the agent reuses it based only on an existence and/or file-type check, without validating its owner or permissions. A local, unprivileged user with write access to the same base directory (by default under $TMPDIR/ankaios, e.g. shared /tmp) can pre-create this path hierarchy, including the two Control Interface FIFOs, before the agent starts. The agent then treats the attacker-owned FIFOs as the legitimate Control Interface for the targeted workload. The attacker can complete the Control Interface handshake and issue requests using that workload's configured controlInterfaceAccess permissions, allowing impersonation of the workload and, depending on its configured permissions, unauthorized reading and/or modification of the cluster's desired state.

In Eclipse Embedded CDT versions 6.0 to 6.7 if the CMSIS-Pack archive extracts a compromised CMSIS pack the archive extraction can extract files to locations outside of the pack, allowing writing of arbitrary files to other locations on disk.

A client may issue HTTP/2 requests to a Jetty server that result in blocking writes that are never unblocked, eventually causing all threads to be blocked and the whole server to become unresponsive.

This is caused by a race condition in the server when handling RSTSTREAM frames and GOAWAY frames sent by the client.

The race condition "resets" the HTTP2Flusher.terminated, previously set to a non-null value, to the null value, allowing entries to be enqueued in the flusher that however will never be processed. These unprocessed entries are the ones that would unblock the write-blocked threads.

A client may issue specially crafted HTTP/1.1 chunked requests to a Jetty server that cause Jetty and an intermediary proxy to interpret different request boundaries, potentially resulting in HTTP request smuggling.

This is caused by Jetty accepting a lone LF character as a terminator in parts of chunked request parsing. Depending on the Jetty version and configured HTTP compliance mode, this may occur in chunk extensions, chunk data termination, or trailer termination.

In Eclipse Che versions 7.79.0 through 7.121.0, the dashboard backend's POST /dashboard/api/data/resolver endpoint passes a caller-supplied URL directly to an outbound HTTP GET request with no host filtering. An authenticated user can exploit this server-side request forgery (SSRF) to read responses from internal network addresses, including the cloud instance metadata service (169.254.169.254), loopback interfaces, RFC-1918 private ranges, and in-cluster Kubernetes services. The operator-configured allowlist (spec.devEnvironments.allowedSources.urls) is not consulted. The vulnerability is fixed in version 7.122.0, which adds private-address blocking, IPv4-mapped IPv6 bypass prevention, operator allowlist enforcement, and disables HTTP redirects on the outbound request.

A client may send a WebSocket frame with an unknown opcode and a very large declared payload length, causing Jetty to attempt a large memory allocation and potentially exhaust the JVM heap.

This occurs when auto-fragmentation is enabled, as unknown opcodes bypass the normal maximum frame size handling and payload allocation occurs before the opcode is validated.

In Eclipse Ankaios versions 0.1.0 through 1.0.1, the agent does not limit the length declared by a workload in a length-delimited protobuf message received through the Control Interface FIFO. A workload granted Control Interface access can specify an excessive message length, causing an unbounded memory allocation that may abort the Ankaios agent process. This results in loss of orchestration services for workloads managed by the affected agent.

In Eclipse Ankaios versions v0.5.1 through v1.0.1, the agent-side Control Interface authorizer incorrectly evaluates multi-segment allow rules whose first path segment is a wildcard. An authenticated workload with access restricted by such a rule can submit a CompleteStateRequest or UpdateStateRequest with an empty field mask. The request may then be incorrectly authorized as matching the scoped rule, allowing the workload to read the complete cluster state or replace state outside its authorized subtree. This may result in unauthorized disclosure or modification of other workloads and cluster configuration. Only a rule consisting solely of is intended to authorize an empty mask.

Mitigation: Until an update containing the fix is installed, avoid multi-segment Control Interface allow-rule filter masks that begin with a wildcard, such as .workloads.someworkload. Replace them with explicit paths such as desiredState.workloads.someworkload, where applicable. A filter mask consisting solely of has different, intentionally unrestricted semantics and should only be used when full-state access is intended.

Eclipse aeriOS Self-orchestrator versions prior to 1.2.1 contain a path traversal vulnerability in the REST API. User-controlled identifiers used to create, update, or delete Self-orchestrator resources were incorporated into filesystem paths without adequate validation or sanitization. An unauthenticated remote attacker able to access the Self-orchestrator API could therefore supply specially crafted identifiers containing path traversal sequences to write or delete JSON files outside the intended application directories, subject to the filesystem permissions of the Self-orchestrator process.

The impact is increased by the absence of authentication on the affected API and by the container running with elevated privileges in the affected deployment configuration.

The issue has been addressed in version 1.2.1 by introducing validation and sanitization of user-controlled identifiers before they are used to construct filesystem paths, preventing path separator characters from being used to escape the intended directories.

In Eclipse Arrowhead versions from 5.0.0 to 5.2.1 when the MQTT API is enabled with the certificate authentication policy, CertificateMqttFilter parses an X.509 certificate that the client sends inside the MQTT message payload (the authentication field of MqttRequestTemplate) and treats its Subject DN as the authenticated identity. The certificate is decoded with CertificateFactory.generateCertificate() but its signature is never verified and its issuer chain is never validated against any trust store. Authorisation is reduced to two string comparisons on attacker-supplied data: the DN-qualifier must equal "sy" or "op", and the cloud-name part of the CN must match the server's. Both values are public (the cloud name is in the server's own TLS certificate). An attacker who can publish to the MQTT broker can therefore mint a self-signed certificate with CN=Sysop.<cloud>.<org>.arrowhead.eu, dnQualifier=op, send it as the authentication field, and be authenticated as the cloud's system operator with isSysOp == true. This passes the downstream ManagementServiceMqttFilter (request.isSysOp() → allowed) and gives full management access over MQTT. The HTTP CertificateFilter is not affected — it reads the certificate from jakarta.servlet.request.X509Certificate, which Tomcat populates only after a successful mTLS handshake against the configured trust store.

In Eclipse Ditto versions [1.3.0, 3.9.6], the ImplicitThingCreationMessageMapper of the connectivity service builds a CreateThing command by substituting placeholder values (e.g. {{ header:deviceid }}) resolved from inbound message headers into a pre-configured JSON "thing" template as raw, un-escaped strings, and then parses the resulting string as JSON. Because the placeholder engine performs no JSON escaping and is unaware of the surrounding JSON string context, a resolved value containing a double-quote character can break out of its string and inject additional JSON structure.

When a connection is configured to use this mapper with a template that reflects a header whose value a publishing device can control (for example an MQTT 5 user property, an AMQP 1.0 application property, or a Kafka record header), an attacker able to publish on that connection can inject an inline policy object. The inline policy overrides the administrator-configured policyId, letting the attacker assign an arbitrary access-control policy to the newly created digital twin — gaining full read/write access to it and potentially revoking the legitimate owner's access, with no administrator interaction.

Exploitation requires all of the following: the connection uses the (non-default) ImplicitThingCreation mapper; its template reflects an attacker-controllable header; and, for the policy-override impact, the connection's authorization subjects are permitted to create policies (the default). Deployments that restrict the connection's subjects to thing creation only via the entity-creation configuration are not affected by the policy-override impact.

In Eclipse Ditto versions 3.0.0 to 3.9.6, the Things service fetches WoT (Web of Things) ThingModels over HTTP from URLs supplied by API users in the definition field of a Thing or Feature, without validating the target host, and follows HTTP redirects without re-validating the redirect target and without a hop limit. An authenticated user who is permitted to create a Thing, or who holds WRITE permission on an existing Thing, can thereby cause the Things service to issue arbitrary HTTP GET requests from inside the deployment's network — including to cloud instance-metadata endpoints and other internal services — and can use the differing error responses returned to the caller to enumerate internal services. Versions 2.4.0 to 2.5.x contain the same code, but are only affected where the operator explicitly enabled the WoT integration feature toggle, which is disabled by default in those versions.

In Eclipse Theia versions 1.73.0 up to but not including 1.75.0, the AI "Agent Mode" file-change tools (writeFileContent, suggestFileContent, and the replacement and state helpers) resolved a model-supplied file path without a workspace-containment check. A crafted relative path such as ../.bashrc, an absolute path, or a ~-expanded path could therefore write or delete files outside the workspace with the privileges of the Theia backend OS user. Because the path argument is influenced by model output, it can be steered through indirect prompt injection, and in Agent Mode writes are applied without a confirmation dialog. Writing to a host-executed file such as a shell startup file or ~/.ssh/authorizedkeys can escalate to code execution on the backend.

In Eclipse Lyo versions 2.0.0 to 7.0.0, OAuth server authorization checks can be bypassed when the 2-legged auth is supported by the server. In those cases, application that based their authz filters upon Lyo-provided AbstractAdapterCredentialsFilter, are vulnerable. An attacked can create a provisional trusted client (valid use-case) but then it can be used as a trusted client immediately without requiring the administrator approval to clear the provisional status. The 3-legged path requiring user interaction is not vulnerable and rejects provisional clients.

In Eclipse SW360 versions 19.0.0, 19.1.0, 19.2.0, 20.0.0, 20.1.0, if the system is configured to use file system storage with config key enable.attachment.store.to.file.system, the attacker can manipulate the filename upon upload and can essentially cause arbitrary file path traversal.

The immediate workaround is to disable enable.attachment.store.to.file.system or update to fixed versions.

A vulnerability was found in Undertow where the WebSocketContainer and its boot process do not allow setting the binaryBuffer and textBuffer sizes, along with session duration and async send timeout. These parameters default to infinite. This is a follow-up to CVE-2026-5680, as the initial fix allowed setting buffer sizes for certain types but left async send and session duration as infinite and inaccessible for configuration. An attacker could exploit these infinite defaults to cause resource exhaustion or an Out of Memory (OOME) condition on the server.

In Eclipse OpenJ9 versions up to 0.60, a crafted .class file with deeply nested annotations causes a segmentation fault.

In Eclipse Theia versions up to and including 1.69.0, opening a folder starts source control integration without requiring the user to trust the folder first. This affects applications built on Theia that include the git integration, such as the Theia IDE. Both Theia's own @theia/git extension and the builtin VS Code git extension run git commands such as git status as soon as a repository is detected. Since git honors repository-local configuration, a folder containing an attacker-controlled .git/config with core.fsmonitor (or a comparable hook-like setting) causes the configured command to be executed. The configuration can be delivered by burying a bare repository inside a regular repository (OVE-20210718-0001), so cloning an attacker-supplied repository and opening it in a Theia-based application is sufficient to execute arbitrary commands with the privileges of the user, without any confirmation prompt.

As of 1.70.0, plugins that declare capabilities.untrustedWorkspaces.supported: false, which includes the builtin git extension, are no longer loaded or activated in an untrusted workspace, and the deprecated @theia/git extension has been removed, so no git command is executed against an untrusted folder.

A flaw was found in Undertow, an HTTP server, within its HTTP response header writing path. The writeString() method performs a silent narrowing cast from 16-bit Unicode characters to 8-bit bytes when writing HTTP response header values. A remote attacker can exploit this by supplying specific Unicode characters in user-controlled input that an application places into response headers. This can lead to the truncation of these characters into ASCII control characters or special symbols, potentially resulting in limited integrity impact or information disclosure if the application does not properly sanitize user input.

In Eclipse RDF4J, several XML parser entry points do not fully restrict XML External Entity (XXE) processing when parsing untrusted XML-based RDF data or query results, permitting DOCTYPE declarations, external entity references, and external DTD loading. This is due to an incomplete fix for CVE-2018-1000644: the earlier fix did not cover all parser entry points. The issue is resolved in RDF4J 5.3.2, which rejects or disables DOCTYPE declarations, external entities, and external DTD loading by default.

In Eclipse GlassFish versions 8.0.x before 8.0.4, CSRF + SSRF in DownloadServlet ContentSources leaks the admin gfresttoken to attacker-controlled host if the victim is authenticated into the Admin Console -\> full unauthenticated takeover of Eclipse GlassFish domain until the token expires.

In Eclipse Theia versions up to and including 1.73.1, the @theia/filesystem backend exposes HTTP file-download endpoints (GET /file, GET /files/, PUT /files/) that convert a client-supplied URI directly to a filesystem path and stream the file, without confining it to the workspace or any allow-listed root. In browser (non-Electron) deployments the connection token is enforced only on WebSocket upgrades; the HTTP middleware in @theia/core re-issues the cookie and calls next() without rejecting tokenless HTTP requests, so these endpoints are reachable without a valid token. As a result an unauthenticated client can read any file readable by the backend process, including files outside the opened workspace (for example /etc/hosts, SSH keys, or tokens). Electron mode uses a separate ElectronSecurityToken and is not affected via this path.

In Eclipse Theia versions up to and including 1.73.1, the @theia/filesystem backend binds POST /file-upload in every filesystem-enabled deployment. The handler takes an attacker-supplied absolute path from the multipart uri field and calls fs.move(tmp, target, { overwrite: true }) with no workspace confinement and no authentication. In browser (non-Electron) deployments the connection token is enforced only on WebSocket upgrades; the HTTP middleware in @theia/core re-issues the cookie and calls next() without rejecting tokenless HTTP requests. Because multipart/form-data is a CORS-safelisted request type, a cross-origin web page can trigger the write with no preflight and no credentials, resulting in an unauthenticated arbitrary file write outside the workspace to any absolute path the backend process can write. This can escalate to remote code execution, for example by overwriting a startup-executed file such as ~/.bashrc. Electron mode uses a separate ElectronSecurityToken and is not affected via this path.

In Eclipse Theia versions 1.66.0 and up until including 1.73.1, the @theia/plugin-ext backend exposes the /hostedPlugin/:pluginId/:path() HTTP endpoint, which resolves the requested file path with path.resolve(localPath, filePath) without verifying that the resolved path stays within the plugin's directory. An unauthenticated network attacker can send percent-encoded ../ sequences (%2e%2e%2f) that decode into the path parameter and escape the plugin directory, allowing arbitrary files readable by the Theia backend process to be retrieved. Plugin IDs are derived deterministically from a plugin's publisher and name, so built-in plugins serve as reliable anchors that require no prior knowledge of the target system.

In Eclipse Theia versions 0.7.0 and up until including 1.73.1, the PreferenceUtils.merge function in @theia/core recursively merges preference values without rejecting prototype-related keys (proto, constructor, prototype). Because this function is invoked by PreferenceServiceImpl.doResolve for every preference resolution across scopes (default, user, workspace, folder), a crafted preference value in a workspace settings file (.theia/settings.json or .vscode/settings.json) can pollute Object.prototype when the user opens the workspace, potentially altering application logic across the Theia process.

In Eclipse Accessibility Tools Framework (ACTF) versions up to 1.6.0 (including source code versions up to v20260630 and ACTF based application miChecker versions up to 3.1.0), it has been identified that an XML External Entity (XXE) vulnerability exists.

If this vulnerability is exploited, a malicious third party could gain access to local resources or internal network resources via computer running applications that use Eclipse ACTF, including miChecker.

In Eclipse Milo versions 0.6.0 through 1.1.4, OPC UA server diagnostics nodes do not enforce access authorization. An anonymous client can enable diagnostics over a None/None endpoint without a certificate; with a trusted client application certificate over SignAndEncrypt, it can read security diagnostics for other active sessions, exposing usernames, login history, authentication mechanisms, security modes and policies, and public client certificates.