In Eclipse Jetty, across various versions of jetty-security, and jetty-eeN-security, two or more security constraints with the same http-method-omission set, and no url-patterns, are not combined properly per Jakarta Servlet Spec.

Resulting in later http-method-omission sets overriding previous constraints with the same http-method-omission set.

Eclipse Jetty's SessionAuthentication retains authentication credentials in a serializable object. When the credentials contain a plaintext password and the authenticated session is persisted to a session data store, the password may consequently be written to persistent storage in plaintext.

An attacker with sufficient privileges to read the persisted session data may obtain the plaintext passwords of authenticated users.

In Eclipse Jetty, across various versions of jetty-server, and jetty-proxy, the host whitelist/blacklist is case-sensitive, and would allow hosts through that only differ by case.

In Eclipse Jetty, across various versions of jetty-annotations, and jetty-eeN-annotations, the Jakarta Spec authoritative url-pattern rules for mixed @ServletSecurity annotation, and web.xml defined security-constraint on the same url-pattern were not being applied if the web.xml had more than 1 url-pattern for a servlet, and had a security-constraint applying to only some of those url-pattern definitions.

In Eclipse Jetty, HttpClient may receive a redirect of the form:

/secure/../evil

If an attacker is able to control the redirects, then HttpClient matches authentication credentials against /secure rather than normalizing the path to /evil, and will therefore follow the redirect sending the Authorization header for /secure to /evil.

This also mean that the attacker must have an evil application deployed on the same domain as the target.

In Eclipse Jetty, TryPathsHandler and TryFilesFilter can be configured to forward requests to template URIs such as index?p=$path, where $path is the request path in context.

However, URI paths may contain characters that are reserved in URI queries so that a path of /s&a=1 when applied to the template becomes index?p=/s&a=1, which is interpreted as 2 query parameters: p=/s and a=1, rather than just one query parameter p whose value is /s&a=1.

In Eclipse Ditto versions 3.6.0 to 3.8.13 and 3.9.0 to 3.9.7, the Ditto Explorer UI loads its complete environment configuration, including the Ditto API URI and the OpenID Connect (OIDC) provider settings, from an arbitrary cross-origin URL supplied in the environmentsURL query parameter. It adopts this configuration without user confirmation and persists it in the browser's localStorage. A crafted link can therefore set an attacker-controlled OIDC authority with autoSso enabled. The UI then automatically starts a login at the genuine identity provider but exchanges the returned authorization code together with its PKCE codeverifier at an attacker-controlled token endpoint. This lets the attacker redeem the code for the victim's access and refresh tokens. Alternatively, an attacker-controlled apiuri causes the UI to send the victim's bearer token or Basic credentials to the attacker. Because the configuration is persisted, later visits to the UI without the crafted link repeat the token theft. In versions 3.9.0 to 3.9.7, the Swagger UI OIDC integration of the Helm chart and the Docker Compose deployment is affected in the same way, but requires the user to start the login. The issue is fixed in 3.8.14 and 3.9.8.

In Eclipse Che versions 7.29.0 and later, the GET /api/scm/resolve and POST /api/factory/resolver endpoints pass an attacker-controlled URL to URLFetcher.fetch(), which calls new URL(url).openConnection() with no scheme or host allow-list and returns the response body to the caller. Any authenticated Che user can read arbitrary local files via the file:// scheme (including the pod's Kubernetes service-account token at file:///var/run/secrets/kubernetes.io/serviceaccount/token), reach internal HTTP services and cloud instance metadata endpoints (169.254.169.254), and have their stored SCM personal access token attached as an Authorization header to a host of their choosing. The same credential-forwarding behavior also fires when a victim opens a workspace from a malicious devfile whose parent.uri points to an attacker-controlled server, enabling exfiltration of the victim's SCM PAT without direct API access. No fix is available.

MQTT WebSocket setter ABI mismatch may disclose memory or cause a crash

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.