Vulnerabilities

Eclipse GlassFish versions in the 8.0.x line before 8.0.4 combine a cross-site request forgery (CSRF) issue with a server-side request forgery (SSRF, CWE-918) in the DownloadServlet ContentSources feature, which can send the domain's administrative REST token (gfresttoken) to an attacker-controlled host. The attack is triggered when an administrator who is logged into the GlassFish Admin Console is lured to attacker-controlled content, at which point the SSRF leaks the token to the attacker's server. Using the leaked token, the attacker gains full, unauthenticated control of the affected GlassFish domain — with high-impact confidentiality, integrity, and availability consequences per the 9.6 CVSS score — until the token expires. Only deployments running Eclipse GlassFish 8.0.x releases prior to 8.0.4 are affected, and the attack requires an admin actively using the Admin Console from a browser that can reach attacker-controlled pages. No in-the-wild exploitation is currently known; a public proof-of-concept report exists, the flaw is not in CISA KEV, and EPSS rates the 30-day exploitation probability at just 0.3%.

Do: Upgrade Eclipse GlassFish to 8.0.4 or later. As interim mitigation, restrict Admin Console access (e.g., limit the admin listener to trusted networks), avoid browsing untrusted sites while logged into the Admin Console, and review server logs for unexpected outbound requests to unfamiliar hosts that could indicate token leakage. If a leak is suspected, invalidate active admin sessions/tokens and rotate administrator credentials.

Eclipse Theia up to and including 1.73.1 binds an unauthenticated POST /file-upload endpoint in every filesystem-enabled deployment, and the handler writes the uploaded file to an attacker-supplied absolute path with overwrite enabled and no workspace confinement. Because the HTTP middleware in browser (non-Electron) deployments does not reject tokenless requests and multipart/form-data is CORS-safelisted, a malicious web page a user simply visits can trigger the write cross-origin with no preflight and no credentials. An attacker gains arbitrary file write anywhere the backend process can write, which can escalate to remote code execution, for example by overwriting a startup-executed file such as ~/.bashrc. Affected users are operators of Theia instances running in browser mode with the filesystem extension; Electron-mode deployments use a separate security token and are not affected through this path. Public proof-of-concept write-ups exist in the Eclipse vulnerability tracker, but there are no confirmed in-the-wild exploits, the flaw is not in CISA KEV, and EPSS puts 30-day exploitation probability at about 0.4%.

Do: Upgrade Eclipse Theia to the first patched release after 1.73.1 per the Eclipse security advisory (GitLab vulnerability report 595). Until then, restrict network access to the Theia backend, enforce connection-token checks on HTTP routes, or disable/restrict the /file-upload binding, and verify whether your deployment runs in browser mode versus Electron and is reachable from user web browsing.

Eclipse Mojarra versions 2.3 and later mishandle URLs in `DefaultFaceletFactory`, failing to properly sanitize or block remote URLs when loading Facelets. An attacker who can influence the Facelet URL supplied to the factory can cause the target server to fetch and process a remote Facelet as part of a normal request, without authentication. Because the included resource is processed with the privileges of the target server, this can expose restricted files such as `WEB-INF/web.xml` or `/etc/passwd`; per the CVSS score, impact is limited to confidentiality. Any application running on Mojarra 2.3 or later where user-controlled input can reach Facelet URL resolution is potentially affected. Exploitation has not been reported in the wild (not in CISA KEV), one public proof-of-concept reference exists, and EPSS estimates only about a 0.4% chance of exploitation in the next 30 days.

Do: Check whether your applications use Mojarra 2.3 or later and whether user input can influence Facelet URLs, then upgrade to the patched Mojarra release identified in the Eclipse security advisory (see the Eclipse vulnerability report work item for fixed versions). As interim mitigation, restrict or disable remote URL resolution in `DefaultFaceletFactory`, limit the server's outbound fetch capability, and ensure `WEB-INF` contents are not readable through application views.

In Eclipse Accessibility Tools Framework (ACTF) versions up to 1.6.0 (including source code versions up to v20260630 and ACTF based application miChecker versions up to 3.1.0), it has been identified that an XML External Entity (XXE) vulnerability exists. If this vulnerability is exploited, a malicious third party could gain access to local resources or internal network resources via computer running applications that use Eclipse ACTF, including miChecker.

In Eclipse Milo versions 0.6.0 through 1.1.4, username-token processing returns distinguishable errors for invalid RSA PKCS#1 v1.5 padding and other authentication failures, allowing an on-path attacker who captures a victim's `Basic128Rsa15`-encrypted username token to use repeated unauthenticated `ActivateSession` requests as a padding oracle, recover the victim's password, and authenticate with the recovered credentials.

