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

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

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 Eclipse Jetty, a first HTTP/1.1 request with trailers causes the server to retain the trailers in subsequent requests performed over the same connection. Subsequent request that do not have trailers report the trailers of the first request. Subsequent request that do have trailers report the union of trailers of the first request and the current request.

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.