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

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.

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.

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.

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.

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.