Eclipse Jetty's server-side HTTP Digest authentication encodes passwords as ISO-8859-1 bytes, so any character outside that set (for example Chinese, Cyrillic, or Greek letters) is silently replaced with a '?' during the digest computation. An attacker can send a crafted Digest 'Authorization' header whose password consists solely of '?' characters, and the server will accept it as a match for any user password of the same length that contains non-ISO-8859-1 characters. This results in an authentication bypass (CWE-303, CWE-173): the attacker gains the privileges of the targeted user account, consistent with the CVSS 4.0 score of 8.7 (High) with high confidentiality impact and no direct integrity or availability impact. Only Jetty deployments that use HTTP Digest authentication where at least one account password contains non-Latin characters are affected; deployments using ASCII-only passwords, other authentication mechanisms, or RFC 7616 charset-aware (UTF-8) Digest handling are not impacted. There are no confirmed in-the-wild exploitation reports: the flaw is not in CISA KEV, EPSS estimates a 0.5% probability of exploitation in the next 30 days (40th percentile), and the vendor advisory (GHSA-2fvj-hgj9-j2gr) has been published with details.

Do: Audit whether your Jetty deployments enable HTTP Digest authentication and whether any Digest-auth accounts use passwords containing non-ASCII characters; if Digest authentication is not enabled, exposure is limited. Upgrade Jetty to the fixed release identified in the vendor advisory GHSA-2fvj-hgj9-j2gr (exact version numbers are not included in the available data). Until patched, mitigate by disabling Digest authentication, restricting Digest-auth accounts to ASCII-only passwords, or rotating any non-Latin passwords that could be impersonated.

In Eclipse OpenJ9 versions up to 0.60, when executing class files where a previously concrete superclass method has been recompiled as abstract, execution is incorrectly delegated to an interface default method.

In Eclipse OMR versions up to 0.11, the arraycmp SIMD implementation for Z and P does not check if the number of bytes to compare is zero.

In Eclipse hawkBit versions 1.0.3 and prior, a privilege escalation vulnerability (CWE-284 / CWE-862) has been identified in the Direct Device Integration (DDI) Controller. This vulnerability allows an authenticated device to escalate its permissions and bypass the strict boundaries of its assigned updates. Under normal operation, a device should be restricted strictly to the specific firmware artifacts explicitly assigned to it. However, this flaw enables any authenticated device to bypass this restriction and download any firmware artifact within the same tenant. This is not an authentication bypass; the requesting device must possess valid credentials for its respective tenant. Instead, the issue stems from a flaw in object-level authorization validation. A related, lower-severity helper issue exists in the listing software modules artifacts metadata endpoint. This endpoint does not enforce assignment checks, enabling an authenticated device to list and enumerate available firmware artifacts, which can facilitate targeted exfiltration using the main download authorization bypass.

Eclipse Kura versions prior to 5.6.2 trust the client-supplied X-Forwarded-For HTTP header as the authoritative source of the client IP address in audit log entries. The org.eclipse.kura.web2 (Web Console) and org.eclipse.kura.rest.provider (REST API) components use this header as the primary IP source when initializing audit context, and org.eclipse.kura.jetty.customizer unconditionally installs Jetty's ForwardedRequestCustomizer on all HTTP/HTTPS connectors, causing HttpServletRequest.getRemoteAddr() to reflect the attacker-controlled header value. An unauthenticated remote attacker can exploit this vulnerability to bypass IP-based brute-force protections — such as fail2ban — by spoofing the logged IP address to a non-routable value, allowing a brute-force attack to proceed undetected, or to cause a denial of service against a third party by injecting a victim's IP address and triggering a ban on that address.

For requests that have a body, but reading the body may end up in reading 0 bytes, there is a buffer leak. This is particularly the case for 100-Continue, but any request where the network is slow can leak.

In versions up to and including 4.5.29 (4.x branch) and 5.1.4 (5.x branch), the WebClientSession component of Eclipse Vert.x Web Client does not validate that the Domain attribute of a Set-Cookie response header matches the originating server's domain, in violation of RFC 6265 section 5.3. An attacker who controls any server that the victim application contacts can inject a cookie scoped to an arbitrary third-party domain; because the session store performs no cross-domain ownership check, it stores and later transmits that cookie to the targeted domain. When the victim application subsequently sends a request to the targeted domain using the same WebClientSession, it presents the attacker-injected cookie, causing the receiving service to process the request under the attacker's account. Sensitive data included in the victim application's requests, such as payment amounts, card details, or other API payloads, may then be accessible to the attacker through their own account on that service.

