CVE-2026-89320 is a high-severity vulnerability in Eclipse Foundation's Eclipse KeyPont - GOSE where the HmacShaCryptor.Hash function fails to hash its input and always returns the MAC of an empty message under the key. This flaw causes the authentication tag in AES-CBC-HMAC JSON Web Encryption (JWE) to be constant per key and independent of the message, effectively removing ciphertext integrity.
CVE-2026-89319 is a medium severity vulnerability in Eclipse KeyPont - GOSE where the Decrypt function improperly validates a 64-bit plaintext length read from a protected header field. This can cause panics due to truncated or oversized values, leading to unbounded memory allocation or slice-bounds errors.
CVE-2026-89318 is a vulnerability in Eclipse KeyPont - GOSE where the Decrypt function passes an incorrectly sized initialization vector (IV) to the Go standard library's AEAD Open method without validating its length. This causes the Go library to panic, crashing the decrypting goroutine. The issue affects versions from 0 up to 1.0.0-rc4, including some release candidates. The vulnerability has a medium severity with a CVSS score of 6.9.
CVE-2026-89317 is a medium severity vulnerability in Eclipse Foundation's Eclipse KeyPont - GOSE component. The vulnerability arises because the library parses the JWS 'crit' header but does not enforce the requirement to reject tokens with unrecognized critical extensions, as mandated by RFC 7515 §4.1.11. Since GOSE implements no header extensions, any token with a non-empty 'crit' header should have been rejected but was not.
CVE-2026-89316 is a medium severity vulnerability in Eclipse KeyPont - GOSE where the function LoadPublicKey performs an unchecked type assertion on an EC key's curve. If a JSON Web Key (JWK) declares a key type "EC" but specifies a non-EC algorithm, this triggers a panic due to the unchecked assertion.
CVE-2026-89315 is a vulnerability in Eclipse KeyPont - GOSE where the JwtClaims.MarshalJSON function uses Go's reflect.StructOf to dynamically create struct fields for JWT claims. This function panics if a claim name is not a valid Go identifier or duplicates another field name, conditions which can be triggered by ordinary JWT claim names. The vulnerability affects multiple versions of the product up to 1.0.0-rc4. It has a CVSS 4.0 score of 6.9, indicating medium severity.
CVE-2026-89314 is a medium severity vulnerability in Eclipse Foundation's Eclipse KeyPont - GOSE. It involves an inefficient algorithmic complexity issue in the jwkFields.CheckConsistency function, which uses a pairwise nested loop to detect duplicate key_ops entries. This causes the validation cost to grow quadratically with the number of entries. Since this check runs on every JWK and JWKS unmarshal, a specially crafted JWKS document could cause significant CPU consumption, potentially occupying a CPU core for many seconds.
CVE-2026-89313 is a medium severity vulnerability in Eclipse KeyPont - GOSE where the function JwksTrustStore.Get incorrectly returns the last key in the JWKS document when a requested key ID (kid) is not found, instead of signaling a 'not found' error. This occurs due to the use of a named return value and a naked return statement that returns the last parsed key with a nil error. This behavior can cause callers to receive incorrect key data, potentially leading to trust or validation issues.
CVE-2026-89312 is a vulnerability in Eclipse Foundation's Eclipse KeyPont - GOSE where the AesGcmCryptor.Open function passes a caller-supplied nonce directly to cipher.AEAD.Open without validating its length. The Go standard library panics if the GCM nonce length is incorrect, causing the decrypting goroutine to crash when processing a JWE with a wrong-sized IV. This affects multiple versions of the product prior to 1.0.0-rc4.
Eclipse OpenJ9 versions from 0.8.0 up to but not including 0.63.0 contain a vulnerability in the JITServer component that allows unauthenticated remote attackers or malicious JITServers to cause denial of service. This occurs due to improper boundary checks during protocol message and reply handling, leading to out-of-bounds heap reads and immediate crashes of the JITServer daemon or client JVM process via segmentation faults.
Eclipse OpenJ9 versions prior to 0.63.0 contain a vulnerability in the JITServer component where attacker-controlled fields are not properly validated during DataDescriptor message deserialization. This allows an unauthenticated remote attacker to cause an unsigned integer underflow, leading to out-of-bounds heap reads and an immediate process crash (SIGSEGV), resulting in denial of service.
Eclipse OpenJ9 versions prior to 0.63.0 contain a vulnerability in the JITServer component where an integer overflow in processing the initial TCP connection length field causes a denial of service. An unauthenticated remote attacker can exploit this by sending crafted TCP connections, leading to infinite CPU consumption and halting compilation services for all connected JVM clients.
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.
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.
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`.
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`.
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`).
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.
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.
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.