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.

Docling Core defines core data types and transformations for the document processing application Docling. In versions 1.5.0 and above, prior to 2.74.1, docling-core did not sufficiently restrict remote request destinations and could resolve a server-provided Content-Disposition to a local path in an unsafe manner. In applications that accept untrusted URLs, this could allow SSRF attacks targeting local files outside the user-defined cache directory. This issue has been fixed in version 2.74.1.

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".

Cline is an autonomous coding agent as an SDK, IDE extension, or CLI assistant. Prior to 3.0.30, the Cline Hub dashboard server launched by the cline dashboard command accepts WebSocket connections on the /browser endpoint without validating the Origin header, and when ROOM_SECRET is unset for local 127.0.0.1 binds, isAuthorizedBrowserRequest() allows attacker-controlled websites to send desktopCommand frames that read workspace state, mutate MCP and provider settings, and trigger command execution when a provider or model is configured. This issue is fixed in version 3.0.30.

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.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. Prior to 2.94.0, the HTML backend has unsafe URI and path handling. This vulnerability is fixed in 2.94.0.

Docling simplifies document processing by parsing diverse formats and providing integrations with the generative AI ecosystem. FIn versions >= 2.82.0, < 2.91.0, if the HTML backend was explicitly configured for rendering (rendering option by default deactivated), then the Playwright-based rendering feature could allow JavaScript execution and unrestricted network access when processing untrusted HTML documents. An attacker could craft malicious HTML that executes arbitrary JavaScript in the rendering context or makes unauthorized network requests to internal services, potentially leading to SSRF attacks, data exfiltration, or remote code execution in the rendering environment. This vulnerability is fixed in 2.91.0.

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.

phpseclib is a PHP secure communications library. From 0.1.1 until 1.0.30, 2.0.55, and 3.0.54, when an application validates an untrusted X.509 certificate with phpseclib, X509::validateSignature() reads a URL out of that certificate's Authority Information Access (AIA) extension and connects to it. Attacker who supplies certificate fully controls host, port, and path of that connection. URL fetching is enabled by default, and no destination is blocked. An unauthenticated attacker can therefore make a validating server open connections to internal hosts and ports it should never reach, for example loopback 127.0.0.1, cloud metadata address 169.254.169.254, and internal-only services. This is a server-side request forgery (SSRF) caused by an insecure default. This vulnerability is fixed in 1.0.30, 2.0.55, and 3.0.54.

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).