In Eclipse KUKSA Databroker version 0.6.1, the kuksa.val.v2.VAL/PublishValue gRPC handler fails to validate the existence of the optional data_point field in PublishValueRequest. When a request contains a valid signal_id but omits data_point, the server directly calls unwrap() on request.data_point, triggering a panic in the Tokio worker thread. This issue can be triggered by any client holding a valid JWT token. Unauthenticated or invalid-token requests are rejected and do not reach the vulnerable path. The panic causes the individual gRPC call to be cancelled but does not terminate the Databroker process, which remains available for subsequent requests.

Eclipse Grizzly in versions before 5.0.2, cannot properly parse the trailer section in malformed trailer header's line, which can be leveraged to perform HTTP request smuggling. Grizzly 5.0.1 supports system properties that enable the behavior that fixes the vulnerability - set org.glassfish.grizzly.http.STRICT_HEADER_NAME_VALIDATION_RFC_9110 and org.glassfish.grizzly.http.STRICT_HEADER_VALUE_VALIDATION_RFC_9110 system properties to "true".

In Open VSX Registry before 1.0.2, the /vscode/unpkg/ endpoint serves user-supplied HTML files with Content-Type: text/html and without a Content-Security-Policy or Content-Disposition: attachment response header. An unauthenticated attacker can register a publisher account, upload a VSIX containing a crafted HTML payload, and induce an authenticated user to visit the resulting URL. The browser renders the file inline in the open-vsx.org origin context, enabling session token exfiltration, persistent Personal Access Token (PAT) generation, and unauthorized publication of malicious extension versions. Because Open VSX extensions are distributed to VS Code, VSCodium, Cursor, Windsurf, and compatible editors, a compromised extension update constitutes a supply chain attack against all downstream users.

Open VSX Registry does not sanitize SVG files uploaded as extension icons prior to storage, and serves them with Content-Type: image/svg+xml without security headers such as Content-Security-Policy or Content-Disposition: attachment. This allows an attacker to publish an extension with a malicious SVG icon and achieve stored cross-site scripting (XSS) when a user navigates directly to the icon URL. On deployments using local storage, script execution occurs within the Open VSX application origin, enabling session hijacking, authentication token theft, and unauthorized extension publishing. On deployments backed by external storage (such as open-vsx.org with an S3-backed CDN), execution is confined to the storage origin, reducing impact but still permitting phishing attacks and credential harvesting through attacker-crafted pages.

The security fix for CVE-2025-0728 in eclipse-threadx NetX Duo refactors error handling in the HTTP server PUT process to use a shared cleanup label, but this unified cleanup path unconditionally calls fx_file_close() even when the file was never successfully opened. Multiple error branches jump to the shared cleanup label before any file open operation has occurred, causing fx_file_close() to operate on an uninitialized file handle, leading to undefined behavior, double-close issues, or memory corruption.

