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

Eclipse Jetty55 vulnerabilities
Jetty is a HTTP Server and Servlet Container

Eclipse Threadx26 vulnerabilities

Eclipse Openj925 vulnerabilities

Eclipse Mosquitto21 vulnerabilities

Eclipse Theia19 vulnerabilities

Eclipse Glassfish15 vulnerabilities

Eclipse Threadx Netx Duo14 vulnerabilities

Eclipse Vert X11 vulnerabilities

Eclipse Omr7 vulnerabilities

Eclipse Open Vsx7 vulnerabilities

Eclipse Che6 vulnerabilities

Eclipse Kura6 vulnerabilities

Eclipse Mojarra4 vulnerabilities

Eclipse Parsson3 vulnerabilities

Eclipse Jgit3 vulnerabilities

Eclipse Equinox3 vulnerabilities

Eclipse Wakaama3 vulnerabilities

Eclipse Rdf4j3 vulnerabilities

Eclipse Cyclone Data Distribution Service3 vulnerabilities

Eclipse Dataspace Components2 vulnerabilities

Eclipse Target Management1 vulnerability

Eclipse Ditto1 vulnerability

Eclipse Edc Connector1 vulnerability

Eclipse Jakarta Mail1 vulnerability

Eclipse Nextx Duo1 vulnerability

By the Year

In 2026 there have been 137 vulnerabilities in Eclipse with an average score of 7.4 out of ten. Last year, in 2025 Eclipse had 49 security vulnerabilities published. That is, 88 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.31.

