Eclipse Jetty CVE-2026-19863

The deployment must be configured to use Jetty's EthereumAuthenticator, and the targeted protected resource's path must contain the configured login path string as a later path segment, which triggers the unanchored substring match that replaces the authorization requirement with ALLOWED. Limiting factors that reduce real-world exposure: EthereumAuthenticator is a non-default, rarely enabled authentication mechanism, so most Jetty deployments are unaffected; explicitly FORBIDDEN routes are not bypassable via this flaw; and exploitation is confined to resources whose paths happen to embed the login path. No user interaction or authentication is required once the authenticator is in use.

All signals point to a genuinely high-priority flaw in a very widely deployed product, tempered by a narrow configuration dependency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N, 9.3 Critical) describes remote, unauthenticated, low-complexity access with high confidentiality and integrity impact and no scope change to other systems - consistent with the CWE-288 authentication-bypass-by-alternate-path mechanism in the description (unanchored substring match on the login path). However, this is NOT a flaw in Jetty's default configuration: it only affects deployments that use EthereumAuthenticator, a niche, rarely enabled authentication mechanism, so the effective real-world attack surface is far smaller than the 9.3 score alone implies. There is no EPSS score, no CISA KEV listing, and no public exploit code referenced in the provided data, so exploitation is currently theoretical - no public exploit identified at time of analysis. No SSVC decision data was provided. The one point to verify: although the CVSS vector sets VI:H (integrity), the description and the 'Information Disclosure' tag frame the impact primarily as unauthorized read access to protected resources; whether an attacker gains write/modify capability depends on what the exposed resource permits, so confirm the realistic integrity impact against the specific protected endpoints.

A remote, unauthenticated attacker targets a Jetty application that is configured to use EthereumAuthenticator for access control. The attacker requests a protected resource using a URL that embeds the configured login path as a later path segment (e.g. /app/<login-path>/resource); because the authenticator does an unanchored substring match, the request is misclassified as the login page and its authentication/role requirement is replaced with ALLOWED, granting access. No public exploit code is referenced in the provided data.