In Eclipse Theia versions prior to 1.71.0, files matching the pattern .prompts/*.prompttemplate in a workspace were automatically loaded and could override or extend the AI agent's system prompts. An attacker could craft a malicious repository containing prompt template files that, when the workspace was opened in Theia, replaced the AI's system instructions with attacker-controlled content (indirect prompt injection). Combined with other AI chat features available in untrusted workspaces, this enabled attack chains leading to data exfiltration via Markdown image rendering or arbitrary command execution via task definitions.

In Eclipse 4diac FORTE versions 3.0.0 to 3.1.0, a specially crafted DELETE connection command to the management interface can lead to a dangling pointer. This allows subsequent commands to access freed memory (use-after-free).

A critical Remote Code Execution (RCE) vulnerability was identified in the server-side template rendering mechanism used by the Glassfish gadget handler. The application processes .xml files and evaluates user-supplied values within a context where Expression Language (EL) “expressions” are processed without proper sanitization or escaping. By injecting expressions such as #{7*7}, the server returns 49, confirming server-side EL evaluation. This issue allows a remote attacker to fully compromise the underlying host, enabling capabilities as reading/modifying data, executing arbitrary commands, persistence, and lateral movement. This issue affects Eclipse GlassFish: from 8.0.0 to 8.0.1, fixed in 8.0.2; 7.1.0, fixed in 7.1.1; from 7.0.0 to 7.0.25, fixed in 7.0.26. Impact on versions from 5.1.0 to 6.2.5 is unknown.

A TCP client can perform a TLS handshake and present the server name extension with a server name that is accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where xyz is a valid name can be used.

In Eclipse Open9J versions 0.21 to 0.58, a pre-authentication remote attacker can crash JITServer by sending a 32-byte crafted TCP message.

In Eclipse Jetty, the HTTP/1.1 parser is vulnerable to request smuggling when chunk extensions are used, similar to the "funky chunks" techniques outlined here: * https://w4ke.info/2025/06/18/funky-chunks.html * https://w4ke.info/2025/10/29/funky-chunks-2.html Jetty terminates chunk extension parsing at \r\n inside quoted strings instead of treating this as an error. POST / HTTP/1.1 Host: localhost Transfer-Encoding: chunked 1;ext="val X 0 GET /smuggled HTTP/1.1 ... Note how the chunk extension does not close the double quotes, and it is able to inject a smuggled request.

In Eclipse Jetty, the class JASPIAuthenticator initiates the authentication checks, which set two ThreadLocal variable. Upon returning from the initial checks, there are conditions that cause an early return from the JASPIAuthenticator code without clearing those ThreadLocals. A subsequent request using the same thread inherits the ThreadLocal values, leading to a broken access control and privilege escalation.

An unsafe parsing of OpenMQ's configuration in OpenMQ versions <6.5.2 and <6.9.0, allows a remote attacker to read arbitrary files from a MQ Broker's server. A full exploitation could read unauthorized files of the OpenMQ’s host OS. In some scenarios RCE could be achieved. This is fixed in OpenMQ 6.5.2, 6.9.0, and in GlassFish 7.0.26, 7.1.1, and 8.0.2.

In Eclipse Jetty, versions 12.0.0-12.0.31 and 12.1.0-12.0.5, class GzipHandler exposes a vulnerability when a compressed HTTP request, with Content-Encoding: gzip, is processed and the corresponding response is not compressed. This happens because the JDK Inflater is allocated for decompressing the request, but it is not released because the release mechanism is tied to the compressed response. In this case, since the response is not compressed, the release mechanism does not trigger, causing the leak.

OpenMQ exposes a TCP-based management service (imqbrokerd) that by default requires authentication. However, the product ships with a default administrative account (admin/ admin) and does not enforce a mandatory password change on first use. After the first successful login, the server continues to accept the default password indefinitely without warning or enforcement. In real-world deployments, this service is often left enabled without changing the default credentials. As a result, a remote attacker with access to the service port could authenticate as an administrator and gain full control of the protocol’s administrative features.

In the Eclipse Theia Website repository, the GitHub Actions workflow .github/workflows/preview.yml used pull_request_target trigger while checking out and executing untrusted pull request code. This allowed any GitHub user to execute arbitrary code in the repository's CI environment with access to repository secrets and a GITHUB_TOKEN with extensive write permissions (contents:write, packages:write, pages:write, actions:write). An attacker could exfiltrate secrets, publish malicious packages to the eclipse-theia organization, modify the official Theia website, and push malicious code to the repository.

In the Eclipse OMR port library component since release 0.2.0, an API function to return the textual names of all supported processor features was not accounting for the separator inserted between processor features. If the output buffer supplied to this function was incorrectly sized, failing to account for the separator when determining when a write to the buffer was safe could lead to a buffer overflow. This issue is fixed in Eclipse OMR version 0.8.0.

The vulnerability stems from an incorrect error-checking logic in the CreateCounter() function (in threadx/utility/rtos_compatibility_layers/OSEK/tx_osek.c) when handling the return value of osek_get_counter(). Specifically, the current code checks if cntr_id equals 0u to determine failure, but @osek_get_counter() actually returns E_OS_SYS_STACK (defined as 12U) when it fails. This mismatch causes the error branch to never execute even when the counter pool is exhausted. As a result, when the counter pool is depleted, the code proceeds to cast the error code (12U) to a pointer (OSEK_COUNTER *), creating a wild pointer. Subsequent writes to members of this pointer lead to writes to illegal memory addresses (e.g., 0x0000000C), which can trigger immediate HardFaults or silent memory corruption. This vulnerability poses significant risks, including potential denial-of-service attacks (via repeated calls to exhaust the counter pool) and unauthorized memory access.

A denial-of-service vulnerability exists in the NetX IPv6 component functionality of Eclipse ThreadX NetX Duo. A specially crafted network packet of "Packet Too Big" with more than 15 different source address can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

The function _ux_host_class_storage_media_mount() is responsible for mounting partitions on a USB mass storage device. When it encounters an extended partition entry in the partition table, it recursively calls itself to mount the next logical partition. This recursion occurs in _ux_host_class_storage_partition_read(), which parses up to four partition entries. If an extended partition is found (with type UX_HOST_CLASS_STORAGE_PARTITION_EXTENDED or EXTENDED_LBA_MAPPED), the code invokes: _ux_host_class_storage_media_mount(storage, sector + _ux_utility_long_get(...)); There is no limit on the recursion depth or tracking of visited sectors. As a result, a malicious or malformed disk image can include cyclic or excessively deep chains of extended partitions, causing the function to recurse until stack overflow occurs.