Export limit exceeded: 15998 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (457 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-115653 | 1 Eclipse | 1 Threadx | 2026-11-02 | N/A |
| In 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. | ||||
| CVE-2026-114408 | 1 Eclipse | 1 Threadx | 2026-11-02 | N/A |
| In 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. | ||||
| CVE-2026-89320 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| 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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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 | 1 Eclipse | 1 Keypont-gose | 2026-11-02 | N/A |
| `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-102479 | 1 Eclipse | 1 Vert.x | 2026-10-28 | 5.9 Medium |
| In Eclipse Vert.x versions [5.0.0,5.0.12] or [5.1.0,5.1.9] or [5.2.0, 5.2.0], the Vert.x HTTP/1.x decoder uses a canonicalization for well known HTTP headers, the canonicalization process interprets well crafted headers as headers of this list, allowing for instance Content-Xength to be interpeted as Content-Length. This can be exploited for request smuggling purpose. The impacted component is io.vertx:vertx-core. | ||||
| CVE-2026-111075 | 1 Eclipse | 1 Eclipse Openj9 | 2026-10-26 | N/A |
| In 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. | ||||
| CVE-2026-111074 | 1 Eclipse | 1 Eclipse Openj9 | 2026-10-26 | N/A |
| In 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. | ||||
| CVE-2026-110938 | 1 Eclipse | 1 Eclipse Openj9 | 2026-10-26 | N/A |
| In Eclipse OpenJ9 versions up to 0.63.0, the JITServer component is vulnerable to denial of service due to improper boundary checks during protocol message and reply handling. An unauthenticated remote attacker or malicious JITServer can transmit malformed network payloads that cause out-of-bounds heap reads, immediately crashing the JITServer daemon or client JVM process via a segmentation fault (SIGSEGV). | ||||
| CVE-2026-7411 | 1 Eclipse | 1 Basyx | 2026-10-25 | 10 Critical |
| In Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10, inadequate path normalization in the Submodel HTTP API allows an unauthenticated remote attacker to perform a path traversal attack. By supplying a maliciously crafted fileName parameter during a file upload operation, an attacker can bypass intended storage boundaries and write arbitrary files to any location on the host filesystem accessible by the Java process. This can lead to Remote Code Execution (RCE) and complete system compromise. | ||||
| CVE-2026-110726 | 1 Eclipse | 1 Connected Services Platform | 2026-10-21 | 6.5 Medium |
| In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration. | ||||
| CVE-2026-110724 | 1 Eclipse | 1 Connected Services Platform | 2026-10-21 | 7.5 High |
| In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration. | ||||
| CVE-2026-110723 | 1 Eclipse | 1 Connected Services Platform | 2026-10-21 | 7.5 High |
| In `api-gateway` versions till `1.7.3`, The default rate-limit key resolver, `ClientIpKeyResolver`, derives the per-client bucket key from the leftmost element of the `X-Forwarded-For` request header. That element is supplied by the originating HTTP client and is not validated against any trusted-proxy list. A single attacker can therefore obtain an unlimited number of independent rate-limit buckets — one per unique header value — and completely bypass the gateway's request-rate limiting on every route that uses the shipped default configuration. | ||||
| CVE-2026-91186 | 1 Eclipse | 1 Threadx Guix | 2026-10-21 | N/A |
| 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. | ||||