Eclipse Foundation
Monthly
Remote code execution in Eclipse GlassFish allows remote attackers to evaluate arbitrary Expression Language (EL) expressions through the gadget handler's server-side template rendering of .xml files, leading to full host compromise. The vulnerability (CVSS 9.6, CWE-917) requires user interaction but no authentication, and is demonstrable by submitting payloads like #{7*7} which the server evaluates to 49. No public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Server-Side Request Forgery (SSRF) in Eclipse BaSyx Java Server SDK prior to 2.0.0-milestone-10 allows unauthenticated remote attackers to force the server to execute blind HTTP POST requests to arbitrary internal or external targets via the unvalidated Operation Delegation feature. Attackers can exploit this to bypass network segmentation, pivot into isolated IT/OT infrastructure, or access Cloud Metadata services (IMDS) - enabling potential credential theft and lateral movement. EPSS data not available; no CISA KEV listing or public POC identified at time of analysis, but the SSRF attack pattern is well-understood and readily exploitable.
Remote code execution in Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10 allows unauthenticated remote attackers to write arbitrary files anywhere on the host filesystem via path traversal in the Submodel HTTP API's file upload fileName parameter, leading to complete system compromise. The vulnerability receives the maximum CVSS score of 10.0 due to network-accessible exploitation requiring no authentication, privileges, or user interaction, with scope change enabling impact beyond the vulnerable component. EPSS data not available; KEV status not confirmed; exploitation status depends on release recency and deployment exposure of this industrial automation SDK.
Remote unauthenticated attackers can crash Eclipse OpenJ9 JITServer instances (versions 0.21-0.58) by sending a specially crafted 32-byte TCP message, triggering a buffer over-read (CWE-125) that causes denial of service. The vulnerability requires no authentication or user interaction, affecting any exposed JITServer endpoint. CVSS 8.7 (High) reflects the severe availability impact, though EPSS data is not available for this recent CVE. Exploit code is publicly available via GitHub PR #23793, which demonstrates the bounds-checking fix, though no active exploitation is confirmed at time of analysis.
Eclipse KUKSA Databroker 0.5.0-0.6.0 allows privilege escalation from read-only JWT tokens to signal provider registration. Attackers with valid read-scope tokens can hijack the kuksa.val.v2 OpenProviderStream API to inject forged sensor/telemetry data into the vehicle data bus, poisoning downstream automotive systems and applications. CVSS 8.5 (High) reflects high integrity and availability impact across system and subsequent components. No active exploitation confirmed (not in CISA KEV), but the attack complexity is low and requires only low-privilege authentication.
HTTP request smuggling in Eclipse Jetty's HTTP/1.1 parser lets remote unauthenticated attackers desynchronize front-end/back-end request boundaries by abusing quoted-string chunk extensions. Jetty incorrectly terminates chunk-extension parsing at a CRLF located inside an unterminated quoted-string (e.g. `1;a="`) rather than rejecting it, so attacker-controlled bytes are reinterpreted as a second, smuggled request on the same TCP connection. Publicly available exploit code exists (a working Python PoC ships in the GHSA advisory), though EPSS is very low (0.03%, 9th percentile) and the issue is not on CISA KEV.
Privilege escalation in Eclipse Jetty 9.4.0-12.1.7 allows unauthenticated remote attackers to bypass authentication via ThreadLocal variable pollution in JASPIAuthenticator. Early returns from authentication checks fail to clear ThreadLocal values, causing subsequent requests on the same thread to inherit elevated privileges. CVSS 7.4 with high complexity but no authentication required. EPSS and KEV status not provided; no public exploit identified at time of analysis. Affects all major Jetty versions from 9.x through 12.x.
Denial of service in Eclipse KeyPont Gose affects the AES-CBC-HMAC direct decryption path (NewJweDirectDecryptorBlock) in Go module github.com/ThalesGroup/gose v0.9.0 through v0.13.0-rc1: an unvalidated 64-bit plaintext length from the _thales_aad protected header causes a nil dereference, a BigEndian.Uint64 panic on short input, an unbounded allocation, or a slice-bounds panic after the HMAC check. The advisory includes an executed reproducer and notes that the same 11 releases carry GHSA-h6w5-722x-2h3m, whose constant, message-independent HMAC tag lets an attacker who has seen one valid JWE reuse its tag so the length field is reachable without the MAC key; confidentiality and integrity are unaffected. Active exploitation is not confirmed (no CISA KEV data is provided), the advisory contains an executed reproducer for the panic and oversized-length behavior, and the vuln.today priority is this_month.
Eclipse KeyPont GoSE's JWE decryptor panics instead of returning an error when a compact JWE carries an incorrectly sized initialization vector, giving a denial of service to anyone holding the recipient's public key. The flaw affects github.com/eclipse-keypont/gose releases from v0.8.0 up to but excluding v1.0.0-rc4, and the deprecated github.com/ThalesGroup/gose module through v0.13.0-rc1. A public PoC reference and a working reproducer are documented in the upstream advisory; it is not confirmed as actively exploited (no KEV entry), and the practical impact ranges from a single failed HTTP request to full process termination depending on the caller's panic recovery posture.
Eclipse KeyPont gose (formerly github.com/ThalesGroup/gose) fails to enforce the JWS `crit` header: any token carrying a non-empty `crit` array should be rejected per RFC 7515 §4.1.11 because gose implements no header extensions, yet affected verifiers accept such tokens and report successful verification. Because `crit` lives inside the signed protected header, this is not reachable by an unauthenticated attacker without the signing key; the realistic risk is cross-context replay, where a trusted issuer constrains a token's use with a critical extension (RFC 7797 `b64:false`, RFC 7800 `cnf`, or an ecosystem `must-revoke-check`) and a gose-backed verifier silently drops that mandatory constraint. Signatures and claims remain authentic, so integrity impact is limited; no public exploit code is identified at time of analysis and the issue is not in CISA KEV. Fixed in eclipse-keypont/gose v1.0.0-rc4 (commit be2277b, merged as 692c25c); the legacy ThalesGroup module path ends at v0.13.0-rc1 and remains vulnerable.
Denial of service in Eclipse KeyPont gose occurs when a JWK declares kty EC with a non-EC alg and is passed directly to the exported LoadPublicKey or LoadPrivateKey loader; an unchecked ECDSAOptions type assertion panics the process. Affected releases are github.com/eclipse-keypont/gose before 1.0.0-rc4 and the deprecated github.com/ThalesGroup/gose path through 0.13.0-rc1, while gose's own NewVerificationKey/JWKS path gates EC algorithms and is not vulnerable. Exploitation is conditional on a consuming application forwarding externally supplied JWKs to those loaders; no CISA KEV listing or verified public exploit code is indicated, the advisory includes a reproducer, and the vendor rates the issue CVSS 4.0 6.3 with high attack complexity and availability-only impact.
Denial of service in Eclipse KeyPont's `gose` JOSE/JWT Go library: `JwtClaims.MarshalJSON` builds a runtime struct with `reflect.StructOf`, naming each field `"A" + claimName`, which panics whenever an untyped claim key is not a valid Go identifier (for example the URL-namespaced `https://example.com/roles` claims that OIDC and Auth0 mandate) or collides after prefixing (`utomaticJwtClaims`, `ettableJwtClaims`). All releases of `github.com/ThalesGroup/gose` from v0.7.3 through v0.13.0-rc1 are affected and that module path is deprecated and unpatched, while `github.com/eclipse-keypont/gose` is affected below v1.0.0-rc4 and fixed in v1.0.0-rc4. Impact is availability only (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:L, vendor CVSS 4.0 6.9 Medium with VA:L), the panic is reachable from legitimate standards-compliant IdP tokens without any attacker, and it only bites callers that call `json.Marshal` on the `*jose.JwtClaims` returned by `JwtVerifierImpl.Verify` without recovering; a reproducer is documented in the upstream advisory, and no public exploit code or active exploitation is confirmed (no CISA KEV listing).
CPU exhaustion in the Go JOSE library Eclipse KeyPont gose (formerly github.com/ThalesGroup/gose) allows a hostile JWK/JWKS document to pin one CPU core for roughly 15 seconds, because the duplicate key_ops validation in jwkFields.CheckConsistency runs an all-pairs nested loop whose cost grows with the square of the entry count (CWE-407). Because that check executes on every JWK and JWKS unmarshal, any consumer that parses a JWKS body from an attacker-controlled or attacker-influenced source - a compromised or malicious identity provider, a misconfigured discovery URL, or an application that accepts a JWKS URL as user input - is exposed; the authoritative assessment rates the impact as availability-only (CVSS:3.1 AV:N/AC:H, no confidentiality or integrity effect), with the higher AC reflecting the precondition that the victim must actually fetch from the hostile endpoint rather than any attacker-uncontrolled timing condition, and notes a trusted, pinned IdP deployment is not triggerable. All releases since the earliest tag are affected on the ThalesGroup module path (>= 0.7.3, <= 0.13.0-rc1, which is deprecated and unpatched) and on the Eclipse path (< 1.0.0-rc4), with the fix first shipped in v1.0.0-rc4; there is no CISA KEV listing and no public exploit identified at time of analysis.
JwksTrustStore.Get in the Eclipse KeyPont gose JOSE library (formerly github.com/ThalesGroup/gose) can return the last key parsed from a JWKS document, with a nil error, when the caller asks for a kid that is not present in that document - so absent-key lookups silently succeed against the wrong key instead of failing as 'not found'. The flaw exists in every release from v0.7.5 through v1.0.0-rc3 of the eclipse-keypont module path, and in the deprecated ThalesGroup path up to its final tag v0.13.0-rc1; it is fixed in v1.0.0-rc4. It is not an authentication bypass: JwtVerifierImpl.Verify still enforces algorithm match and signature verification against whatever key it receives, so a token signed by an unrelated key is still rejected; the realistic impact is broken kid-to-key binding during key rotation and any downstream logic that treats kid as a trusted decision input, which is why the maintainers rate integrity impact Low with High attack complexity. There is no KEV listing and no public exploit code identified at time of analysis; the upstream advisory publishes a reproducer that demonstrates the wrong-key return against an httptest JWKS server, and the recommended handling is to fold the fix into a routine monthly patch cycle rather than an emergency response.
Denial of service in the Eclipse Keypont gose Go JWE library (published historically as github.com/ThalesGroup/gose) where AesGcmCryptor.Open forwards a caller-supplied, wire-derived nonce to crypto/cipher AEAD Open without a length check, causing the Go standard library to panic instead of returning an error. Any party able to submit a compact JWE to a gose-backed decryptor can trigger it without key material or credentials (CVSS 4.0 base 6.9; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) - they only need a kid matching a key in the decryptor's keystore, alg=dir with a matching enc, and an IV whose decoded length is anything other than 12 bytes. Impact is bounded by the caller's panic posture: under net/http the panic is recovered per request and only that request fails, while a worker, daemon or CLI without recovery has its process terminated; confidentiality and integrity are unaffected because the panic occurs before plaintext is produced. No public exploit code was identified at time of analysis, although the advisory ships a unit-test reproducer that demonstrates the panic; this_month priority, not KEV-listed.
HTTP request smuggling in Eclipse ThreadX NetX Duo's optional Web add-on allows unauthenticated remote clients to influence request-framing decisions by placing header-like field names in the request body; the embedded HTTP server scans the entire packet for headers instead of stopping at the end of the header section. The CVSS 4.0 score is 6.9, with low integrity and availability impact and no confidentiality impact, and exposure is limited to devices that enable and network-expose the Web add-on. No public exploit code or CISA KEV confirmation is present in the provided data; no public exploit identified at time of analysis.
Out-of-bounds read in the Eclipse ThreadX Module Manager's block-pool create dispatcher (_txm_module_manager_tx_block_pool_create_dispatch) lets a loaded, memory-protected module cause the kernel to read words it does not own. The dispatcher verifies only two ALIGN_TYPE words of the caller-supplied extra-parameter array, but then uses indices 0 through 3, and the out-of-bounds access happens inside the validation path itself: index 1 is taken as the pool start and index 2 as the length used to range-check it, so the size the pool start is checked against is itself an unverified word, and a further unverified word is consumed when the service argument list is built. Affected are builds using the ThreadX Module Manager with MPU-isolated modules; the vector is CVSS:4.0/AV:L/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L (4.8) and our independent assessment agrees it is local, requires an already-loaded low-privilege module, and is bounded to information disclosure plus possible fault rather than code execution. No public exploit identified at time of analysis, and the issue is not in CISA KEV.
Denial of service in the Eclipse ThreadX Module Manager (CWE-400) lets a loaded user-mode module permanently drain the shared module object pool by cycling threads. Each thread a module creates consumes two allocations - a TX_THREAD control block plus a separately allocated TXM_MODULE_KERNEL_STACK_SIZE kernel stack - but the thread-delete dispatcher releases only the control block, so every valid create/terminate/delete cycle silently removes one fixed-size block from a finite pool shared by the Module Manager and all other loaded modules. A module that loops this lifecycle long enough exhausts the pool, after which no memory-protected module anywhere in the system can create kernel objects or new user-mode threads. Exploitation requires local execution of a loadable user-mode module (PR:L per the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector) and is purely an availability impact; no public exploit code or confirmed active exploitation was identified at time of analysis.
A crafted ThreadX module can permanently hang the entire kernel by abusing the Module Manager's object-lookup path: the search name for a memory-protected module is validated on only one byte and then walked in privileged mode for as far as the module declares. Both lookup dispatchers are affected - the recommended txm_module_object_pointer_get_extended accepts a length argument but never uses it to bound the buffer, while the deprecated txm_module_object_pointer_get passes the maximum UINT value, removing the bound entirely - so a hostile module forces an out-of-bounds read (CWE-125) without needing to know anything about the memory it reaches. Because the walk happens with the kernel's preemption count raised, an unrecoverable read fault leaves the scheduler disabled for the remainder of the device's uptime, making this a durable denial of service rather than privilege escalation or code execution. The local attack vector (CVSS 4.0 base 6.9; assessed 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H) requires the attacker to already be able to load or compromise a module in a build that enables the Module Manager; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Eclipse ThreadX deployments that use the Module Manager to load untrusted or mixed-trust modules let a module destroy kernel objects it does not own: the privileged dispatcher validates only that a pointer targets memory outside the caller's own code and data, which is the correct policy for *using* a shared object but not for deleting one. Any code running inside a loaded module, having obtained a pointer (for example via txm_module_object_pointer_get_extended name lookup) to an application- or peer-module-owned queue, semaphore, or mutex, can route that pointer to the kernel object delete service and have it torn down, yielding a local integrity and availability impact (CVSS 4.0 6.9; CVSS 3.1 AV:L/PR:L/UI:N/I:H/A:H, no confidentiality impact). Exploitation requires the module feature to be enabled with more than one trust domain, is local only, and does not apply to firmware built as a single monolithic trusted image; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Eclipse GUIX multi-line text view rendering can read one byte past the end of an application text buffer when the displayed string ends with a carriage return, and that over-read can cascade into an index overrun and a spurious text row. The issue is local and requires user interaction: an attacker must influence text rendered in a GUIX multi-line text view and a user must view that widget; impact is limited to low confidentiality and availability effects, with no public exploit identified at time of analysis. It is a low-to-moderate priority memory-safety bug in Eclipse ThreadX GUIX rather than a remotely triggerable or code-execution issue.
Truncated JPEG marker segments and a zero chroma sampling factor in Eclipse ThreadX GUIX's software JPEG decoder can trigger an out-of-bounds read and a non-terminating block-decode loop, letting a local, unauthenticated attacker who can get a crafted JPEG opened or rendered crash or hang the device and potentially disclose a small amount of adjacent memory. Both triggers reproduce in the default configuration with GX_SOFTWARE_DECODER_SUPPORT enabled; the CVSS 3.1 score is 6.1 (AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H), so the dominant outcome is availability loss rather than large-scale data theft. No public exploit code or CISA KEV entry was identified at time of analysis, and no EPSS score was provided.
An out-of-bounds read in the Eclipse ThreadX GUIX JPEG software decoder lets a crafted JPEG file expose memory beyond an undersized image buffer. The flaw affects GUIX builds with GX_SOFTWARE_DECODER_SUPPORT enabled, which is the shipped default, and is triggered by a JPEG whose marker ordering is illegal - specifically a second SOF0 frame header placed after SOS - which re-parses the frame header after the output buffer has already been allocated and its geometry latched. The decoder then returns GX_SUCCESS and publishes a GX_PIXELMAP whose reported dimensions and data_size exceed the actual allocation, so any consumer trusting the structure, including GUIX's own display drivers via the ordinary draw path, reads past the buffer; interaction is required and the attack is local (the malicious file must reach the decoder), and no public exploit code has been identified at time of analysis.
Out-of-bounds reads in Eclipse ThreadX GUIX can expose adjacent memory or terminate the application when gx_binres_theme_load() or gx_binres_font_load() processes a crafted theme or font resource that declares more data than it contains or embeds an out-of-range offset. The loaders accept a bare resource pointer with no length, so file-controlled offsets can drive reads past the buffer end; a well-formed, narrow glyph range is sufficient, and no underflow or integer-wrap is required. Exploitation is local and requires the application to load an untrusted GUIX resource, and no public exploit or CISA KEV activity is identified at time of analysis.
Out-of-bounds write in the Eclipse ThreadX GUIX binary resource theme loader lets an attacker who supplies a crafted GUIX theme file corrupt the GUIX memory arena and potentially hijack execution or crash the device. The flaw is only reachable in products that call the public API gx_binres_theme_load() on externally supplied or user-replaceable theme files, with GX_BINARY_RESOURCE_SUPPORT compiled in (the shipped default). CVSS 4.0 rates this 6.8 (Medium) with a local attack vector and required user interaction; no public exploit code and no CISA KEV entry were identified at time of analysis.
Eclipse ThreadX's memory-protected module support under-validates queue extents in the front-send path: the Module Manager's dispatch layer receives a value counted in ULONGs where it expects a byte extent, so the privileged copy in _txe_queue_front_send reads up to 3 x message_size bytes past the end of the memory a loaded module is permitted to read. The over-read words land in the queue's message area, meaning a second module (or the same one) that can receive from that queue can retrieve the adjacent memory contents. Exploitation is strictly local and requires the attacker to already control a loaded low-privilege module authorized to front-send on the target queue; there is no public exploit code and no confirmed active exploitation (no public exploit identified at time of analysis), and the assessed impact is limited information disclosure plus a possible availability effect, consistent with the 4.8 CVSS 4.0 / 4.8 CVSS 3.1 ratings.
Out-of-bounds heap read in the Eclipse ThreadX USBX host stack can be triggered when a malicious USB device presenting the MTP/PTP class is attached and the host performs ordinary object enumeration, causing adjacent heap memory to be disclosed to the application or an unmapped-page fault that crashes the host. The issue is physically gated: an unauthenticated attacker needs physical access, and the target must be running USBX in USB host mode with MTP/PTP support enabled and must enumerate the crafted device. Vendor scoring is CVSS 4.0 5.2 (Medium); no public exploit was identified at time of analysis, and impact is limited to low confidentiality loss plus possible denial of service, with no integrity impact or code execution.
Eclipse OpenJ9 through 0.63 can expose local files to a remote receiver when an analyst opens a crafted diagnostic dump bundle with jdmpview or equivalent legacy DTFJ code. The bundle's XML metadata can define an external entity that references an arbitrary local file, causing the tool to read that file and transmit its contents to an attacker-controlled host. This is a local, user-interaction-dependent issue in the legacy DTFJ XML path; no public exploit was identified at time of analysis, and the risk is moderate and context-dependent rather than a mass-exploitation priority.
An out-of-bounds read exists in the Eclipse ThreadX USBX host stack's USB Video Class handling: when a malicious USB device declares a VideoStreaming interface wTotalLength larger than the format, frame, and frame-interval descriptors it actually transmits, the host trusts that self-reported size as its parsing budget and walks past the end of the configuration buffer. The bug is only triggered when the application queries format or frame data, not during enumeration, and requires physically attaching a crafted USB device to a host built with USBX video-class host support. No public exploit code or active exploitation was identified at time of analysis, and the physical attack vector keeps practical risk low-to-moderate despite potential information disclosure and host-context denial of service.
Heap out-of-bounds read in the Eclipse ThreadX USBX USB host HID class driver is triggered during ordinary device enumeration when a physically attached HID peripheral returns a short or truncated report descriptor whose item headers declare more payload bytes than were actually transferred. The flaw affects USBX builds configured as a USB host with HID support, requires physical access and a user action to connect the device, and needs no authentication (CVSS 3.1: 4.9, AV:P/AC:L/PR:N/UI:R), with the main impact being a crash or denial of service plus limited information disclosure. No public exploit code or confirmed active exploitation was identified at the time of analysis.
Blind server-side request forgery in Eclipse PIA allows an approved OIDC identity provider to force PIA's token-verification flow to fetch an arbitrary host and port, including plaintext HTTP, from PIA's network position. The issue is in verify_token (pia/oidc.py), which follows jwks_uri from a trusted issuer's discovery document without parsing it as a URL, comparing it to the issuer origin, or requiring HTTPS, and the fetch is triggered by an unauthenticated POST /v1/upload/sbom that is then rejected with 401. Because the response is not reflected to the attacker, impact is limited to outbound GET reconnaissance/interaction; exploitation requires a high-privileged position controlling a registered per-project Jenkins issuer under https://ci.eclipse.org/<project>/oidc (PR:H), and no public exploit was identified at time of analysis.
Eclipse CSI PIA executes its pre-authentication OIDC discovery and JWKS fetch operations synchronously directly on the asyncio event loop, so a single unauthenticated request can stall the entire service for every connected user. Any network-reachable deployment that has the OIDC authentication flow enabled is affected, and exploitation needs no credentials, privileges, or user interaction (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N, availability-only with VA:L). Impact is confined to denial of service with no confidentiality or integrity effect, and no public exploit code was identified at time of analysis.
Query-parameter injection in Eclipse Jetty's TryPathsHandler and TryFilesFilter allows unauthenticated remote attackers to inject extra query parameters when a deployment uses a non-default configuration that forwards the request path into a template query string such as index?p=$path. Exposure is limited to sites using that operator-chosen pattern; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) and CVSS 4.0 base score of 6.9 describe a medium-severity, configuration-dependent flaw whose realized impact depends on how the backend interprets the smuggled parameters. No public exploit code or confirmed active exploitation was identified at time of analysis.
A heap-based out-of-bounds write in Eclipse ThreadX GUIX's gx_binres_theme_load() lets a local attacker corrupt memory by supplying a binary theme resource in which the requested theme id is at or beyond the theme count the resource declares. The loader sizes and allocates a zero-byte buffer for that out-of-range id, then walks past the end of the theme table and writes a GX_THEME structure and its tables into the empty allocation, producing out-of-bounds heap corruption. Exploitation requires local placement or substitution of the malicious resource plus application/user interaction to load it (AV:L, PR:N, UI:R), so risk is moderate rather than high; no public exploit has been identified at time of analysis.
Information disclosure in the Eclipse ThreadX NetX Duo embedded TCP/IP stack's FTP server addon lets a network attacker consume data belonging to an authenticated FTP session, because the server never ties the passive-mode data connection back to the peer on the control channel. Exploiting this requires the target to be running the NetX Duo FTP server and a client to be performing or negotiating a passive-mode transfer at the moment of attack, and the attacker must reach the announced passive port and win a connection race against the legitimate client before it connects; no authentication is required (PR:N), but the timing dependency makes complexity high (AC:H, UI:P) and the impact is limited to confidentiality (C:H/I:N/A:N, CVSS 4.0 base 6.0). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw should be treated as a genuine but moderate-priority confidentiality issue rather than a high-severity one.
Crafted IPCP configuration options sent by a PPP peer can stall a NetX Duo worker thread and drive an out-of-bounds read in Eclipse ThreadX NetX Duo builds that enable the PPP/IPCP add-on. Only devices that terminate PPP links (serial, cellular modem, PPPoE, or L2TP) and accept negotiation traffic from an attacker-controlled or untrusted peer are exposed, and the assessed vector (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H) reflects adjacency rather than remote reachability. Exploitation is unauthenticated and needs a specifically crafted IPCP option with an oversized declared length, but no public exploit code has been identified and the issue is not listed in CISA KEV at time of analysis.
Out-of-bounds reads in Eclipse NetX Duo's MSRP (Multiple Stream Reservation Protocol) attribute-list parser allow an attacker positioned on the same layer-2 network segment to crash a device by supplying a malformed attribute list whose length field is never validated. The flaw affects NetX Duo builds that have the MSRP / TSN-AVB stream-reservation feature compiled in and actively processing MSRP traffic; because exploitation requires adjacent-network access and yields only a denial of service - no confidentiality or integrity impact, and no code execution is claimed - this is a bounded availability issue rather than a remotely exploitable high-severity defect. There is no CISA KEV listing and no public exploit code identified at time of analysis, so exploitation is assessed as unconfirmed.
Eclipse NetX Duo can be crashed (high availability impact) by an unauthenticated attacker on the same Layer-2 network segment who manipulates MSRP attribute state so that the sole remaining MSRP attribute is evicted, triggering a NULL pointer dereference. This is a genuine but bounded availability-only risk: MSRP (IEEE 802.1 AVB/TSN) must be enabled, and the attacker must achieve a precise attribute-table condition (AT:P), so it is not a stateless single-packet trigger. No public exploit code has been identified at time of analysis; the vendor-assigned CVSS 4.0 base score is 6.0, and our independent CVSS 3.1 assessment (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms adjacent-only, state-dependent denial of service.
Attribute table exhaustion in Eclipse ThreadX NetX Duo's MSRP (Multiple Stream Reservation Protocol) handling triggers a NULL pointer dereference that halts the affected device, producing an availability-only denial of service. Only deployments where MSRP/AVB-TSN support is compiled in and actively running are exposed, and the attacker must be on the same Layer-2 bridged segment because MSRP frames are not routed outside the local bridge domain. No public exploit code has been identified at time of analysis, and success requires sustained flooding of attribute registration frames rather than a single packet, giving this an assessed severity in the moderate range despite the total loss of availability on a targeted device.
The FTP client component of Eclipse ThreadX NetX Duo trusts the IPv4 address returned in a server's 227 PASV reply, performing only parse and non-zero checks before opening a data connection to that address, which lets a malicious or man-in-the-middle FTP server redirect the client's data transfer to any host it names (CWE-918 server-side request forgery class). Only the IPv4 passive-mode path is affected; the client must itself initiate an FTP control session to a hostile or intercepted endpoint and then request a passive transfer. No authentication or user interaction beyond starting the session is required (CVSS:4.0 base 6.9; independent assessment CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), and no public exploit code or active exploitation has been identified at time of analysis.
An out-of-bounds read in the Eclipse NetX Duo TFTP client lets an attacker-controlled or man-in-the-middle TFTP server return a short ERROR packet that causes the client to read up to 64 bytes past the received datagram. The vulnerable receive paths are in the TFTP client add-on and an unauthenticated remote attacker can trigger the condition when a device initiates a TFTP read or open against the attacker's server, potentially disclosing adjacent packet-pool memory if the application logs or displays nx_tftp_client_error_string, and potentially causing a crash. No public exploit identified at time of analysis, and the provided advisory points to a code-level bounds-check fix; risk is moderate rather than critical because exploitation requires the client-initiated, attacker-as-server model and yields no write primitive.
An out-of-bounds heap read in the DHCP client addon of Eclipse ThreadX NetX Duo (nxd_dhcp_client.c) allows an attacker on the same local link to disclose adjacent heap memory whenever a device performs a DHCP acquisition. The attacker only needs to be a DHCP server, or any LAN host that wins the race to answer the client's broadcast DISCOVER first, and to reply with a single OFFER containing a long run of skippable TLV options; a malformed option layout causes the parser's offset counter to lag the actual read pointer, producing a read roughly a kilobyte and beyond past the end of the message (a one-byte read 164 bytes past a 1648-byte heap region in the reported AddressSanitizer trace). The issue occurs unauthenticated (CVSS PR:N), from an adjacent network (AV:A), on every boot while the interface is unconfigured, with bounded impact limited to low confidentiality and low availability (CVSS 5.3); no public exploit code or confirmed active exploitation was identified at time of analysis.
Eclipse NetX Duo's DTLS server implementation uses predictable HelloVerifyRequest cookies due to insufficient randomness (CWE-330), enabling unauthenticated remote attackers to bypass source-address validation and potentially facilitate amplification attacks. Affected deployments are those running NetX Secure as a DTLS server with cookie exchange enabled; exploitation requires high attack complexity and no public exploit or active exploitation has been identified. The independent assessment rates this as a moderate, narrow-trigger weakness.
Out-of-bounds heap read and a control-flow-integrity gap in the Eclipse ThreadX loadable-module loader (module manager) allow an attacker-supplied module image to trigger out-of-bounds memory disclosure when the device loads it through `_txm_module_manager_memory_load` or `_txm_module_manager_in_place_load`. The affected code fully trusts every size and offset field in `TXM_MODULE_PREAMBLE` - the loader APIs accept only a base pointer and no image length, and the preamble `checksum` is never verified - so `code_size` can drive the code-copy loop past the end of the source image; the copy destination is overflow-guarded, so no controlled out-of-bounds write was found. Exploitation is local and conditional: no authentication or privileges are required (PR:N), but attack complexity is high, user/operator action is needed to trigger the load, and only systems that actually load third-party or externally supplied modules are exposed; no public exploit was identified at time of analysis.
Eclipse NetX Duo's NetX Secure TLS stack accepts empty application-data records without ever generating or comparing their message authentication code, so the receive sequence number advances on records that were never integrity-checked. An unauthenticated remote attacker who holds a man-in-the-middle position on an already-established TLS connection can inject such records into the stream, yielding a bounded loss of integrity and availability (no confidentiality impact). Exploitation is constrained by high attack complexity, no public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited (no CISA KEV listing).
Eclipse iceoryx2 versions after v0.8.0 up to v0.9.x contain a Rust soundness defect in which StaticString exposes its contents as mutable bytes via safe APIs, and the associated String::as_str() conversion does not validate UTF-8, allowing safe Rust code to construct an invalid &str and trigger undefined behavior. Exploitation requires a local authenticated attacker with low privileges and high attack complexity, and it additionally depends on an application coded in the vulnerable pattern; impact is limited to minor integrity and availability loss with no confidentiality impact, and the defect is not remotely exploitable against a default configuration. No public exploit code or active exploitation has been identified, and the vendor has released a patched version v0.10.0.
Local attackers holding a low-privileged workload on an Eclipse Ankaios agent can bypass log-access authorization to read other workloads' logs on the same agent. The flaw affects Eclipse Ankaios 0.6.0 through 1.0.3, where the agent's control-interface authorizer stops evaluating a rule at the first wildcard pattern and therefore skips later deny LogRule entries; exploitation requires a rule set in which a wildcard-containing entry precedes a deny rule. This is a low-severity authorization flaw (CVSS 4.8, CWE-863) requiring local access and an existing workload foothold, with no public exploit identified at time of analysis.
Let me synthesize. Product: Siglet / Eclipse Data Plane Core. The description mentions "Siglet" refresh token handler, CPE says eclipse_data_plane_core. Primary product name — 1-3 words. Probably "Eclipse Data Plane Core" or "Siglet". Let me pick "Siglet" — hmm, the CPE is Eclipse Data Plane Core. The description says "In Siglet current and past versions". Siglet appears to be a component within Eclipse Data Plane Core (Eclipse Dataspace Components). Tags list Eclipse Data Plane Core. I'll use "Eclipse Data Plane Core" as primary? The rules say pick primary product. The CPE is the authoritative affected product. But description says Siglet. Hmm. I'll say "Siglet" — actually product_name 1-3 words only. Let me choose "Eclipse Data Plane Core" (4 words? Eclipse, Data, Plane, Core = 4 words). That violates 1-3 words. "Siglet" is 1 word. I'll go with "Siglet". Hmm, but the affected products refer to Eclipse Data Plane Core. Perhaps Siglet is the SSI/token component. I'll use "Siglet" as product name and mention Eclipse Data Plane Core in affected_products. Actually, to be safe, maybe "Eclipse Data Plane Core" — 4 words is over. Let's use "Siglet". CVSS 6.3, vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N — network, high complexity, no privileges, no UI, low impact on C/I/A. CWE-290: Authentication Bypass by Spoofing. Issue: refresh token handler does not enforce proof of possession of the issuer DID. So an attacker who obtains a refresh token (or can present a refresh token) without proving possession of the private key corresponding to the issuer DID can redeem it — token theft/replay allows issuing new access tokens. That's authentication bypass by spoofing: the token handler accepts a refresh token without verifying the DID key binding. Affected versions: Eclipse Data Plane Core 0.1.0 ≤ 0.1.3 and commit range a6f7d4cc... < 882fe22d... Patch: Available from vendor. The commit 882fe22db42bc67abfd0304c4cdb141b762c35d1 is likely the fix com
Disk exhaustion via zip bomb in Eclipse OpenVSX allows a publisher to cause persistent service disruption on any OpenVSX server instance. A publisher uploads a small, highly compressed VSIX (zip bomb) that the server decompresses without size limits when any client requests a file via /vscode/unpkg/; the decompressed content is cached to java.io.tmpdir under an entry-count eviction policy with no total-size bound, enabling repeated disk exhaustion through new filenames or versions. Impact includes HTTP 500 errors for all uncached resources, publishing failures with 'Failed to read extension file', and a poisoned cache entry that blocks future requests to the same path. No public exploit has been identified at time of analysis, and EPSS data is not available in the provided input.
Server-side request forgery in Eclipse Che dashboard backend (versions 7.79.0-7.121.0) enables any authenticated user to make the backend issue arbitrary outbound HTTP GET requests to internal network targets, including the cloud instance metadata service at 169.254.169.254, loopback interfaces, RFC-1918 ranges, and in-cluster Kubernetes service endpoints. The POST /dashboard/api/data/resolver endpoint forwards caller-supplied URLs with no host validation and without consulting the operator-configured allowlist (spec.devEnvironments.allowedSources.urls). The vulnerability is fixed in 7.122.0, which introduces private-address blocking, IPv4-mapped IPv6 bypass prevention, allowlist enforcement, and disables outbound redirect following. No public exploit or CISA KEV listing identified at time of analysis.
Uncontrolled memory allocation in Eclipse Ankaios 0.1.0-1.0.1 allows a workload with granted Control Interface access to abort the agent process by declaring an arbitrarily large protobuf message length over the Control Interface FIFO, causing unbounded heap allocation and an OOM-triggered process crash. The impact is complete loss of orchestration services for all workloads managed by the affected agent instance. No public exploit has been identified and no active exploitation is confirmed; patch v1.0.2 is available.
Server-side request forgery in Eclipse Ditto's Things service allows authenticated users with WRITE permission on a Thing to force the service to issue arbitrary HTTP GET requests to any host reachable from within the deployment's internal network. The vulnerability arises because the Things service fetches WoT ThingModel documents from attacker-supplied URLs in the Thing or Feature `definition` field without validating the target host, without re-validating redirect targets, and without enforcing a redirect hop limit. Attackers can leverage cloud instance-metadata endpoints (e.g., AWS IMDS at 169.254.169.254) and exploit differing HTTP error responses to enumerate internal services. No public exploit or CISA KEV entry exists at time of analysis.
Path traversal in Eclipse SW360's optional filesystem attachment store allows authenticated low-privilege users to write files to arbitrary paths on the host operating system by crafting malicious filenames during attachment upload. Affected versions span 19.0.0 through 20.1.0 exclusively when the non-default `enable.attachment.store.to.file.system` configuration key is active. The CVSS 4.0 score of 6.0 (AT:P, PR:L, VI:H) reflects meaningful integrity impact gated behind a specific configuration requirement; no public exploit has been identified at time of analysis.
Eclipse OpenJ9 JVM versions through 0.60 crash with a segmentation fault when processing a crafted .class file containing deeply nested annotations, enabling a denial-of-service attack against any Java application running on OpenJ9 where an attacker can supply class files for loading. The vulnerability is rooted in uncontrolled recursion (CWE-674) within the bytecode utility annotation parser, which exhausts the OS thread stack without triggering a recoverable error path. No active exploitation has been confirmed by CISA KEV and no standalone exploit code has been publicly identified, though the public GitHub fix PR clearly exposes the triggering mechanism and root cause.
Session security diagnostics nodes in Eclipse Milo 0.6.0 through 1.1.4 expose sensitive OPC UA session metadata without enforcing any authorization checks, a CWE-862 (Missing Authorization) flaw. An unauthenticated anonymous client connecting over a None/None (no-security) endpoint can enable the diagnostics subsystem with no certificate or credentials whatsoever; separately, a client presenting a trusted application certificate over SignAndEncrypt can read the SessionSecurityDiagnosticsArray for all active server sessions, harvesting usernames, login history, authentication mechanisms, session security modes and policies, and public client certificates. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the zero-authentication path and prevalence of None/None endpoints in legacy OT/IIoT environments meaningfully lower the exploitation barrier.
Unauthenticated remote clients can permanently exhaust the global monitored-item quota in Eclipse Milo OPC UA SDK versions 1.0.0 through 1.1.4, effectively preventing all clients from creating new monitored items until the server is restarted. The attack combines two defects: the server's ExtensionObject decoder lacks recursion-depth enforcement, enabling deeply nested PubSub structures in a CreateMonitoredItems event filter to trigger a JVM StackOverflowError, and the quota accounting code is not exception-safe against unchecked JVM Errors, so the reserved slot is never reclaimed. No public exploit code has been identified and this CVE is absent from the CISA KEV catalog; however, the CVSS 4.0 vector AV:N/AC:L/PR:N/UI:N confirms the attack is network-reachable with no authentication or complexity barriers.
Incorrect interface method dispatch in Eclipse OpenJ9 up to version 0.60 causes the JVM to silently execute an unintended interface default method instead of raising AbstractMethodError or IllegalAccessError when a previously JIT-compiled concrete superclass method is subsequently recompiled as abstract. Applications running on OpenJ9 with dynamic class-loading or OSGi-style hot deployment are at risk of integrity violations - untended code paths execute where exceptions should be thrown. No confirmed active exploitation exists and this CVE does not appear in CISA KEV; EPSS data was not provided, and the high attack complexity (AC:H) and specific attack prerequisites (AT:P) significantly limit real-world exploitability.
Out-of-bounds read in Eclipse OMR's arraycmp SIMD JIT implementation for IBM Z (s390x) and IBM POWER (P10) architectures - versions up to 0.11 - allows a low-privileged network-reachable attacker to trigger an application crash when a zero-length array comparison is JIT-compiled and executed. The flaw exists exclusively in the SIMD code-generation paths for these two architectures and has no impact on x86 or ARM deployments. No active exploitation has been confirmed (no CISA KEV listing) and no public exploit has been identified at time of analysis; exploitation is further constrained by high attack complexity and the requirement for user interaction.
Buffer underflow (CWE-124) in Eclipse OpenJ9 versions through 0.60 allows memory corruption via the JVM method argument tracing subsystem when the -Xtrace diagnostic flag is active, with potential high integrity and availability impact to the running JVM process. The defect resides in traceMethodArguments() within the trace runtime, where the cursor pointer could be decremented past the start of the allocated trace buffer when constructing an ellipsis truncation marker - a classic buffer underwrite. No active exploitation is confirmed in CISA KEV, and no public exploit code has been disclosed at time of analysis.
Privilege escalation in Eclipse hawkBit's Direct Device Integration (DDI) Controller allows any authenticated device to download firmware artifacts beyond those explicitly assigned to it, within the same tenant. The flaw - rooted in missing object-level authorization (CWE-284/CWE-862) - means a valid device credential is sufficient to access arbitrary firmware artifacts belonging to other devices in the same tenant, not just the device's own assigned updates. A secondary enumeration weakness in the software modules listing endpoint compounds the issue by enabling targeted discovery of available artifacts. No public exploit has been identified at time of analysis, and no CISA KEV listing is present.
Eclipse Jetty mishandles HTTP URI path parameters containing semicolons combined with traversal sequences, delivering an unresolved path (e.g., `/public/../admin/secret.txt`) to downstream web applications instead of the canonicalized form (e.g., `/admin/secret.txt`). Web applications that delegate path-based authorization decisions to Jetty-provided paths are susceptible to confusion attacks where an attacker crafts a URI like `/public;/../admin/secret.txt` to receive a path that bypasses application-layer access controls. Jetty itself is shielded by its alias checker and will not serve restricted files directly; the integrity risk materializes only in applications that consume the unresolved path for routing or authorization logic. No public exploit code or CISA KEV listing is present at time of analysis.
Eclipse Jetty fails to enforce RFC 9110/9112's requirement that the HTTP request authority (host and port) match the value in the Host header across all supported protocol versions - HTTP/1, HTTP/2, and HTTP/3. Unauthenticated network attackers can exploit this input validation gap to manipulate Host-header-derived URI constructions (particularly redirect targets on login pages), influence virtual host selection, corrupt reverse proxy routing decisions, and produce misleading access logs. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack surface is meaningful in any Jetty deployment that performs host-based routing or generates redirects from the Host header.
HTTP/1.1 trailer leakage in Eclipse Jetty allows a remote unauthenticated attacker to read trailer headers from a previous request when sharing a persistent connection with another party. Trailers sent in an initial request are incorrectly retained in the server's connection state, causing them to bleed into all subsequent requests on the same keep-alive connection - either appended wholesale (if the later request has no trailers) or merged with the later request's own trailers. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
HTTP request smuggling in Eclipse Grizzly before 5.0.2 stems from the framework's inability to correctly parse malformed trailer header lines in chunked HTTP requests, enabling CWE-444 boundary-confusion attacks. Remote unauthenticated attackers who can send crafted chunked requests through a front-end proxy to a GlassFish-backed server can cause the proxy and Grizzly to disagree on request boundaries, smuggling attacker-controlled content as the prefix of a subsequent legitimate user's request. No public exploit code and no CISA KEV listing have been identified at time of analysis, though the CVSS 4.0 AT:P condition signals that specific deployment prerequisites must be met.
Eclipse KUKSA Databroker 0.6.1 panics in a Tokio worker thread when an authenticated client sends a PublishValueRequest with a valid signal_id but omits the optional data_point field, causing the server to call Rust's unwrap() on a None value. Any client holding a valid JWT token can trigger this condition, cancelling the individual gRPC call while leaving the Databroker process intact and available. No public exploit has been identified and this vulnerability is not listed in CISA KEV; EPSS data was not supplied in available intelligence.
Log injection in Eclipse CSI PIA's unauthenticated /v1/upload/sbom endpoint allows a remote attacker to plant forged authentication-success log entries that are byte-for-byte indistinguishable from genuine PIA audit events. PIA is an authentication broker whose logs are explicitly designated as the authoritative source for incident response (DESIGN.md §5.4), meaning the forgery directly subverts the audit trail the service exists to produce. No public exploit has been identified at time of analysis, but the attack requires no authentication and minimal technical sophistication.
Out-of-bounds read in Eclipse tinydtls prior to commit b3efd41ad111a4920f599f51ffa4f5e9f1e72221 allows unauthenticated network attackers to crash memory-constrained IoT devices by sending a specially crafted Certificate handshake message during DTLS epoch 0. The vulnerable check_server_certificate() function omits buffer length validation before uint24 reads, memcmp, and memcpy operations, enabling reads beyond valid buffer boundaries on both client and server code paths. No public exploit code or active exploitation has been identified at time of analysis; however, the unauthenticated, network-reachable nature makes this straightforward to trigger against any exposed tinydtls endpoint.
Stored XSS in Eclipse Open VSX Registry allows authenticated extension publishers to embed malicious JavaScript inside SVG files uploaded as extension icons, which are stored and re-served without sanitization or protective headers. On local-storage deployments, script execution occurs within the Open VSX application origin, enabling session hijacking, authentication token theft, and unauthorized extension publishing on behalf of victims. On CDN-backed deployments (such as open-vsx.org using S3), scope is reduced to the storage origin - still usable for phishing and credential harvesting. No public exploit code has been identified at time of analysis and CISA has not listed this in KEV.
Unconstrained Markdown image rendering in Eclipse Theia's AI chat component, in all versions prior to 1.71.0, enables silent data exfiltration when combined with prompt injection via a malicious workspace. An attacker who delivers a crafted workspace can inject instructions into the AI agent's context, causing it to construct Markdown image tags whose URLs encode sensitive workspace or conversation data; when the IDE renders these images, it issues HTTP GET requests transmitting that data to an attacker-controlled server. No public exploit has been identified and the vulnerability is not listed in CISA KEV, but the local-access, active-user-interaction model (CVSS 4.0: 6.7, AV:L/UI:A) correctly reflects that this is a targeted, workspace-delivery attack rather than a remote, unauthenticated threat.
Remote code execution in Eclipse GlassFish allows remote attackers to evaluate arbitrary Expression Language (EL) expressions through the gadget handler's server-side template rendering of .xml files, leading to full host compromise. The vulnerability (CVSS 9.6, CWE-917) requires user interaction but no authentication, and is demonstrable by submitting payloads like #{7*7} which the server evaluates to 49. No public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Server-Side Request Forgery (SSRF) in Eclipse BaSyx Java Server SDK prior to 2.0.0-milestone-10 allows unauthenticated remote attackers to force the server to execute blind HTTP POST requests to arbitrary internal or external targets via the unvalidated Operation Delegation feature. Attackers can exploit this to bypass network segmentation, pivot into isolated IT/OT infrastructure, or access Cloud Metadata services (IMDS) - enabling potential credential theft and lateral movement. EPSS data not available; no CISA KEV listing or public POC identified at time of analysis, but the SSRF attack pattern is well-understood and readily exploitable.
Remote code execution in Eclipse BaSyx Java Server SDK versions prior to 2.0.0-milestone-10 allows unauthenticated remote attackers to write arbitrary files anywhere on the host filesystem via path traversal in the Submodel HTTP API's file upload fileName parameter, leading to complete system compromise. The vulnerability receives the maximum CVSS score of 10.0 due to network-accessible exploitation requiring no authentication, privileges, or user interaction, with scope change enabling impact beyond the vulnerable component. EPSS data not available; KEV status not confirmed; exploitation status depends on release recency and deployment exposure of this industrial automation SDK.
Remote unauthenticated attackers can crash Eclipse OpenJ9 JITServer instances (versions 0.21-0.58) by sending a specially crafted 32-byte TCP message, triggering a buffer over-read (CWE-125) that causes denial of service. The vulnerability requires no authentication or user interaction, affecting any exposed JITServer endpoint. CVSS 8.7 (High) reflects the severe availability impact, though EPSS data is not available for this recent CVE. Exploit code is publicly available via GitHub PR #23793, which demonstrates the bounds-checking fix, though no active exploitation is confirmed at time of analysis.
Eclipse KUKSA Databroker 0.5.0-0.6.0 allows privilege escalation from read-only JWT tokens to signal provider registration. Attackers with valid read-scope tokens can hijack the kuksa.val.v2 OpenProviderStream API to inject forged sensor/telemetry data into the vehicle data bus, poisoning downstream automotive systems and applications. CVSS 8.5 (High) reflects high integrity and availability impact across system and subsequent components. No active exploitation confirmed (not in CISA KEV), but the attack complexity is low and requires only low-privilege authentication.
HTTP request smuggling in Eclipse Jetty's HTTP/1.1 parser lets remote unauthenticated attackers desynchronize front-end/back-end request boundaries by abusing quoted-string chunk extensions. Jetty incorrectly terminates chunk-extension parsing at a CRLF located inside an unterminated quoted-string (e.g. `1;a="`) rather than rejecting it, so attacker-controlled bytes are reinterpreted as a second, smuggled request on the same TCP connection. Publicly available exploit code exists (a working Python PoC ships in the GHSA advisory), though EPSS is very low (0.03%, 9th percentile) and the issue is not on CISA KEV.
Privilege escalation in Eclipse Jetty 9.4.0-12.1.7 allows unauthenticated remote attackers to bypass authentication via ThreadLocal variable pollution in JASPIAuthenticator. Early returns from authentication checks fail to clear ThreadLocal values, causing subsequent requests on the same thread to inherit elevated privileges. CVSS 7.4 with high complexity but no authentication required. EPSS and KEV status not provided; no public exploit identified at time of analysis. Affects all major Jetty versions from 9.x through 12.x.
Denial of service in Eclipse KeyPont Gose affects the AES-CBC-HMAC direct decryption path (NewJweDirectDecryptorBlock) in Go module github.com/ThalesGroup/gose v0.9.0 through v0.13.0-rc1: an unvalidated 64-bit plaintext length from the _thales_aad protected header causes a nil dereference, a BigEndian.Uint64 panic on short input, an unbounded allocation, or a slice-bounds panic after the HMAC check. The advisory includes an executed reproducer and notes that the same 11 releases carry GHSA-h6w5-722x-2h3m, whose constant, message-independent HMAC tag lets an attacker who has seen one valid JWE reuse its tag so the length field is reachable without the MAC key; confidentiality and integrity are unaffected. Active exploitation is not confirmed (no CISA KEV data is provided), the advisory contains an executed reproducer for the panic and oversized-length behavior, and the vuln.today priority is this_month.
Eclipse KeyPont GoSE's JWE decryptor panics instead of returning an error when a compact JWE carries an incorrectly sized initialization vector, giving a denial of service to anyone holding the recipient's public key. The flaw affects github.com/eclipse-keypont/gose releases from v0.8.0 up to but excluding v1.0.0-rc4, and the deprecated github.com/ThalesGroup/gose module through v0.13.0-rc1. A public PoC reference and a working reproducer are documented in the upstream advisory; it is not confirmed as actively exploited (no KEV entry), and the practical impact ranges from a single failed HTTP request to full process termination depending on the caller's panic recovery posture.
Eclipse KeyPont gose (formerly github.com/ThalesGroup/gose) fails to enforce the JWS `crit` header: any token carrying a non-empty `crit` array should be rejected per RFC 7515 §4.1.11 because gose implements no header extensions, yet affected verifiers accept such tokens and report successful verification. Because `crit` lives inside the signed protected header, this is not reachable by an unauthenticated attacker without the signing key; the realistic risk is cross-context replay, where a trusted issuer constrains a token's use with a critical extension (RFC 7797 `b64:false`, RFC 7800 `cnf`, or an ecosystem `must-revoke-check`) and a gose-backed verifier silently drops that mandatory constraint. Signatures and claims remain authentic, so integrity impact is limited; no public exploit code is identified at time of analysis and the issue is not in CISA KEV. Fixed in eclipse-keypont/gose v1.0.0-rc4 (commit be2277b, merged as 692c25c); the legacy ThalesGroup module path ends at v0.13.0-rc1 and remains vulnerable.
Denial of service in Eclipse KeyPont gose occurs when a JWK declares kty EC with a non-EC alg and is passed directly to the exported LoadPublicKey or LoadPrivateKey loader; an unchecked ECDSAOptions type assertion panics the process. Affected releases are github.com/eclipse-keypont/gose before 1.0.0-rc4 and the deprecated github.com/ThalesGroup/gose path through 0.13.0-rc1, while gose's own NewVerificationKey/JWKS path gates EC algorithms and is not vulnerable. Exploitation is conditional on a consuming application forwarding externally supplied JWKs to those loaders; no CISA KEV listing or verified public exploit code is indicated, the advisory includes a reproducer, and the vendor rates the issue CVSS 4.0 6.3 with high attack complexity and availability-only impact.
Denial of service in Eclipse KeyPont's `gose` JOSE/JWT Go library: `JwtClaims.MarshalJSON` builds a runtime struct with `reflect.StructOf`, naming each field `"A" + claimName`, which panics whenever an untyped claim key is not a valid Go identifier (for example the URL-namespaced `https://example.com/roles` claims that OIDC and Auth0 mandate) or collides after prefixing (`utomaticJwtClaims`, `ettableJwtClaims`). All releases of `github.com/ThalesGroup/gose` from v0.7.3 through v0.13.0-rc1 are affected and that module path is deprecated and unpatched, while `github.com/eclipse-keypont/gose` is affected below v1.0.0-rc4 and fixed in v1.0.0-rc4. Impact is availability only (assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/C:N/I:N/A:L, vendor CVSS 4.0 6.9 Medium with VA:L), the panic is reachable from legitimate standards-compliant IdP tokens without any attacker, and it only bites callers that call `json.Marshal` on the `*jose.JwtClaims` returned by `JwtVerifierImpl.Verify` without recovering; a reproducer is documented in the upstream advisory, and no public exploit code or active exploitation is confirmed (no CISA KEV listing).
CPU exhaustion in the Go JOSE library Eclipse KeyPont gose (formerly github.com/ThalesGroup/gose) allows a hostile JWK/JWKS document to pin one CPU core for roughly 15 seconds, because the duplicate key_ops validation in jwkFields.CheckConsistency runs an all-pairs nested loop whose cost grows with the square of the entry count (CWE-407). Because that check executes on every JWK and JWKS unmarshal, any consumer that parses a JWKS body from an attacker-controlled or attacker-influenced source - a compromised or malicious identity provider, a misconfigured discovery URL, or an application that accepts a JWKS URL as user input - is exposed; the authoritative assessment rates the impact as availability-only (CVSS:3.1 AV:N/AC:H, no confidentiality or integrity effect), with the higher AC reflecting the precondition that the victim must actually fetch from the hostile endpoint rather than any attacker-uncontrolled timing condition, and notes a trusted, pinned IdP deployment is not triggerable. All releases since the earliest tag are affected on the ThalesGroup module path (>= 0.7.3, <= 0.13.0-rc1, which is deprecated and unpatched) and on the Eclipse path (< 1.0.0-rc4), with the fix first shipped in v1.0.0-rc4; there is no CISA KEV listing and no public exploit identified at time of analysis.
JwksTrustStore.Get in the Eclipse KeyPont gose JOSE library (formerly github.com/ThalesGroup/gose) can return the last key parsed from a JWKS document, with a nil error, when the caller asks for a kid that is not present in that document - so absent-key lookups silently succeed against the wrong key instead of failing as 'not found'. The flaw exists in every release from v0.7.5 through v1.0.0-rc3 of the eclipse-keypont module path, and in the deprecated ThalesGroup path up to its final tag v0.13.0-rc1; it is fixed in v1.0.0-rc4. It is not an authentication bypass: JwtVerifierImpl.Verify still enforces algorithm match and signature verification against whatever key it receives, so a token signed by an unrelated key is still rejected; the realistic impact is broken kid-to-key binding during key rotation and any downstream logic that treats kid as a trusted decision input, which is why the maintainers rate integrity impact Low with High attack complexity. There is no KEV listing and no public exploit code identified at time of analysis; the upstream advisory publishes a reproducer that demonstrates the wrong-key return against an httptest JWKS server, and the recommended handling is to fold the fix into a routine monthly patch cycle rather than an emergency response.
Denial of service in the Eclipse Keypont gose Go JWE library (published historically as github.com/ThalesGroup/gose) where AesGcmCryptor.Open forwards a caller-supplied, wire-derived nonce to crypto/cipher AEAD Open without a length check, causing the Go standard library to panic instead of returning an error. Any party able to submit a compact JWE to a gose-backed decryptor can trigger it without key material or credentials (CVSS 4.0 base 6.9; assessed CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) - they only need a kid matching a key in the decryptor's keystore, alg=dir with a matching enc, and an IV whose decoded length is anything other than 12 bytes. Impact is bounded by the caller's panic posture: under net/http the panic is recovered per request and only that request fails, while a worker, daemon or CLI without recovery has its process terminated; confidentiality and integrity are unaffected because the panic occurs before plaintext is produced. No public exploit code was identified at time of analysis, although the advisory ships a unit-test reproducer that demonstrates the panic; this_month priority, not KEV-listed.
HTTP request smuggling in Eclipse ThreadX NetX Duo's optional Web add-on allows unauthenticated remote clients to influence request-framing decisions by placing header-like field names in the request body; the embedded HTTP server scans the entire packet for headers instead of stopping at the end of the header section. The CVSS 4.0 score is 6.9, with low integrity and availability impact and no confidentiality impact, and exposure is limited to devices that enable and network-expose the Web add-on. No public exploit code or CISA KEV confirmation is present in the provided data; no public exploit identified at time of analysis.
Out-of-bounds read in the Eclipse ThreadX Module Manager's block-pool create dispatcher (_txm_module_manager_tx_block_pool_create_dispatch) lets a loaded, memory-protected module cause the kernel to read words it does not own. The dispatcher verifies only two ALIGN_TYPE words of the caller-supplied extra-parameter array, but then uses indices 0 through 3, and the out-of-bounds access happens inside the validation path itself: index 1 is taken as the pool start and index 2 as the length used to range-check it, so the size the pool start is checked against is itself an unverified word, and a further unverified word is consumed when the service argument list is built. Affected are builds using the ThreadX Module Manager with MPU-isolated modules; the vector is CVSS:4.0/AV:L/AC:L/PR:L/UI:N/VC:L/VI:N/VA:L (4.8) and our independent assessment agrees it is local, requires an already-loaded low-privilege module, and is bounded to information disclosure plus possible fault rather than code execution. No public exploit identified at time of analysis, and the issue is not in CISA KEV.
Denial of service in the Eclipse ThreadX Module Manager (CWE-400) lets a loaded user-mode module permanently drain the shared module object pool by cycling threads. Each thread a module creates consumes two allocations - a TX_THREAD control block plus a separately allocated TXM_MODULE_KERNEL_STACK_SIZE kernel stack - but the thread-delete dispatcher releases only the control block, so every valid create/terminate/delete cycle silently removes one fixed-size block from a finite pool shared by the Module Manager and all other loaded modules. A module that loops this lifecycle long enough exhausts the pool, after which no memory-protected module anywhere in the system can create kernel objects or new user-mode threads. Exploitation requires local execution of a loadable user-mode module (PR:L per the assessed CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H vector) and is purely an availability impact; no public exploit code or confirmed active exploitation was identified at time of analysis.
A crafted ThreadX module can permanently hang the entire kernel by abusing the Module Manager's object-lookup path: the search name for a memory-protected module is validated on only one byte and then walked in privileged mode for as far as the module declares. Both lookup dispatchers are affected - the recommended txm_module_object_pointer_get_extended accepts a length argument but never uses it to bound the buffer, while the deprecated txm_module_object_pointer_get passes the maximum UINT value, removing the bound entirely - so a hostile module forces an out-of-bounds read (CWE-125) without needing to know anything about the memory it reaches. Because the walk happens with the kernel's preemption count raised, an unrecoverable read fault leaves the scheduler disabled for the remainder of the device's uptime, making this a durable denial of service rather than privilege escalation or code execution. The local attack vector (CVSS 4.0 base 6.9; assessed 3.1 AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:H) requires the attacker to already be able to load or compromise a module in a build that enables the Module Manager; no public exploit code has been identified at time of analysis and there is no confirmed active exploitation (no CISA KEV listing).
Eclipse ThreadX deployments that use the Module Manager to load untrusted or mixed-trust modules let a module destroy kernel objects it does not own: the privileged dispatcher validates only that a pointer targets memory outside the caller's own code and data, which is the correct policy for *using* a shared object but not for deleting one. Any code running inside a loaded module, having obtained a pointer (for example via txm_module_object_pointer_get_extended name lookup) to an application- or peer-module-owned queue, semaphore, or mutex, can route that pointer to the kernel object delete service and have it torn down, yielding a local integrity and availability impact (CVSS 4.0 6.9; CVSS 3.1 AV:L/PR:L/UI:N/I:H/A:H, no confidentiality impact). Exploitation requires the module feature to be enabled with more than one trust domain, is local only, and does not apply to firmware built as a single monolithic trusted image; no public exploit code has been identified at time of analysis and the issue is not in CISA KEV.
Eclipse GUIX multi-line text view rendering can read one byte past the end of an application text buffer when the displayed string ends with a carriage return, and that over-read can cascade into an index overrun and a spurious text row. The issue is local and requires user interaction: an attacker must influence text rendered in a GUIX multi-line text view and a user must view that widget; impact is limited to low confidentiality and availability effects, with no public exploit identified at time of analysis. It is a low-to-moderate priority memory-safety bug in Eclipse ThreadX GUIX rather than a remotely triggerable or code-execution issue.
Truncated JPEG marker segments and a zero chroma sampling factor in Eclipse ThreadX GUIX's software JPEG decoder can trigger an out-of-bounds read and a non-terminating block-decode loop, letting a local, unauthenticated attacker who can get a crafted JPEG opened or rendered crash or hang the device and potentially disclose a small amount of adjacent memory. Both triggers reproduce in the default configuration with GX_SOFTWARE_DECODER_SUPPORT enabled; the CVSS 3.1 score is 6.1 (AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H), so the dominant outcome is availability loss rather than large-scale data theft. No public exploit code or CISA KEV entry was identified at time of analysis, and no EPSS score was provided.
An out-of-bounds read in the Eclipse ThreadX GUIX JPEG software decoder lets a crafted JPEG file expose memory beyond an undersized image buffer. The flaw affects GUIX builds with GX_SOFTWARE_DECODER_SUPPORT enabled, which is the shipped default, and is triggered by a JPEG whose marker ordering is illegal - specifically a second SOF0 frame header placed after SOS - which re-parses the frame header after the output buffer has already been allocated and its geometry latched. The decoder then returns GX_SUCCESS and publishes a GX_PIXELMAP whose reported dimensions and data_size exceed the actual allocation, so any consumer trusting the structure, including GUIX's own display drivers via the ordinary draw path, reads past the buffer; interaction is required and the attack is local (the malicious file must reach the decoder), and no public exploit code has been identified at time of analysis.
Out-of-bounds reads in Eclipse ThreadX GUIX can expose adjacent memory or terminate the application when gx_binres_theme_load() or gx_binres_font_load() processes a crafted theme or font resource that declares more data than it contains or embeds an out-of-range offset. The loaders accept a bare resource pointer with no length, so file-controlled offsets can drive reads past the buffer end; a well-formed, narrow glyph range is sufficient, and no underflow or integer-wrap is required. Exploitation is local and requires the application to load an untrusted GUIX resource, and no public exploit or CISA KEV activity is identified at time of analysis.
Out-of-bounds write in the Eclipse ThreadX GUIX binary resource theme loader lets an attacker who supplies a crafted GUIX theme file corrupt the GUIX memory arena and potentially hijack execution or crash the device. The flaw is only reachable in products that call the public API gx_binres_theme_load() on externally supplied or user-replaceable theme files, with GX_BINARY_RESOURCE_SUPPORT compiled in (the shipped default). CVSS 4.0 rates this 6.8 (Medium) with a local attack vector and required user interaction; no public exploit code and no CISA KEV entry were identified at time of analysis.
Eclipse ThreadX's memory-protected module support under-validates queue extents in the front-send path: the Module Manager's dispatch layer receives a value counted in ULONGs where it expects a byte extent, so the privileged copy in _txe_queue_front_send reads up to 3 x message_size bytes past the end of the memory a loaded module is permitted to read. The over-read words land in the queue's message area, meaning a second module (or the same one) that can receive from that queue can retrieve the adjacent memory contents. Exploitation is strictly local and requires the attacker to already control a loaded low-privilege module authorized to front-send on the target queue; there is no public exploit code and no confirmed active exploitation (no public exploit identified at time of analysis), and the assessed impact is limited information disclosure plus a possible availability effect, consistent with the 4.8 CVSS 4.0 / 4.8 CVSS 3.1 ratings.
Out-of-bounds heap read in the Eclipse ThreadX USBX host stack can be triggered when a malicious USB device presenting the MTP/PTP class is attached and the host performs ordinary object enumeration, causing adjacent heap memory to be disclosed to the application or an unmapped-page fault that crashes the host. The issue is physically gated: an unauthenticated attacker needs physical access, and the target must be running USBX in USB host mode with MTP/PTP support enabled and must enumerate the crafted device. Vendor scoring is CVSS 4.0 5.2 (Medium); no public exploit was identified at time of analysis, and impact is limited to low confidentiality loss plus possible denial of service, with no integrity impact or code execution.
Eclipse OpenJ9 through 0.63 can expose local files to a remote receiver when an analyst opens a crafted diagnostic dump bundle with jdmpview or equivalent legacy DTFJ code. The bundle's XML metadata can define an external entity that references an arbitrary local file, causing the tool to read that file and transmit its contents to an attacker-controlled host. This is a local, user-interaction-dependent issue in the legacy DTFJ XML path; no public exploit was identified at time of analysis, and the risk is moderate and context-dependent rather than a mass-exploitation priority.
An out-of-bounds read exists in the Eclipse ThreadX USBX host stack's USB Video Class handling: when a malicious USB device declares a VideoStreaming interface wTotalLength larger than the format, frame, and frame-interval descriptors it actually transmits, the host trusts that self-reported size as its parsing budget and walks past the end of the configuration buffer. The bug is only triggered when the application queries format or frame data, not during enumeration, and requires physically attaching a crafted USB device to a host built with USBX video-class host support. No public exploit code or active exploitation was identified at time of analysis, and the physical attack vector keeps practical risk low-to-moderate despite potential information disclosure and host-context denial of service.
Heap out-of-bounds read in the Eclipse ThreadX USBX USB host HID class driver is triggered during ordinary device enumeration when a physically attached HID peripheral returns a short or truncated report descriptor whose item headers declare more payload bytes than were actually transferred. The flaw affects USBX builds configured as a USB host with HID support, requires physical access and a user action to connect the device, and needs no authentication (CVSS 3.1: 4.9, AV:P/AC:L/PR:N/UI:R), with the main impact being a crash or denial of service plus limited information disclosure. No public exploit code or confirmed active exploitation was identified at the time of analysis.
Blind server-side request forgery in Eclipse PIA allows an approved OIDC identity provider to force PIA's token-verification flow to fetch an arbitrary host and port, including plaintext HTTP, from PIA's network position. The issue is in verify_token (pia/oidc.py), which follows jwks_uri from a trusted issuer's discovery document without parsing it as a URL, comparing it to the issuer origin, or requiring HTTPS, and the fetch is triggered by an unauthenticated POST /v1/upload/sbom that is then rejected with 401. Because the response is not reflected to the attacker, impact is limited to outbound GET reconnaissance/interaction; exploitation requires a high-privileged position controlling a registered per-project Jenkins issuer under https://ci.eclipse.org/<project>/oidc (PR:H), and no public exploit was identified at time of analysis.
Eclipse CSI PIA executes its pre-authentication OIDC discovery and JWKS fetch operations synchronously directly on the asyncio event loop, so a single unauthenticated request can stall the entire service for every connected user. Any network-reachable deployment that has the OIDC authentication flow enabled is affected, and exploitation needs no credentials, privileges, or user interaction (CVSS 4.0 base 6.9, AV:N/AC:L/PR:N/UI:N, availability-only with VA:L). Impact is confined to denial of service with no confidentiality or integrity effect, and no public exploit code was identified at time of analysis.
Query-parameter injection in Eclipse Jetty's TryPathsHandler and TryFilesFilter allows unauthenticated remote attackers to inject extra query parameters when a deployment uses a non-default configuration that forwards the request path into a template query string such as index?p=$path. Exposure is limited to sites using that operator-chosen pattern; the assessed CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N) and CVSS 4.0 base score of 6.9 describe a medium-severity, configuration-dependent flaw whose realized impact depends on how the backend interprets the smuggled parameters. No public exploit code or confirmed active exploitation was identified at time of analysis.
A heap-based out-of-bounds write in Eclipse ThreadX GUIX's gx_binres_theme_load() lets a local attacker corrupt memory by supplying a binary theme resource in which the requested theme id is at or beyond the theme count the resource declares. The loader sizes and allocates a zero-byte buffer for that out-of-range id, then walks past the end of the theme table and writes a GX_THEME structure and its tables into the empty allocation, producing out-of-bounds heap corruption. Exploitation requires local placement or substitution of the malicious resource plus application/user interaction to load it (AV:L, PR:N, UI:R), so risk is moderate rather than high; no public exploit has been identified at time of analysis.
Information disclosure in the Eclipse ThreadX NetX Duo embedded TCP/IP stack's FTP server addon lets a network attacker consume data belonging to an authenticated FTP session, because the server never ties the passive-mode data connection back to the peer on the control channel. Exploiting this requires the target to be running the NetX Duo FTP server and a client to be performing or negotiating a passive-mode transfer at the moment of attack, and the attacker must reach the announced passive port and win a connection race against the legitimate client before it connects; no authentication is required (PR:N), but the timing dependency makes complexity high (AC:H, UI:P) and the impact is limited to confidentiality (C:H/I:N/A:N, CVSS 4.0 base 6.0). No public exploit code and no confirmed active exploitation were identified at time of analysis, and the flaw should be treated as a genuine but moderate-priority confidentiality issue rather than a high-severity one.
Crafted IPCP configuration options sent by a PPP peer can stall a NetX Duo worker thread and drive an out-of-bounds read in Eclipse ThreadX NetX Duo builds that enable the PPP/IPCP add-on. Only devices that terminate PPP links (serial, cellular modem, PPPoE, or L2TP) and accept negotiation traffic from an attacker-controlled or untrusted peer are exposed, and the assessed vector (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H) reflects adjacency rather than remote reachability. Exploitation is unauthenticated and needs a specifically crafted IPCP option with an oversized declared length, but no public exploit code has been identified and the issue is not listed in CISA KEV at time of analysis.
Out-of-bounds reads in Eclipse NetX Duo's MSRP (Multiple Stream Reservation Protocol) attribute-list parser allow an attacker positioned on the same layer-2 network segment to crash a device by supplying a malformed attribute list whose length field is never validated. The flaw affects NetX Duo builds that have the MSRP / TSN-AVB stream-reservation feature compiled in and actively processing MSRP traffic; because exploitation requires adjacent-network access and yields only a denial of service - no confidentiality or integrity impact, and no code execution is claimed - this is a bounded availability issue rather than a remotely exploitable high-severity defect. There is no CISA KEV listing and no public exploit code identified at time of analysis, so exploitation is assessed as unconfirmed.
Eclipse NetX Duo can be crashed (high availability impact) by an unauthenticated attacker on the same Layer-2 network segment who manipulates MSRP attribute state so that the sole remaining MSRP attribute is evicted, triggering a NULL pointer dereference. This is a genuine but bounded availability-only risk: MSRP (IEEE 802.1 AVB/TSN) must be enabled, and the attacker must achieve a precise attribute-table condition (AT:P), so it is not a stateless single-packet trigger. No public exploit code has been identified at time of analysis; the vendor-assigned CVSS 4.0 base score is 6.0, and our independent CVSS 3.1 assessment (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms adjacent-only, state-dependent denial of service.
Attribute table exhaustion in Eclipse ThreadX NetX Duo's MSRP (Multiple Stream Reservation Protocol) handling triggers a NULL pointer dereference that halts the affected device, producing an availability-only denial of service. Only deployments where MSRP/AVB-TSN support is compiled in and actively running are exposed, and the attacker must be on the same Layer-2 bridged segment because MSRP frames are not routed outside the local bridge domain. No public exploit code has been identified at time of analysis, and success requires sustained flooding of attribute registration frames rather than a single packet, giving this an assessed severity in the moderate range despite the total loss of availability on a targeted device.
The FTP client component of Eclipse ThreadX NetX Duo trusts the IPv4 address returned in a server's 227 PASV reply, performing only parse and non-zero checks before opening a data connection to that address, which lets a malicious or man-in-the-middle FTP server redirect the client's data transfer to any host it names (CWE-918 server-side request forgery class). Only the IPv4 passive-mode path is affected; the client must itself initiate an FTP control session to a hostile or intercepted endpoint and then request a passive transfer. No authentication or user interaction beyond starting the session is required (CVSS:4.0 base 6.9; independent assessment CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), and no public exploit code or active exploitation has been identified at time of analysis.
An out-of-bounds read in the Eclipse NetX Duo TFTP client lets an attacker-controlled or man-in-the-middle TFTP server return a short ERROR packet that causes the client to read up to 64 bytes past the received datagram. The vulnerable receive paths are in the TFTP client add-on and an unauthenticated remote attacker can trigger the condition when a device initiates a TFTP read or open against the attacker's server, potentially disclosing adjacent packet-pool memory if the application logs or displays nx_tftp_client_error_string, and potentially causing a crash. No public exploit identified at time of analysis, and the provided advisory points to a code-level bounds-check fix; risk is moderate rather than critical because exploitation requires the client-initiated, attacker-as-server model and yields no write primitive.
An out-of-bounds heap read in the DHCP client addon of Eclipse ThreadX NetX Duo (nxd_dhcp_client.c) allows an attacker on the same local link to disclose adjacent heap memory whenever a device performs a DHCP acquisition. The attacker only needs to be a DHCP server, or any LAN host that wins the race to answer the client's broadcast DISCOVER first, and to reply with a single OFFER containing a long run of skippable TLV options; a malformed option layout causes the parser's offset counter to lag the actual read pointer, producing a read roughly a kilobyte and beyond past the end of the message (a one-byte read 164 bytes past a 1648-byte heap region in the reported AddressSanitizer trace). The issue occurs unauthenticated (CVSS PR:N), from an adjacent network (AV:A), on every boot while the interface is unconfigured, with bounded impact limited to low confidentiality and low availability (CVSS 5.3); no public exploit code or confirmed active exploitation was identified at time of analysis.
Eclipse NetX Duo's DTLS server implementation uses predictable HelloVerifyRequest cookies due to insufficient randomness (CWE-330), enabling unauthenticated remote attackers to bypass source-address validation and potentially facilitate amplification attacks. Affected deployments are those running NetX Secure as a DTLS server with cookie exchange enabled; exploitation requires high attack complexity and no public exploit or active exploitation has been identified. The independent assessment rates this as a moderate, narrow-trigger weakness.
Out-of-bounds heap read and a control-flow-integrity gap in the Eclipse ThreadX loadable-module loader (module manager) allow an attacker-supplied module image to trigger out-of-bounds memory disclosure when the device loads it through `_txm_module_manager_memory_load` or `_txm_module_manager_in_place_load`. The affected code fully trusts every size and offset field in `TXM_MODULE_PREAMBLE` - the loader APIs accept only a base pointer and no image length, and the preamble `checksum` is never verified - so `code_size` can drive the code-copy loop past the end of the source image; the copy destination is overflow-guarded, so no controlled out-of-bounds write was found. Exploitation is local and conditional: no authentication or privileges are required (PR:N), but attack complexity is high, user/operator action is needed to trigger the load, and only systems that actually load third-party or externally supplied modules are exposed; no public exploit was identified at time of analysis.
Eclipse NetX Duo's NetX Secure TLS stack accepts empty application-data records without ever generating or comparing their message authentication code, so the receive sequence number advances on records that were never integrity-checked. An unauthenticated remote attacker who holds a man-in-the-middle position on an already-established TLS connection can inject such records into the stream, yielding a bounded loss of integrity and availability (no confidentiality impact). Exploitation is constrained by high attack complexity, no public exploit code has been identified at time of analysis, and the issue is not confirmed as actively exploited (no CISA KEV listing).
Eclipse iceoryx2 versions after v0.8.0 up to v0.9.x contain a Rust soundness defect in which StaticString exposes its contents as mutable bytes via safe APIs, and the associated String::as_str() conversion does not validate UTF-8, allowing safe Rust code to construct an invalid &str and trigger undefined behavior. Exploitation requires a local authenticated attacker with low privileges and high attack complexity, and it additionally depends on an application coded in the vulnerable pattern; impact is limited to minor integrity and availability loss with no confidentiality impact, and the defect is not remotely exploitable against a default configuration. No public exploit code or active exploitation has been identified, and the vendor has released a patched version v0.10.0.
Local attackers holding a low-privileged workload on an Eclipse Ankaios agent can bypass log-access authorization to read other workloads' logs on the same agent. The flaw affects Eclipse Ankaios 0.6.0 through 1.0.3, where the agent's control-interface authorizer stops evaluating a rule at the first wildcard pattern and therefore skips later deny LogRule entries; exploitation requires a rule set in which a wildcard-containing entry precedes a deny rule. This is a low-severity authorization flaw (CVSS 4.8, CWE-863) requiring local access and an existing workload foothold, with no public exploit identified at time of analysis.
Let me synthesize. Product: Siglet / Eclipse Data Plane Core. The description mentions "Siglet" refresh token handler, CPE says eclipse_data_plane_core. Primary product name — 1-3 words. Probably "Eclipse Data Plane Core" or "Siglet". Let me pick "Siglet" — hmm, the CPE is Eclipse Data Plane Core. The description says "In Siglet current and past versions". Siglet appears to be a component within Eclipse Data Plane Core (Eclipse Dataspace Components). Tags list Eclipse Data Plane Core. I'll use "Eclipse Data Plane Core" as primary? The rules say pick primary product. The CPE is the authoritative affected product. But description says Siglet. Hmm. I'll say "Siglet" — actually product_name 1-3 words only. Let me choose "Eclipse Data Plane Core" (4 words? Eclipse, Data, Plane, Core = 4 words). That violates 1-3 words. "Siglet" is 1 word. I'll go with "Siglet". Hmm, but the affected products refer to Eclipse Data Plane Core. Perhaps Siglet is the SSI/token component. I'll use "Siglet" as product name and mention Eclipse Data Plane Core in affected_products. Actually, to be safe, maybe "Eclipse Data Plane Core" — 4 words is over. Let's use "Siglet". CVSS 6.3, vector CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N — network, high complexity, no privileges, no UI, low impact on C/I/A. CWE-290: Authentication Bypass by Spoofing. Issue: refresh token handler does not enforce proof of possession of the issuer DID. So an attacker who obtains a refresh token (or can present a refresh token) without proving possession of the private key corresponding to the issuer DID can redeem it — token theft/replay allows issuing new access tokens. That's authentication bypass by spoofing: the token handler accepts a refresh token without verifying the DID key binding. Affected versions: Eclipse Data Plane Core 0.1.0 ≤ 0.1.3 and commit range a6f7d4cc... < 882fe22d... Patch: Available from vendor. The commit 882fe22db42bc67abfd0304c4cdb141b762c35d1 is likely the fix com
Disk exhaustion via zip bomb in Eclipse OpenVSX allows a publisher to cause persistent service disruption on any OpenVSX server instance. A publisher uploads a small, highly compressed VSIX (zip bomb) that the server decompresses without size limits when any client requests a file via /vscode/unpkg/; the decompressed content is cached to java.io.tmpdir under an entry-count eviction policy with no total-size bound, enabling repeated disk exhaustion through new filenames or versions. Impact includes HTTP 500 errors for all uncached resources, publishing failures with 'Failed to read extension file', and a poisoned cache entry that blocks future requests to the same path. No public exploit has been identified at time of analysis, and EPSS data is not available in the provided input.
Server-side request forgery in Eclipse Che dashboard backend (versions 7.79.0-7.121.0) enables any authenticated user to make the backend issue arbitrary outbound HTTP GET requests to internal network targets, including the cloud instance metadata service at 169.254.169.254, loopback interfaces, RFC-1918 ranges, and in-cluster Kubernetes service endpoints. The POST /dashboard/api/data/resolver endpoint forwards caller-supplied URLs with no host validation and without consulting the operator-configured allowlist (spec.devEnvironments.allowedSources.urls). The vulnerability is fixed in 7.122.0, which introduces private-address blocking, IPv4-mapped IPv6 bypass prevention, allowlist enforcement, and disables outbound redirect following. No public exploit or CISA KEV listing identified at time of analysis.
Uncontrolled memory allocation in Eclipse Ankaios 0.1.0-1.0.1 allows a workload with granted Control Interface access to abort the agent process by declaring an arbitrarily large protobuf message length over the Control Interface FIFO, causing unbounded heap allocation and an OOM-triggered process crash. The impact is complete loss of orchestration services for all workloads managed by the affected agent instance. No public exploit has been identified and no active exploitation is confirmed; patch v1.0.2 is available.
Server-side request forgery in Eclipse Ditto's Things service allows authenticated users with WRITE permission on a Thing to force the service to issue arbitrary HTTP GET requests to any host reachable from within the deployment's internal network. The vulnerability arises because the Things service fetches WoT ThingModel documents from attacker-supplied URLs in the Thing or Feature `definition` field without validating the target host, without re-validating redirect targets, and without enforcing a redirect hop limit. Attackers can leverage cloud instance-metadata endpoints (e.g., AWS IMDS at 169.254.169.254) and exploit differing HTTP error responses to enumerate internal services. No public exploit or CISA KEV entry exists at time of analysis.
Path traversal in Eclipse SW360's optional filesystem attachment store allows authenticated low-privilege users to write files to arbitrary paths on the host operating system by crafting malicious filenames during attachment upload. Affected versions span 19.0.0 through 20.1.0 exclusively when the non-default `enable.attachment.store.to.file.system` configuration key is active. The CVSS 4.0 score of 6.0 (AT:P, PR:L, VI:H) reflects meaningful integrity impact gated behind a specific configuration requirement; no public exploit has been identified at time of analysis.
Eclipse OpenJ9 JVM versions through 0.60 crash with a segmentation fault when processing a crafted .class file containing deeply nested annotations, enabling a denial-of-service attack against any Java application running on OpenJ9 where an attacker can supply class files for loading. The vulnerability is rooted in uncontrolled recursion (CWE-674) within the bytecode utility annotation parser, which exhausts the OS thread stack without triggering a recoverable error path. No active exploitation has been confirmed by CISA KEV and no standalone exploit code has been publicly identified, though the public GitHub fix PR clearly exposes the triggering mechanism and root cause.
Session security diagnostics nodes in Eclipse Milo 0.6.0 through 1.1.4 expose sensitive OPC UA session metadata without enforcing any authorization checks, a CWE-862 (Missing Authorization) flaw. An unauthenticated anonymous client connecting over a None/None (no-security) endpoint can enable the diagnostics subsystem with no certificate or credentials whatsoever; separately, a client presenting a trusted application certificate over SignAndEncrypt can read the SessionSecurityDiagnosticsArray for all active server sessions, harvesting usernames, login history, authentication mechanisms, session security modes and policies, and public client certificates. No public exploit code exists and the vulnerability is not listed in CISA KEV, but the zero-authentication path and prevalence of None/None endpoints in legacy OT/IIoT environments meaningfully lower the exploitation barrier.
Unauthenticated remote clients can permanently exhaust the global monitored-item quota in Eclipse Milo OPC UA SDK versions 1.0.0 through 1.1.4, effectively preventing all clients from creating new monitored items until the server is restarted. The attack combines two defects: the server's ExtensionObject decoder lacks recursion-depth enforcement, enabling deeply nested PubSub structures in a CreateMonitoredItems event filter to trigger a JVM StackOverflowError, and the quota accounting code is not exception-safe against unchecked JVM Errors, so the reserved slot is never reclaimed. No public exploit code has been identified and this CVE is absent from the CISA KEV catalog; however, the CVSS 4.0 vector AV:N/AC:L/PR:N/UI:N confirms the attack is network-reachable with no authentication or complexity barriers.
Incorrect interface method dispatch in Eclipse OpenJ9 up to version 0.60 causes the JVM to silently execute an unintended interface default method instead of raising AbstractMethodError or IllegalAccessError when a previously JIT-compiled concrete superclass method is subsequently recompiled as abstract. Applications running on OpenJ9 with dynamic class-loading or OSGi-style hot deployment are at risk of integrity violations - untended code paths execute where exceptions should be thrown. No confirmed active exploitation exists and this CVE does not appear in CISA KEV; EPSS data was not provided, and the high attack complexity (AC:H) and specific attack prerequisites (AT:P) significantly limit real-world exploitability.
Out-of-bounds read in Eclipse OMR's arraycmp SIMD JIT implementation for IBM Z (s390x) and IBM POWER (P10) architectures - versions up to 0.11 - allows a low-privileged network-reachable attacker to trigger an application crash when a zero-length array comparison is JIT-compiled and executed. The flaw exists exclusively in the SIMD code-generation paths for these two architectures and has no impact on x86 or ARM deployments. No active exploitation has been confirmed (no CISA KEV listing) and no public exploit has been identified at time of analysis; exploitation is further constrained by high attack complexity and the requirement for user interaction.
Buffer underflow (CWE-124) in Eclipse OpenJ9 versions through 0.60 allows memory corruption via the JVM method argument tracing subsystem when the -Xtrace diagnostic flag is active, with potential high integrity and availability impact to the running JVM process. The defect resides in traceMethodArguments() within the trace runtime, where the cursor pointer could be decremented past the start of the allocated trace buffer when constructing an ellipsis truncation marker - a classic buffer underwrite. No active exploitation is confirmed in CISA KEV, and no public exploit code has been disclosed at time of analysis.
Privilege escalation in Eclipse hawkBit's Direct Device Integration (DDI) Controller allows any authenticated device to download firmware artifacts beyond those explicitly assigned to it, within the same tenant. The flaw - rooted in missing object-level authorization (CWE-284/CWE-862) - means a valid device credential is sufficient to access arbitrary firmware artifacts belonging to other devices in the same tenant, not just the device's own assigned updates. A secondary enumeration weakness in the software modules listing endpoint compounds the issue by enabling targeted discovery of available artifacts. No public exploit has been identified at time of analysis, and no CISA KEV listing is present.
Eclipse Jetty mishandles HTTP URI path parameters containing semicolons combined with traversal sequences, delivering an unresolved path (e.g., `/public/../admin/secret.txt`) to downstream web applications instead of the canonicalized form (e.g., `/admin/secret.txt`). Web applications that delegate path-based authorization decisions to Jetty-provided paths are susceptible to confusion attacks where an attacker crafts a URI like `/public;/../admin/secret.txt` to receive a path that bypasses application-layer access controls. Jetty itself is shielded by its alias checker and will not serve restricted files directly; the integrity risk materializes only in applications that consume the unresolved path for routing or authorization logic. No public exploit code or CISA KEV listing is present at time of analysis.
Eclipse Jetty fails to enforce RFC 9110/9112's requirement that the HTTP request authority (host and port) match the value in the Host header across all supported protocol versions - HTTP/1, HTTP/2, and HTTP/3. Unauthenticated network attackers can exploit this input validation gap to manipulate Host-header-derived URI constructions (particularly redirect targets on login pages), influence virtual host selection, corrupt reverse proxy routing decisions, and produce misleading access logs. No public exploit has been identified at time of analysis and the vulnerability is not in CISA KEV, but the attack surface is meaningful in any Jetty deployment that performs host-based routing or generates redirects from the Host header.
HTTP/1.1 trailer leakage in Eclipse Jetty allows a remote unauthenticated attacker to read trailer headers from a previous request when sharing a persistent connection with another party. Trailers sent in an initial request are incorrectly retained in the server's connection state, causing them to bleed into all subsequent requests on the same keep-alive connection - either appended wholesale (if the later request has no trailers) or merged with the later request's own trailers. No public exploit has been identified at time of analysis, and the vulnerability is not listed in CISA KEV.
HTTP request smuggling in Eclipse Grizzly before 5.0.2 stems from the framework's inability to correctly parse malformed trailer header lines in chunked HTTP requests, enabling CWE-444 boundary-confusion attacks. Remote unauthenticated attackers who can send crafted chunked requests through a front-end proxy to a GlassFish-backed server can cause the proxy and Grizzly to disagree on request boundaries, smuggling attacker-controlled content as the prefix of a subsequent legitimate user's request. No public exploit code and no CISA KEV listing have been identified at time of analysis, though the CVSS 4.0 AT:P condition signals that specific deployment prerequisites must be met.
Eclipse KUKSA Databroker 0.6.1 panics in a Tokio worker thread when an authenticated client sends a PublishValueRequest with a valid signal_id but omits the optional data_point field, causing the server to call Rust's unwrap() on a None value. Any client holding a valid JWT token can trigger this condition, cancelling the individual gRPC call while leaving the Databroker process intact and available. No public exploit has been identified and this vulnerability is not listed in CISA KEV; EPSS data was not supplied in available intelligence.
Log injection in Eclipse CSI PIA's unauthenticated /v1/upload/sbom endpoint allows a remote attacker to plant forged authentication-success log entries that are byte-for-byte indistinguishable from genuine PIA audit events. PIA is an authentication broker whose logs are explicitly designated as the authoritative source for incident response (DESIGN.md §5.4), meaning the forgery directly subverts the audit trail the service exists to produce. No public exploit has been identified at time of analysis, but the attack requires no authentication and minimal technical sophistication.
Out-of-bounds read in Eclipse tinydtls prior to commit b3efd41ad111a4920f599f51ffa4f5e9f1e72221 allows unauthenticated network attackers to crash memory-constrained IoT devices by sending a specially crafted Certificate handshake message during DTLS epoch 0. The vulnerable check_server_certificate() function omits buffer length validation before uint24 reads, memcmp, and memcpy operations, enabling reads beyond valid buffer boundaries on both client and server code paths. No public exploit code or active exploitation has been identified at time of analysis; however, the unauthenticated, network-reachable nature makes this straightforward to trigger against any exposed tinydtls endpoint.
Stored XSS in Eclipse Open VSX Registry allows authenticated extension publishers to embed malicious JavaScript inside SVG files uploaded as extension icons, which are stored and re-served without sanitization or protective headers. On local-storage deployments, script execution occurs within the Open VSX application origin, enabling session hijacking, authentication token theft, and unauthorized extension publishing on behalf of victims. On CDN-backed deployments (such as open-vsx.org using S3), scope is reduced to the storage origin - still usable for phishing and credential harvesting. No public exploit code has been identified at time of analysis and CISA has not listed this in KEV.
Unconstrained Markdown image rendering in Eclipse Theia's AI chat component, in all versions prior to 1.71.0, enables silent data exfiltration when combined with prompt injection via a malicious workspace. An attacker who delivers a crafted workspace can inject instructions into the AI agent's context, causing it to construct Markdown image tags whose URLs encode sensitive workspace or conversation data; when the IDE renders these images, it issues HTTP GET requests transmitting that data to an attacker-controlled server. No public exploit has been identified and the vulnerability is not listed in CISA KEV, but the local-access, active-user-interaction model (CVSS 4.0: 6.7, AV:L/UI:A) correctly reflects that this is a targeted, workspace-delivery attack rather than a remote, unauthenticated threat.