Year	Vulnerabilities	Average Score
2026	137	7.41
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-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-93003	Oct 20, 2026	Eclipse WTP HTTP server header injection via request body The 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 Miscalc A 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 Dispatcher The 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_dispatch One 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 Mode The 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
CVE-2026-94023	Oct 20, 2026	ThreadX Module Manager Delete Service Privilege Escalation A ThreadX module reaches a kernel object's delete service through the Module Manager's dispatch layer, which asked one question about the pointer: does the object lie outside the module's own code and data. That is the policy for using an object, and using an object a module does not own is supported and intended `txm_module_object_pointer_get_extended` searches the system's created objects by name and hands back objects the application created and objects other modules created, so that a module can send to a shared queue, take a shared semaphore or get a shared mutex. Destroying one of those is not sharing it. A module could name any object it had a pointer to and have the privileged dispatcher delete it.	Threadx
CVE-2026-95109	Oct 20, 2026	ARM Cortex-A7 MMU Buffer Validation Flaw (CVE-2026-95109) The Cortex-A7 MMU Modules port validates a caller-supplied buffer by translating one address the first byte. The common Module Manager hands its range check the module instance, the start address and the complete byte size; the Cortex-A7 implementation discarded the instance and the size and asked the MMU a single question about the start. A memory-protected module therefore passed any range whose first byte was user-readable, however far the rest of it reached. Privileged dispatch code then read or wrote the whole range. Because every protected-module dispatcher that consumes a buffer or an extra-parameter array goes through this one macro, the defect is not in any individual service: it is in the primitive all of them rely on.	Threadx
CVE-2026-94192	Oct 20, 2026	ThreadX Module Manager Deallocates Active Kernel Objects DoS A ThreadX module allocates the control blocks of its kernel objects from the Module Manager's object pool, and can ask for that memory back by address with `txm_module_object_deallocate`. The manager released it whatever was in it, including a control block the kernel was still using. Deallocation is not deletion: the object stays on the created list for its type, a thread stays wherever it was on the ready or suspension lists and stays schedulable, and an active timer stays on the timer list. The byte pool is meanwhile free to hand those same bytes to the next allocation.	Threadx
CVE-2026-92843	Oct 20, 2026	NetX Secure TLS 1.3 CertMsg Parser UB -> Heap OOB Read (preauth) A missing bounds check in the TLS 1.3 Certificate-message parser of NetX Secure lets a malicious TLS 1.3 server trigger an unsigned-integer underflow and a subsequent heap out-of-bounds read in any peer that processes a remote Certificate message. It is reachable pre-authentication, during the normal handshake, before certificate verification completes.	Threadx Netx Duo
CVE-2026-94018	Oct 20, 2026	Eclipse Jetty: Uninit Ptr Deref via PUT Content-Length Underflow The Web add-on's HTTP server dereferences and releases an uninitialized pointer when it detects a `Content-Length` underflow while processing a `PUT` request. The condition is reachable by an unauthenticated remote client with a single malformed request.	Threadx Netx Duo
CVE-2026-92853	Oct 20, 2026	NetX Secure TLS1.3 Cert Parser Buffer Overflow via Zero-Length Message The TLS 1.3 Certificate-message parser in NetX Secure decrements the message length to skip a context byte without first establishing that the message has a byte to skip. A zero-length Certificate message therefore wraps the unsigned length to `0xFFFFFFFF`, which makes the bounds check that follows vacuous and sends the parser reading past the session packet buffer. The trigger is a four-byte handshake header and requires no cryptographic validity. It is reachable pre-authentication.	Threadx Netx Duo
CVE-2026-93475	Oct 20, 2026	NetX Secure OOB Write via oversized RSA modulus in X.509 parsing The X.509 parser in NetX Secure accepts an RSA public key of any size, but every signature-verification path decrypts into fixed-size buffers dimensioned for the `NX_CRYPTO_MAX_RSA_MODULUS_SIZE` default of 4096 bits. A certificate carrying a larger modulus drives an out-of-bounds write past a file-scope static during ordinary certificate-chain verification. It is reachable pre-authentication. The issuer used for the crypto operation is looked up in the remote, peer-supplied store before the trusted store, so the attacker supplies the oversized key themselves as an intermediate in the chain they present. It triggers on a TLS or DTLS client verifying a malicious server's chain, and on a server performing client-certificate authentication.	Threadx Netx Duo
CVE-2026-91057	Oct 20, 2026	Overread in GEF MultiLine TextView `_gx_multi_line_text_view_display_info_get()` reads one byte past the end of the application's text buffer when the string it is given ends with a carriage return (`\r`). The over-read can also cause callers to advance their index past the end of the string, producing a second over-read in `_gx_multi_line_text_view_string_total_rows_compute()` and a row of text that is not in the source.	Threadx
CVE-2026-92454	Oct 20, 2026	Buffer Overread + Infinite Loop in GUIX JPEG Decoder (GX_SOFTWARE_DECODER_SUPPORT) The GUIX software JPEG decoder reads four kinds of marker segment without checking that each is long enough to hold what it reads. A truncated segment is therefore read past the end of the caller's image buffer. Separately, a zero chroma sampling factor makes the block decode loop non-terminating. Both reproduce in the default configuration, in which `GX_SOFTWARE_DECODER_SUPPORT` is enabled.	Threadx
CVE-2026-91059	Oct 20, 2026	GUIX JPEG Decoder Buffer Overread via SOF0 After SOS The GUIX JPEG software decoder enforces no ordering on JPEG markers. A file that places a second `SOF0` frame header after `SOS` re-runs the frame header parser after the output buffer has already been allocated and its geometry latched. The decoder returns `GX_SUCCESS` and publishes a `GX_PIXELMAP` whose reported dimensions and `data_size` exceed the allocation behind it. Any consumer that trusts the returned structure reads out of bounds, including GUIX's own display drivers, reached through the ordinary draw path. Reproduces in the shipped default configuration; `GX_SOFTWARE_DECODER_SUPPORT` is enabled by default.	Threadx
CVE-2026-91189	Oct 20, 2026	GuiX binary loader buffer overflow via malformed glyph range The GUIX binary resource loader never checks that a font page's glyph range is well formed. `gx_page_header_first_glyph` and `gx_page_header_last_glyph` are read verbatim from the file and only the upper bound of `last_glyph` is validated, so a page declaring `first_glyph > last_glyph` makes `last - first + 1` underflow to a very large unsigned count. That count is multiplied by a glyph record size to reserve the load buffer, and the multiply is unchecked, so it wraps to a small value and the loader allocates a buffer far smaller than the data it is about to write. The load pass then recomputes the count in a narrower type and writes attacker-controlled glyph records into the undersized buffer.	Threadx
CVE-2026-92446	Oct 20, 2026	Buffer Overread in GX Binres Loader (gx_binres_* functions) `gx_binres_theme_load()` and `gx_binres_font_load()` take the resource as a bare `GX_UBYTE *` with no length, and `GX_BINRES_DATA_INFO` has no field to carry one. Every read is therefore performed at an offset the file itself chose, against a buffer whose extent the loader does not know. A resource that declares more data than it contains is read past its end, and an offset stored in the file is turned into a pointer without being bounded. This is a distinct defect from GHSA-hgcj-22cg-4hfv, which was an underflowed glyph count. It needs no underflow and no wrapped multiply: a perfectly well-formed, narrow glyph range reaches it.	Threadx
CVE-2026-92449	Oct 20, 2026	GUIX _gx_binres_pixelmap_table_load BOF in Theme Loader: 256KB overflow `_gx_binres_pixelmap_table_load()` in the GUIX binary resource (theme) loader indexes the pixelmap table with a value read verbatim from the resource file and never bounds it against the table size. A crafted theme drives a write of up to roughly 256 KB past the end of the table. The overflowed buffer is allocated by GUIX itself, through `_gx_system_memory_allocator`, rather than supplied by the caller, so the loader corrupts its own arena. The public API `gx_binres_theme_load()` takes no size parameter, so no amount of caller diligence prevents this. Reproduces in the shipped default configuration; `GX_BINARY_RESOURCE_SUPPORT` is enabled by default.	Threadx
CVE-2026-91186	Oct 20, 2026	Eclipse GUIX PNG reader memory overrun via duplicated IHDR chunk The PNG chunk reader has no notion of chunk ordering. It records whether an IDAT has been seen and whether a tRNS has already supplied transparency, but nothing prevents an IHDR being read a second time. A PNG carries exactly one IHDR and it is the first chunk. A file that places a second one after IDAT rewrites the image width, height, bit depth and pixel depth after the decoded-data buffer has already been allocated and filled from the original values. The pass that reverses the PNG row filters then derives its own extent from the new dimensions and walks the old allocation, moving image bytes past the end of it. The buffer is allocated by GUIX rather than supplied by the caller, so the application has no way to size it defensively. The decoder is compiled in by default.	Threadx
CVE-2026-95111	Oct 20, 2026	ThreadX Queue Copy OOB Read Vulnerability A memory-protected ThreadX module's queue request reaches the Module Manager's dispatch layer, which decides how much of the module's buffer the privileged queue copy may touch and hands that extent to the module port's range check. A queue's `tx_queue_message_size` is a count of `ULONG`s and the copy moves that many words, so the extent is `message_size * sizeof(ULONG)` bytes. The front-send dispatcher passed the word count itself. `tx_queue_send` and `tx_queue_receive`, either side of it in the same header, have always multiplied. A source buffer ending `message_size` bytes into memory the module may read was therefore accepted, and `_txe_queue_front_send` then read `message_size * sizeof(ULONG)` bytes from it in privileged mode `3 * message_size` bytes past the end of what the module is allowed to read. The words are written into the queue's message area, so a module that can receive from that queue reads them back.	Threadx
CVE-2026-96402	Oct 20, 2026	USBX Heap Buffer Overread via Malicious MTP/PTP Device A malicious USB MTP/PTP device can cause the USBX host to read past a heap buffer during ordinary object enumeration, leaking adjacent heap contents to the application or faulting on an unmapped page.	Threadx
CVE-2026-97400	Oct 20, 2026	Eclipse OpenJ9 <0.63: Local FS Read & Remote exfil via jdmpview In Eclipse OpenJ9 versions up to 0.63, opening a supplied diagnostic dump bundle with the jdmpview tool, or equivalent DTFJ code, may cause the analyst's machine to read an arbitrary local file named inside the bundle and send its contents to an arbitrary remote host.	Openj9
CVE-2026-96406	Oct 20, 2026	USBX Host Descriptors Overrun via VideoStreaming Descriptor Mismatch A VideoStreaming interface reports the size of its whole class-specific descriptor block in the `wTotalLength` field of its input header. The USBX host recorded that figure and used it as the budget for walking the format, frame and frame-interval descriptors, without holding it against the configuration descriptor actually received. A device that reports a `wTotalLength` larger than the descriptors it supplies therefore had its own claim believed. Once the real bytes ran out the walk kept going, dereferencing the cursor past the end of the configuration buffer, in the host's context, whenever the application queried format or frame data.	Threadx
CVE-2026-96582	Oct 20, 2026	USBX HID Report Descriptor Heap OOB Read on Enumeration A HID report descriptor is a sequence of items, each declaring in its header how many data bytes follow. The USBX host walks that sequence by advancing over each header and parsing the data behind it. The walk checked that an item fitted in the descriptor only after it had advanced past the header and parsed the payload, and the item analysis it relied on never measured the declared sizes against the bytes actually received. A HID peripheral returning a short report descriptor therefore drove a heap out-of-bounds read during ordinary enumeration.	Threadx
CVE-2026-91041	Oct 20, 2026	Eclipse FX_MEDIA OOB heap write via FAT image Mounting an attacker-controlled FAT image with fault tolerance enabled causes an out-of-bounds heap write during log replay. The write is attacker-positioned and attacker-valued, and on a common embedded memory layout it reaches the FX_MEDIA driver callback, giving control of the instruction pointer.	Threadx
CVE-2026-93649	Oct 15, 2026	Adoptium.net URL Redirection via Untrusted link Parameter (CVE-2026-93649) In the Eclipse Adoptium website (adoptium.net), in every deployment built from commit 0b24ea1 (2025-06-18) up to the fix in commit cbb53cf (2026-09-24), the post-download page /[locale]/download takes a download URL from the "link" query parameter and automatically navigates to it with a meta http-equiv="refresh". The URL is checked against a list of trusted prefixes using String.startsWith() on the raw string, while the browser applies RFC 3986 dot-segment normalisation before navigating, so a value such as https://github.com/adoptium/temurin/../../attacker/malware/releases/download/v1/jdk.exe passes the check but resolves to an attacker-controlled repository. A victim who follows a crafted adoptium.net link is shown the genuine "Thank you for downloading Eclipse Temurin" page while their browser downloads a binary of the attacker's choosing
CVE-2026-18659	Oct 15, 2026	Jetty HTTP Method Omission Bypass via Substring Exploit In Eclipse Jetty, across various versions of `jetty-security`, and `jetty-eeN-security`, and `jetty-eeN-servlet`, the Jakarta Spec constraints defined as `http-method-omission` can be bypassed by using substrings of the defined HTTP Methods.	Jetty
CVE-2026-18662	Oct 15, 2026	Jetty HTTP Method Omission Overlap CVE-2026-18662 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.	Jetty
CVE-2026-18661	Oct 15, 2026	Jetty @ServletSecurity vs web.xml security-constraint url-pattern Mixing Bug 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.	Jetty
CVE-2026-77711	Oct 15, 2026	Jetty HttpClient Proxy Auth Leakage via 407 When Jetty's `HttpClient` make a request to a server through a forward proxy, the server may reply with a 407 (Proxy Authentication Required). The client mistakenly interprets the 407 as coming from the proxy, so it re-sends the request with the `Proxy-Authentication` header, which arrives to the server, that now has access to the proxy credentials.	Jetty
CVE-2026-76184	Oct 15, 2026	Eclipse Jetty HttpClient path traversal leaks auth headers via redirect 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.	Jetty
CVE-2026-76182	Oct 15, 2026	Eclipse Jetty TryPathsHandler URI Query Injection 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`.	Jetty
CVE-2026-92877	Oct 12, 2026	JAXB XXE via FEATURE_SECURE_PROCESSING bypass in JAXP The JAXB factory methods historically relied solely on `FEATURE_SECURE_PROCESSING` to prevent XML External Entity (XXE) resolution. On JAXP implementations where that feature alone does not block external entity resolution, an attacker who can get untrusted XML unmarshalled through JAXB can read local files via out-of-band XXE.
CVE-2026-86671	Oct 05, 2026	Eclipse Che 7.29+ Local File Read & Credential Leak via /api/scm/resolve 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.	Che
CVE-2026-90882	Sep 22, 2026	Open VSX CORS flaw leaks user tokens The open-vsx.org deployment returned Access-Control-Allow-Origin reflecting the requesting origin together with Access-Control-Allow-Credentials: true on the authenticated /user/ endpoints. A page on any origin could therefore issue credentialed requests to the service in a logged-in user's browser and read the responses. This exposed /user (login name, avatar, homepage, tokens URL), /user/tokens, /user/namespaces, /user/extensions, /user/search/{name} and /user/namespace/{name}/members, and because /user/csrf was readable the same way allowed the CSRF protection on write endpoints to be defeated. Chaining the two, an attacker page could call /user/token/create and exfiltrate a personal access token carrying publish and delete rights over the victim's namespaces. The headers were emitted by the CDN/edge layer, not by the application: the Open VSX software sets allowCredentials(true) in exactly one place, against a single exact origin derived from ovsx.webui.url, and defines no CORS mapping on /user/ beyond it. No configuration of the software produces origin reflection with credentials.	Open Vsx
CVE-2026-92612	Sep 21, 2026	Eclipse iceoryx2 <v0.8.0: StaticString Exposes Mutable Bytes, UBA In Eclipse iceoryx2 versions greater than v0.8.0, the StaticString exposes its contents as mutable bytes through safe APIs, while String::as_str() 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.
CVE-2025-12999	Sep 21, 2026	OpenVSX Cache Poison via UrlUtil.getBaseUrl Header Injection (0.6.0+) UrlUtil.getBaseUrl builds the absolute URLs in a response download links, icons, asset and API URLs from the X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix request headers, with no check on whether the sender was a trusted proxy, falling back to the client-supplied Host header. Those responses are cached under keys that do not include the host (extension.json since 0.6.0, namespace.details.json since 0.9.0, sitemap since 0.14.5, latest.extension.version.vscode since 0.34.2). A single request carrying a forged header therefore places attacker-chosen URLs into an entry served to every other client for the lifetime of that entry one hour by default, and cluster-wide where ovsx.redis.enabled is set. The VSIX download URL, its signature URL and the public key URL are all derived from the same base URL, so extension signing does not limit the impact: an attacker who poisons an entry supplies the package, the signature over it, and the key used to verify it. Exploitability depends on deployment topology. A server reachable directly by clients, or fronted by a proxy that relays the client's X-Forwarded-Host rather than overwriting it, is exploitable by an unauthenticated remote attacker. A proxy that overwrites the header is not. An unauthenticated attacker can poison Open VSX's per-extension metadata cache with attacker-controlled download, signature, and public-key URLs by supplying a crafted X-Forwarded-Host header, causing downstream VS Code-compatible editors to fetch and install a malicious VSIX. Workarounds (unpatched versions) 1. Configure the reverse proxy to set rather than relay X-Forwarded-Host, X-Forwarded-Proto and X-Forwarded-Prefix note that nginx's $host is the client's Host header and is not a safe value. 2. Ensure the server is not reachable except through that proxy. 3. Flush the caches afterwards; poisoned entries survive the configuration change.	Open Vsx
CVE-2026-92611	Sep 17, 2026	Unauthorized Log Access via Wildcard Skipping in Eclipse Ankaios 0.6.0-1.0.4 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.
CVE-2026-86836	Sep 14, 2026	Eclipse Ankaios <1.0.2 Fifo Poisoning Enables Local Impersonation 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.
CVE-2026-88819	Sep 14, 2026	Siglet Refresh Token Handler Lacks Proof of Possession (CVE-2026-88819) In Siglet current and past versions the refresh token handler do not enforce proof of possession of the issuer DID.
CVE-2026-78299	Sep 14, 2026	CMSIS-Pack Extraction Path Traversal in Eclipse Embedded CDT 6.0-6.7 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.