Eclipse
Don't miss out!
Thousands of developers use stack.watch to stay informed.Get an email whenever new security vulnerabilities are reported in any Eclipse product.
RSS Feeds for Eclipse security vulnerabilities
Create a CVE RSS feed including security vulnerabilities found in Eclipse products with stack.watch. Just hit watch, then grab your custom RSS feed url.
Products by Eclipse Sorted by Most Security Vulnerabilities since 2018
By the Year
In 2026 there have been 197 vulnerabilities in Eclipse with an average score of 7.5 out of ten. Last year, in 2025 Eclipse had 49 security vulnerabilities published. That is, 148 more vulnerabilities have already been reported in 2026 as compared to last year. However, the average CVE base score of the vulnerabilities in 2026 is greater by 0.35.
| Year | Vulnerabilities | Average Score |
|---|---|---|
| 2026 | 197 | 7.45 |
| 2025 | 49 | 7.10 |
| 2024 | 23 | 6.72 |
| 2023 | 24 | 6.84 |
| 2022 | 18 | 6.81 |
| 2021 | 35 | 7.12 |
| 2020 | 13 | 7.17 |
| 2019 | 34 | 7.85 |
| 2018 | 15 | 7.76 |
It may take a day or so for new Eclipse vulnerabilities to show up in the stats or in the list of recent security vulnerabilities. Additionally vulnerabilities may be tagged under a different product or component name.
Recent Eclipse Security Vulnerabilities
| CVE | Date | Vulnerability | Products |
|---|---|---|---|
| CVE-2026-111729 | Nov 10, 2026 |
Eclipse Kura 5.6.2 Path Traversal in Command FileUploadIn Kura versions <= 5.6.2, the "Command" file-upload handler at `POST /admin/denali/file/command` extracts a client-supplied ZIP archive into the configured `command.working.directory`. The path-containment check `validateFileName()` compares canonical paths with `String.startsWith()` without appending a trailing path separator, so an entry that canonicalises to a sibling directory sharing the same string prefix (e.g. `/tmpevil/x` when the intended directory is `/tmp`) is accepted. The handler then calls `parent.mkdirs()` and `new FileOutputStream(newFile)`, creating directories and writing attacker-controlled bytes outside the intended extraction root. The command service is disabled by default since Kura 4.0.0 [1]. The issue does not apply when the command service is disabled. The caller must be authenticated with `rest.command` permission. |
Kura
|
| CVE-2026-97401 | Nov 10, 2026 |
Eclipse Kura <=5.6.2 CommandCloudApp ZIP Extraction Path TraversalIn Kura versions <= 5.6.2, `CommandCloudApp.execute()` extracts a caller-supplied ZIP archive into a caller-supplied directory inside the Kura JVM process before dispatching the command to the executor service. On a packaged Kura installation the JVM runs as `kurad` with `CAP_DAC_OVERRIDE`, while the configurable "Unprivileged" executor drops to the `kura` user via `su`. A caller with permissions `rest.command` who is intentionally restricted to unprivileged command execution (`privileged.command.service.enable=false`, the default) can therefore set `workingDirectory` to `/` and use the ZIP body to write or overwrite arbitrary files on the device as `kurad`, completely bypassing the unprivileged sandbox the operator selected. The command service is disabled by default since Kura 4.0.0 [1]. The issue does not apply when the command service is disabled. [1] https://github.com/eclipse-kura/kura/blob/f9f969231892769a269876b23f19fa0e8173e3df/kura/distrib/RELEASE_NOTES.txt#L94 |
Kura
|
| CVE-2026-112186 | Nov 10, 2026 |
Eclipse Kura 5.6.2 Service Listing V1 REST API Unlimited JSON DoSIn Eclipse Kura versions 5.4.0 through 5.6.2, the Service Listing V1 REST API read the JSON body of every request into memory, with no limit on its size. The endpoints parse the body before they check whether the caller is authenticated. A remote attacker without valid credentials can therefore send a few dozen large JSON requests at the same time, exhaust the Java heap with an `OutOfMemoryError`, and cause a denial of service. Likewise, a remote attacker, can send a deeply nested JSON request and trigger a `StackOverflowError` because of an unbound recursion in Service Listing V1. |
Kura
|
| CVE-2026-112185 | Nov 10, 2026 |
Eclipse Kura <=5.6.2 Config REST API v2 Auth Bypass & Priv EscIn Eclipse Kura versions 5.1.0 through 5.6.2, the Configuration REST API v2 (org.eclipse.kura.rest.configuration.provider) does not restrict access to the configuration of the UserAdmin persistence component to identities holding the kura.admin permission. An authenticated identity holding only the rest.configuration permission can read the password hashes of all identities, including administrators, which are stored as unsalted SHA-256 digests. The same identity can also modify identities and permission assignments, and restore previous configuration snapshots, which allows escalation to full administrative privileges. The issue is fixed in Eclipse Kura 5.6.3. |
Kura
|
| CVE-2026-97891 | Nov 10, 2026 |
Eclipse Kura 5.6.2 HTTP Session DoS in Web ConsoleIn Eclipse Kura version 5.0.0 to 5.6.2, the Web Console allocates a new HTTP session for every request to its built-in authentication endpoints (/admin/auth, /admin/login/password, /admin/login/cert) before checking the HTTP method, parsing the request, or validating any submitted credentials, and does not limit how many such sessions can be allocated. An unauthenticated client that sends requests to these endpoints without honoring the returned session cookie can cause the server to allocate an unbounded number of sessions, exhausting the JVM heap and crashing the Kura process. |
Kura
|
| CVE-2026-97402 | Nov 10, 2026 |
Eclipse Kura 5.6.2 iBeacon/Eddystone Scanner DoS via BLE AD lengthIn Eclipse Kura versions 3.1.0 to 5.6.2, the iBeacon and Eddystone advertisement decoders wrongly parse the AD-structure length field of an over-the-air BLE advertising payload. Any unauthenticated attacker within BLE radio range can broadcast a two-byte advertising payload that drives the Kura beacon-scanner thread into a tight infinite loop, pinning a CPU core and permanently halting beacon ingestion until the gateway is restarted. To trigger the attack, the iBeacon/Eddystone scanner component should be installed and active. By default the components are not installed or enabled. |
Kura
|
| CVE-2026-112191 | Nov 10, 2026 |
Eclipse Kura 5.6.2 Identity REST API Auth Bypass -> PrivEsc (fixed 5.6.3)In Eclipse Kura versions 5.4.0 through 5.6.2, the Identity REST APIs (identity/v1, and identity/v2 since 5.5.0, provided by org.eclipse.kura.rest.identity.provider) do not check identity and permission management requests against the permissions of the requesting identity. An authenticated identity holding the rest.identity permission, but not kura.admin, can assign any permission to any identity, including kura.admin to itself. It can also change the password of, or delete, identities holding more privileges than its own, including administrators, and create or delete permissions. This allows escalation to full administrative privileges and can lock legitimate administrators out of the device. The issue is fixed in Eclipse Kura 5.6.3. |
Kura
|
| CVE-2026-113422 | Nov 10, 2026 |
Eclipse Kura <=5.6.2 Wire Graph Auth Bypass (REST/UI)In Eclipse Kura versions 5.0.0 through 5.6.2, the Wire Graph update functionality of the Kura Web UI, and the Wire Service REST API v1 (available since 5.1.0, org.eclipse.kura.rest.wire.provider), determine whether a configuration update targets a Wire Component, Driver or Asset from the factory identifier supplied in the request, instead of the actual factory of the existing component. An authenticated identity holding only the Wires management permission (kura.wires.admin for the Web UI, rest.wires.admin for the REST API) can therefore modify the configuration of existing components that are not part of the Wire Graph, including security-relevant ones, or replace existing components. This allows escalation to full administrative privileges and can disrupt the device. Modifying arbitrary components requires at least one Driver to be installed on the device. The issue is fixed in Eclipse Kura 5.6.3. |
Kura
|
| CVE-2026-114359 | Nov 10, 2026 |
Eclipse Kura Unbounded Download/Upload Leads to DoS via Resource ExhaustionEclipse Kura downloads deployment packages (DPs) from a remote URL without any limit on the size of the data it receives. A malicious or compromised HTTP(S) server, or an attacker able to tamper with a plain-HTTP download, can stream an arbitrarily large (or endless) response. Kura writes the response to local storage until the filesystem is full. On gateways the temporary directory is often a RAM-backed tmpfs, so this can also exhaust memory. The result is denial of service of the device: failed configuration persistence, failed logging and possible crashes of the framework or other services. The same missing size limit is present in the REST upload endpoint `POST /deploy/v2/_upload`, which copies the request body to the temporary directory with no limit. Workarounds: only install DPs from trusted HTTPS sources, restrict who can install packages (Web UI `kura.packages.admin` permission, REST `kura.permission.rest.deploy`, cloud DEPLOY-V2 access). |
Kura
|
| CVE-2026-124683 | Nov 09, 2026 |
Eclipse Langium 4.4.0 IndentationAwareLexer/TokenBuilder DoSEclipse Langium versions 3.2.0 through 4.4.0 contain an inefficient algorithmic complexity issue (CWE-407) in the opt-in IndentationAwareTokenBuilder and IndentationAwareLexer. When producing DEDENT tokens, the token builder recomputes line numbers by re-scanning the entire preceding document text. A document whose indentation changes on most lines then takes quadratic time to tokenize. Because tokenization is synchronous, a crafted document of a few hundred kilobytes can block the Node.js event loop for tens of seconds. That causes a DoS for every user served by the same process. Languages built with the DefaultLexer and DefaultTokenBuilder are unaffected. |
|
| CVE-2026-118492 | Nov 09, 2026 |
Eclipse Langium 3.0.0+ XSS in langium-sprotty hoverIn Eclipse Langium versions 3.0.0 and later, the langium-sprotty package does not HTML-escape diagnostic messages before rendering them in the default hover popup provided by `addHoverPopupHandler`. If a Langium grammar allows cross-reference text to contain HTML markup (such as through a STRING terminal), an unresolved cross-reference produces a diagnostic message that includes the literal ref text. When a Sprotty diagram is opened for a malicious source file under these conditions, and a user hovers over the corresponding error marker, attacker-controlled JavaScript can execute in the browser or webview. |
|
| CVE-2026-123870 | Nov 09, 2026 |
Otterdog Webapp Python eval() RCE via Missing HMAC CheckThe otterdog webapp evaluates a format-string built from the incoming GitHub webhook JSON body using Python's eval(). When the GITHUB_WEBHOOK_SECRET configuration value is unset or empty (the code default is None), the HMAC signature check is skipped entirely, allowing an unauthenticated network client to reach the eval() sink with attacker-controlled input and execute arbitrary Python on the webapp host. |
|
| CVE-2026-123059 | Nov 05, 2026 |
Eclipse BaSyx Helm Chart 2.2.0 client secret exposed in ConfigMapIn Eclipse BaSyx Helm Charts version 2.2.0 of the `aas-basyx-v2-full` chart, deployments with the bundled Keycloak enabled store the client secret of the `basyx-technical-user` OAuth2 client in cleartext in a Kubernetes ConfigMap. This client uses the client-credentials grant and its service account holds the realm `admin` role. The chart correctly writes `keycloak.technicalUser.clientSecret` to a Kubernetes Secret, but the template `basyx-keycloak-realm.yaml` also substitutes the same value into the Keycloak realm-import JSON, which is stored in the ConfigMap `<keycloak.fullnameOverride>-realm`. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the client secret from the ConfigMap. They can then exchange it at the Keycloak token endpoint for an access token with the `admin` role. That token grants full create, read, update, delete and execute rights on all BaSyx repositories and registries in the deployment. The bundled Keycloak is disabled by default. No fixed release of the `aas-basyx-v2-full` chart exists. Affected users should migrate to the `basyx` chart, or deploy without the bundled Keycloak and rotate the `basyx-technical-user` client secret. |
|
| CVE-2026-123047 | Nov 05, 2026 |
Eclipse BaSyx Chart 3.0.0rc.13.12.1 Cleartext Keycloak PasswordsIn Eclipse BaSyx Helm Charts versions 3.0.0-rc.1 to 3.12.1 of the `basyx` chart, deployments with the bundled Keycloak enabled store the passwords of the Keycloak users that the chart creates in cleartext in a Kubernetes ConfigMap. The template `keycloak-init-config.yaml` rendered `keycloak.initialization.users`, including each user's `credentials[].value`, as `users.json` into the persistent ConfigMap `<release>-basyx-keycloak-init-config`. By default this includes the bootstrap administrator user. That user holds the `admin` role and has a non-temporary password. A principal that can read ConfigMaps but not Secrets in the release namespace, such as a holder of the built-in Kubernetes `view` ClusterRole, can read the password from the ConfigMap and log in to Keycloak as this user. The resulting token carries the `admin` role, which the default BaSyx ABAC rules map to full rights on all BaSyx APIs in the deployment. The bundled Keycloak is disabled by default. The issue is fixed in version 3.12.2 of the `basyx` chart, which moves the initialization users to the Keycloak credentials Secret. Affected users should upgrade and change the passwords of users that were created through the chart. |
|
| CVE-2026-120421 | Nov 04, 2026 |
Eclipse Mojarra 2.2-5.0.0-M11: Reflected XSS via unencoded URL client window ID (CSP bypass)In Eclipse Mojarra versions 2.2.0 through 4.0.28, 4.1.0 through 4.1.19, and 5.0.0-M1 through 5.0.0-M11, when URL client window mode is enabled (`jakarta.faces.CLIENT_WINDOW_MODE=url`), the client window id from the `jfwid` or `jakarta.faces.ClientWindow` request parameter is appended to generated URLs without URL-encoding. `h:button` renders such a URL into a JavaScript string literal, which allows reflected cross-site scripting. With `com.sun.faces.enableCspNonce=true`, the injected script runs on page load inside the nonce script element, bypassing the Content Security Policy. |
Mojarra
|
| CVE-2026-118487 | Nov 03, 2026 |
CVE-2026-118487: Vert.x FP-DS via unlimited buffer (4-4.5.35,5-5.2.2)In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], the `FrameParser` in vertx-stomp creates a `RecordParser` without setting `maxRecordSize`, so any peer that streams bytes continuously without a newline character causes the parser to accumulate data indefinitely. Both the STOMP server and the STOMP client are affected: a malicious server can exploit this against a connecting client, and a malicious client can exploit this against a server before or after authentication. Sustained byte streaming exhausts JVM heap memory, crashing the affected process and causing a complete denial of service. |
Vert X
|
| CVE-2026-118488 | Nov 03, 2026 |
Vert.x OOM & Infinite Loop via EOL Lines (4.5.35/5.2.2)In Eclipse Vert.x versions [4.0.0, 4.5.35] or [5.0.0, 5.2.2], when a malicious server keeps sending bytes on an EOL-terminated line (not length-prefixed, for example a simple string [1]), we'll keep growing the buffer without bounds, eventually leading to an OOM. We need to have a configurable limit for EOL-terminated lines. If a malicious server sends a specially crafted RESP response (for example a bulk string [2] with missing CRLF trailer), the parser enters an infinite loop where it keeps parsing the same buffer and pushing the same response to the caller, which may lead e.g. to an OOM if the consumer just buffers the responses. We must fix the parser to avoid this infinite looping. |
Vert X
|
| CVE-2026-118489 | Nov 03, 2026 |
Eclipse Vert.x 4.x/5.x CachingWebClient Shared Cache DisclosureIn Eclipse Vert.x versions [4.0.0,4.5.35] or [5.0.0,5.2.2], when one `CachingWebClient` is shared across users the documented pattern of a per-user `WebClientSession` over a shared caching client a response that is specific to one user but is cacheable and not marked `private`/`no-store` is stored in the client-level shared cache tier and served to other users requesting the same URL. A later user's session, or an anonymous caller through the same client, can receive an earlier user's response. Depending on the response this discloses authenticated content or a session cookie, the latter enabling session fixation or hijacking. |
Vert X
|
| CVE-2026-89295 | Nov 03, 2026 |
Eclipse Mnestix AAS Generator <1.5.0 DoS via Unbounded CountIn Eclipse Mnestix AAS Generator versions 0.1.0 up until but excluding 1.5.0, a practical upper bound on the client-supplied count parameter of the GET /api/v1/IdGenerator/submodelIds/{count} and GET /api/v2/IdGenerator/submodelIds/{count} endpoints is not enforced. The service generates and retains identifiers in memory before returning a response. A remote unauthenticated attacker can submit a large count to cause excessive memory consumption, potentially resulting in denial of service. Exploitation requires network access to the endpoint and successful retrieval of the ID-generation configuration from the configured backend repository. |
|
| CVE-2026-89293 | Nov 03, 2026 |
Eclipse Mnestix Browser <=2.3.0 Unauth Priv EscalationIn Eclipse Mnestix Browser versions 1.2.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to perform actions that are only allowed to be executed by an authorized Mnestix user, like changing the Infrastructure settings or calling the connected and authenticated Mnestix AAS Generator backend. |
|
| CVE-2026-89292 | Nov 03, 2026 |
Unauthenticated exfiltration of MNESTIX_BACKEND_API_KEY in Mnestix Browser 1.6-2.3In Eclipse Mnestix Browser versions 1.6.0 up until but excluding 2.3.0 it was possible for an unauthenticated attacker to exfiltrate the MNESTIX_BACKEND_API_KEY for all configured Infrastructures. |
|
| CVE-2026-92610 | Nov 03, 2026 |
EsMF SDK Py Aspect Loader 2.1.2-2.2.1 Directory Traversal via URNIn esmf-sdk-py-aspect-model-loader versions 2.1.2 to 2.2.1, the Aspect Model loader resolves cross-file model references by extracting the third and fourth colon-separated components of any urn:samm: namespace declared in a parsed Turtle file to build a directory to scan. A model file containing @prefix x: <urn:samm:../../../foo:bar#> or @prefix x: <urn:samm:/abs/path:bar#> causes the loader to glob and parse *.ttl files from arbitrary directories outside the intended models root, merging their contents into the returned graph. |
|
| CVE-2026-113421 | Nov 03, 2026 |
Eclipse ThreadX 6.0.1-6.5.2.202603 PrivEsc via Unrevoked TraceBufferFull CallbackIn Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, ThreadX Modules does not revoke a module's trace-buffer-full callback when the module is stopped and unloaded. With event tracing enabled and a kernel-owned trace buffer still active, a later buffer wrap invokes the callback from privileged thread context after the module's code has been released, so a user-mode module can have its code run with kernel privileges after unload, or, once the memory is reused, redirect control flow or cause a fault. |
Threadx
|
| CVE-2026-115231 | Nov 03, 2026 |
Eclipse ThreadX ModMgr Priv Esc via forged callback (6.0.1-6.5.2.202603)In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager lets a user-mode, memory-protected module post a forged callback request to another module's callback request queue. The receiving module's callback thread calls the function pointer in the request without checking that the Module Manager sent it, so the attacker's code runs with the receiving module's privilege; when that module runs in privileged mode, a user-mode module gains privileged execution. |
Threadx
|
| CVE-2026-115215 | Nov 02, 2026 |
Eclipse ThreadX NetX Duo DTLS DoS via Session Pool Exhaustion (v6.0-6.5.2)In Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, the NetX Secure DTLS server allocates a session from its fixed session pool for the first datagram from any unrecognised address and port, before the cookie exchange, and never releases a session whose handshake stalls. A remote, unauthenticated attacker can exhaust the pool with one spoofed datagram per source and deny DTLS service to legitimate clients until the application resets the sessions. |
Threadx
|
| CVE-2026-115403 | Nov 02, 2026 |
Eclipse ThreadX NetX Duo <=6.5.2 NULL Pointer Deref IPv6 Raw SendIn Eclipse ThreadX NetX Duo versions 6.0 through 6.5.2.202603a, built with BSD raw socket and IPv6 support, the IPv6 raw send path uses the destination-table entry it adds without checking that the add succeeded. When the destination table is full and an off-link destination is reached through a default router whose neighbour cache entry is unknown, sending on an IPv6 raw socket with header inclusion dereferences a NULL pointer; a remote sender can fill the table, for example with ICMPv6 Packet Too Big messages, and crash the sending thread. |
Threadx
|
| CVE-2026-115654 | Nov 02, 2026 |
Eclipse ThreadX 6.0.1-6.5.2 Module Manager Thread Control EscalationIn Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager's thread-control services do not check that a thread passed by a user-mode, memory-protected module belongs to that module. Any loaded module can suspend, resume, terminate, reset or re-prioritise application threads and other modules' threads and abort their waits, denying service or changing how the system schedules them. |
Threadx
|
| CVE-2026-115653 | Nov 02, 2026 |
ThreadX 6.5.2.202603 Register Corruption via PendSV Pointer AbuseIn Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the PendSV handler of the Cortex-M module ports saves a preempted user-mode module thread's registers in privileged mode at addresses taken from the thread's stack pointer, without checking that pointer against the thread's stack. A user-mode, memory-protected module can thereby write up to nine words, eight of its choosing, or 25 with floating-point state, into memory immediately below any region it may write, and read back what is stored there. |
Threadx
|
| CVE-2026-114408 | Nov 02, 2026 |
Eclipse ThreadX NetX Duo 6.4.5-6.5.2 ICMPv6 NULL Deref CrashIn Eclipse ThreadX NetX Duo versions 6.4.5.202504 through 6.5.2.202603a, built with IPv6 path MTU discovery, the ICMPv6 Packet Too Big handler uses the destination-table entry it adds without checking that the add succeeded. A sender on the network can fill the destination table with Packet Too Big messages quoting new destinations, after which the next message makes the IP helper thread dereference a NULL pointer, crashing it on targets that fault on address 0 and stopping all network processing. |
Threadx
Threadx Netx Duo
|
| CVE-2026-118052 | Nov 02, 2026 |
Eclipse ThreadX Module Manager Overflow 6.0.1-6.5.2In Eclipse ThreadX versions 6.0.1 through 6.5.2.202603, the Module Manager loaders return an overflow error without releasing the Module Manager mutex when a module preamble declares a data or stack size that overflows the allocation arithmetic. Loading such an image blocks every later module load, start, stop and unload from other threads until the system is reset. |
Threadx
|
| CVE-2026-114278 | Oct 28, 2026 |
Eclipse Che Machine Exec Remote Code Execution via Shell InjectionThe che-machine-exec service constructs a shell command by concatenating user-controlled input (the username and namespace fields from the /exec/init and /exec/config JSON endpoints) into a double-quoted sh -c "echo "..." > ..." invocation without any escaping. When che-machine-exec is run with authentication disabled (its default), any network-reachable attacker can achieve remote code execution in containers che-machine-exec is configured to access, via shell command substitution ($(...) or backticks). |
Che
|
| CVE-2026-115408 | Oct 27, 2026 |
crypto11 Go library <2.0.0-rc9 (>=2.0.0-rc3) MLKEM key pair lookup bypassIn `github.com/eclipse-keypont/crypto11/v2` versions `>= 2.0.0-rc3, <= 2.0.0-rc8`, the ML-KEM key-pair lookup functions (`FindMLKEMKeyPair`, `FindMLKEMKeyPairs`, `FindMLKEMKeyPairsWithAttributes`) locate the public half of an ML-KEM key pair by `CKA_ID`/`CKA_LABEL` and never verify it against the private key. In addition, the "ID only" fallback search runs even when the private key has no `CKA_ID`, so the search template reduces to the public-key class and the ML-KEM key type and the first ML-KEM public key on the token is returned. `Encapsulate()` on the resulting key pair encrypts the fresh shared secret to that key, so its owner not the holder of the private key the caller looked up can recover the secret. An attacker who can open an unauthenticated session on the token and plant a public `CKK_ML_KEM` object carrying the victim's `CKA_ID`/`CKA_LABEL` receives the shared secrets for encapsulations performed through the substituted key pair, compromising the confidentiality of those secrets and of everything protected by keys derived from them. The v1 module paths have no ML-KEM support and are not affected. |
|
| CVE-2026-113644 | Oct 27, 2026 |
Eclipse ioFog iofogctl 1.0.0-3.9.1 Command Injection (fixed in 3.9.2)In Eclipse ioFog iofogctl versions 1.0.0 through 3.7.0 and 3.8.0-rc.1 through 3.9.1, the provisioning key and CA certificate returned by the Controller API are concatenated into shell commands (`edgelet provision` and `edgelet config cert` on supported releases; `iofog-agent provision` and `iofog-agent cert` on older releases) that run over SSH on a remote agent host and via a local shell. A party who can change that API response can include shell metacharacters and cause the operator's CLI to run additional commands on the agent host when the operator deploys or attaches an agent. This is fixed in version 3.9.2. |
|
| CVE-2026-115216 | Oct 27, 2026 |
Eclipse ioFog Operator <3.9.2 TLS cert verification bypassIn Eclipse ioFog Operator versions 3.8.0 before 3.9.2, TLS certificate verification is disabled when the operator contacts the Controller API and when it logs in to an external OIDC issuer. An on-path attacker can present any certificate, capture the OAuth client secret (external mode) or the Controller bootstrap admin password (embedded mode with Controller HTTPS enabled), and supply the access token the operator stores for later Controller API calls. v3.8 removed Keycloak. The exposed credential is not a Keycloak realm-admin secret. |
|
| CVE-2026-89320 | Oct 23, 2026 |
Gose HmacShaCryptor.Hash flaw: constant MAC breaks JWE integrity`HmacShaCryptor.Hash` never hashed its input. For any input it returned `HMAC_K("")` the MAC of the empty message under the key. Every AES-CBC-HMAC JWE produced or verified by gose therefore carried an authentication tag that is constant per key and independent of the message, removing ciphertext integrity entirely. |
|
| CVE-2026-89319 | Oct 23, 2026 |
Unbounded Alloc & Slice-Bound Panic in JweDirectDecryptorBlock (Eclipse)`JweDirectDecryptorBlock.Decrypt` read a 64-bit plaintext length from the `_thales_aad` protected-header field and used it without any validation. A truncated field panics `binary.BigEndian.Uint64`, an oversized value drives an unbounded allocation, and a value larger than the decrypted block panics with a slice-bounds error. |
|
| CVE-2026-89318 | Oct 23, 2026 |
Eclipse Go JWE Decryptor Crashes on Bad IV (NonceSize)`JweRsaKeyEncryptionDecryptorImpl.Decrypt` passed the JWE's initialization vector to `cipher.AEAD.Open` without checking its length. The Go standard library **panics** rather than returning an error when a GCM nonce is not exactly `NonceSize()` bytes, so a JWE carrying a wrong-sized IV crashes the decrypting goroutine. |
|
| CVE-2026-89317 | Oct 23, 2026 |
gose Unvalidated JWS crit Header (Reject Violation)gose parsed the JWS `crit` header into `JwsHeader.Crit` and then never read it. RFC 7515 §4.1.11 requires a recipient to reject a JWS whose listed critical extension parameters it does not understand. gose implements no header extensions, so every token carrying a non-empty `crit` should have been rejected and none were. |
|
| CVE-2026-89316 | Oct 23, 2026 |
Eclipse JWE LoadPublicKey panics on nonEC alg with EC JWK`LoadPublicKey` resolved an EC key's curve with an unchecked type assertion, `algToOptsMap[alg].(*ECDSAOptions)`. A JWK declaring `"kty":"EC"` together with a non-EC `"alg"` which RFC 7517 §4.4 permits reaches that assertion and **panics**. |
|
| CVE-2026-89315 | Oct 23, 2026 |
Go JWT: MarshalJSON panic on invalid claim names via reflect.StructOf`JwtClaims.MarshalJSON` built a Go struct at runtime with `reflect.StructOf`, synthesising a field named `"A" + claimName` for each untyped claim. `reflect.StructOf` **panics** when a field name is not a valid Go identifier, or when it duplicates another field. Both conditions are reachable from ordinary JWT claim names. |
|
| CVE-2026-89314 | Oct 23, 2026 |
Eclipse MicroProfile JWT: JWK key_ops Duplicate Check OOM via Quadratic`jwkFields.CheckConsistency` detected duplicate `key_ops` entries with a pairwise nested loop, making validation cost grow with the **square** of the entry count. Because the check runs on every JWK and JWKS unmarshal, a modestly sized but hostile JWKS document could occupy a CPU core for many seconds. |
|
| CVE-2026-89313 | Oct 23, 2026 |
Eclipse JwksTrustStore Missing Key Handling Exposes Wrong JWKS Key`JwksTrustStore.Get` assigned each parsed key to the function's **named return value** while refreshing the JWKS cache. When the requested `kid` was not present, the trailing naked `return` handed the caller the last key in the JWKS document together with a `nil` error a confidently wrong answer instead of "not found". |
|
| CVE-2026-89312 | Oct 23, 2026 |
Go Stdlib AesGcmCryptor.Panic on WrongSized GCM Nonce`AesGcmCryptor.Open` passed a caller-supplied nonce straight to `cipher.AEAD.Open` without checking its length. The Go standard library **panics** rather than returning an error when a GCM nonce is not exactly `NonceSize()` bytes, so a JWE carrying a wrong-sized IV crashes the decrypting goroutine. |
|
| CVE-2026-111075 | Oct 21, 2026 |
Eclipse OpenJ9 JITServer <0.63.0 Remote DoS via DataDescriptor underflowIn Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component fails to perform cross-field validation on attacker-controlled `_size`, `_paddingSize`, and `_dataOffset` fields during `DataDescriptor` message deserialization. An unauthenticated remote attacker can send a crafted network payload that triggers an unsigned integer underflow in `DataDescriptor::getPayloadSize()` and `DataDescriptor::getNextDescriptor()`. This results in an out-of-bounds heap read and an immediate process crash (SIGSEGV), causing a denial of service. |
Openj9
|
| CVE-2026-111074 | Oct 21, 2026 |
Eclipse OpenJ9 JITServer <0.63.0 Remote DoS via Integer OverflowIn Eclipse OpenJ9 versions prior to 0.63.0, the JITServer component is vulnerable to a pre-authentication remote denial of service. When processing the initial 4-byte length field of an incoming TCP connection, an integer overflow in `MessageBuffer::computeRequiredCapacity()` causes the receiving compilation worker thread to enter an infinite loop consuming ~100% CPU. An unauthenticated remote attacker can exploit this by opening a small number of crafted TCP connections to exhaust the entire worker thread pool, silently halting compilation services for all connected client JVMs. |
Openj9
|
| CVE-2026-93003 | Oct 20, 2026 |
Eclipse WTP HTTP server header injection via request bodyThe Web add-on's HTTP server searches the entire request packet for header fields instead of stopping at the end of the header section. A header field name placed in the request body is therefore reported to the server as though it were a header, which lets a client control request framing decisions it should not be able to reach. |
Threadx Netx Duo
|
| CVE-2026-95107 | Oct 20, 2026 |
ThreadX Module Manager Buffer Overwrite via Object Size MiscalcA ThreadX module chooses `object_size` when it calls `txm_module_object_allocate`. The Module Manager adds its own 16-byte private header to that size and asked the object pool for the result **without checking the addition**. A size near the top of a `ULONG` wrapped, the pool served a block far smaller than the header, and the manager then wrote the header past the end of it and into the neighbouring byte-pool block. |
Threadx
|
| CVE-2026-94202 | Oct 20, 2026 |
ThreadX Module Manager OOB Read in Block-Pool DispatcherThe Module Manager's block-pool create dispatcher proved that two `ALIGN_TYPE` words of the extra-parameter array a memory-protected module supplies lay inside the module's data, and then used indices 0 through 3 of that array. One of the two unproved words is read by the dispatcher's own buffer check, which takes index 1 as the pool start and index 2 as the length to range-check it over. So the out-of-bounds read is performed by the validation code itself, before the kernel service is reached, and the size the caller's pool start is then validated against is a word the manager has not proved the module owns. The other unproved word is read when the service's argument list is built. Vulnerable function: `_txm_module_manager_tx_block_pool_create_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. |
Threadx
|
| CVE-2026-95108 | Oct 20, 2026 |
ThreadX ModuleMgr memory leak via _txm_module_manager_tx_thread_delete_dispatchOne logical thread of a user-mode ThreadX module costs the Module Manager's shared object pool two allocations, not one. The module asks for a `TX_THREAD` control block through `txm_module_object_allocate`; `_txm_module_manager_thread_create` then takes a second allocation of `TXM_MODULE_KERNEL_STACK_SIZE` bytes for the privileged kernel stack that thread's system calls run on, and records it in the control block. Both come from `_txm_module_manager_object_pool` and both are linked onto the module's allocation list. The Module Manager's thread-delete dispatcher released only the first. The kernel stack stayed allocated until the whole module was stopped, so a module that creates, terminates and deletes threads in a loop every state transition valid, every service returning `TX_SUCCESS` removed a fixed block from a finite pool shared by the manager and by every other loaded module, on every cycle, for as long as it stayed loaded. Once the pool is exhausted, no memory-protected module can create any kernel object and no user-mode module thread can be created anywhere in the system. Vulnerable function: `_txm_module_manager_tx_thread_delete_dispatch`, in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`. |
Threadx
|
| CVE-2026-94024 | Oct 20, 2026 |
ThreadX Module Manager Buffer Overflow in Privileged ModeThe Module Manager's object lookup validated one byte of a memory-protected module's search name and then walked as much of it as the module declared, in privileged mode, with the kernel's preemption count raised. Both lookup dispatchers are affected: the recommended `txm_module_object_pointer_get_extended` is handed a length and does not use it to bound the buffer, and the deprecated `txm_module_object_pointer_get` supplies the largest value a `UINT` can hold, so it removes the bound rather than lacking one. A module can make the walk unbounded without knowing anything about the memory it reaches, and where the walk reaches memory a privileged read cannot take, the resulting fault leaves the kernel unable to preempt for the rest of the system's life. Vulnerable functions: `_txm_module_manager_txm_module_object_pointer_get_dispatch`, `_txm_module_manager_txm_module_object_pointer_get_extended_dispatch` (both in `common_modules/module_manager/inc/txm_module_manager_dispatch.h`) and `_txm_module_manager_object_name_compare` (`common_modules/module_manager/src/txm_module_manager_util.c`). |
Threadx
|