EUVD-2026-101987Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessIdentify Jetty endpoint using host filtering
-
ExploitCraft request with altered hostname case
-
ExecutionBypass case-sensitive whitelist/blacklist check
-
ImpactReach restricted resource or backend
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Case sensitivity handling
|
| Exploitation Conditions | Exploitation requires that the target Jetty deployment has a host whitelist or blacklist configured and relies on it as a security/access-control boundary; the flaw does not apply where no host-based filtering is used. The limiting factor is therefore this specific non-default configuration rather than authentication or user interaction - where the filter is configured, exploitation is remote, unauthenticated (PR:N), and requires only sending a request with a case-altered Host value, with no special privileges or client-side interaction needed. |
| Impact | This is a security-control-bypass flaw (CWE-178, improper handling of case sensitivity) in Eclipse Jetty's host whitelist/blacklist matching, affecting jetty-server and jetty-proxy. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H) indicates a network-reachable, low-complexity, unauthenticated issue with high confidentiality impact, consistent with the 8.8 base score. However, the real-world risk is strongly gated by a configuration prerequisite that the raw score does not capture: the vulnerability only manifests where an operator has actually deployed host-based allow/deny filtering, which is not a universal default. No EPSS probability, CISA KEV listing, or public POC was provided in the input, so there is no evidence of active or at-scale exploitation - exploitation status is 'no public exploit identified at time of analysis.' Net: treat as a genuine but conditional priority - high-impact and trivial to trigger where host filtering is relied upon as a security boundary, but low urgency for deployments that do not use Jetty's host whitelist/blacklist. The PR:N in the vector is accurate (the attacker needs no credentials), but defenders should read it alongside the configuration dependency rather than as blanket default-config exposure. |
| Exploit ScenarioDerived | An attacker targets a Jetty server or proxy that enforces a host-based whitelist or blacklist as an access-control boundary. Because matching is case-sensitive, the attacker submits a request whose Host value differs only in letter case (e.g. an uppercase variant of a blacklisted host, or a case-variant that misses a whitelist entry), causing the filter to fail to match and granting access to otherwise-restricted resources or backends. No public exploit code was identified in the provided data, though the technique is trivial to reproduce manually. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 15, 2026
Eclipse Jetty's host whitelist/blacklist enforcement in the jetty-server and jetty-proxy modules performs case-sensitive comparisons, so a remote, unauthenticated attacker can bypass the filter simply by altering the letter case of the Host value (e.g. 'EXAMPLE.com' instead of 'example.com') and reach hosts the operator intended to block or exclude. The flaw only matters where an operator has explicitly configured a host whitelist or blacklist and treats it as a security boundary; deployments without host-based filtering are unaffected. The vendor has published a security advisory (GHSA-7wfj-j486-mxrf), and no public exploit code has been identified at time of analysis, though the low attack complexity (AC:L, PR:N, UI:N) and high confidentiality impact make the bypass straightforward to attempt wherever the non-default filtering configuration is present.
RemediationAI
Apply the Jetty release that contains the fix as specified in the Eclipse/GitHub advisory GHSA-7wfj-j486-mxrf (https://github.com/jetty/jetty.project/security/advisories/GHSA-7wfj-j486-mxrf), which is the authoritative source for the exact patched version numbers; the Eclipse CVE assignment record (https://gitlab.eclipse.org/security/cve-assignment/-/work_items/212) should be checked alongside it. Where an immediate upgrade is not possible, the practical compensating control is to normalize the Host value before Jetty evaluates the whitelist/blacklist - for example by terminating traffic at an upstream reverse proxy or gateway that lowercases (or rejects any non-lowercase) the Host header prior to forwarding, and by ensuring the Jetty-side rules are expressed in a single canonical case; this preserves the intended filtering but depends on the edge component never forwarding a mixed-case Host, and it will break any client that legitimately sends non-lowercase Host values (rare, since DNS names are case-insensitive). Operators who cannot normalize should treat the host filter as non-authoritative and enforce the restriction through a layer that does not rely on case-sensitive string comparison, accepting the added complexity of a second policy point. Finally, audit whether the affected Jetty instance is reachable in a way that lets an attacker control the Host header; restricting the listener to trusted networks reduces exposure but is not a substitute for the fix.
Affected ProductsAI
The issue affects the Eclipse Jetty jetty-server and jetty-proxy artifacts; the vendor description states that it applies across various versions of both modules rather than a single release line, and the provided CPE data does not enumerate an exact version range, so operators should treat all Jetty releases predating the vendor's fix as potentially affected. The authoritative sources are the vendor security advisory at https://github.com/jetty/jetty.project/security/advisories/GHSA-7wfj-j486-mxrf and the Eclipse CVE assignment work item at https://gitlab.eclipse.org/security/cve-assignment/-/work_items/212, which should be consulted for the precise list of patched versions. Exposure is conditional: only deployments that have explicitly configured a host whitelist or blacklist and rely on it as a security or access-control boundary are meaningfully at risk, since the mismatch has no effect where no host-based filtering is enabled.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is CWE-178 (improper handling of case sensitivity) in the hostname matching logic used by Jetty's host whitelist/blacklist facilities in the jetty-server and jetty-proxy artifacts. DNS hostnames are case-insensitive by definition, and the HTTP Host header is permitted to carry any casing of the same name, so two strings that differ only in letter case denote the same virtual host. Because the affected matching routine compares host strings byte-for-byte without normalizing to a canonical case (or otherwise comparing case-insensitively / against a canonicalized form), a request whose Host value is cased differently from the denylist entry or the allowlist entry will be evaluated as a different host than the operator's rules assume. This turns an intended access-control filter into a bypassable check: a deny entry can be evaded by uppercasing, and an allow-only policy can be short-circuited in the opposite direction. The associated CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N) and the independent CVSS 3.1 assessment (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N) both describe a network-reachable, unauthenticated, no-user-interaction condition in which the primary consequence is unauthorized information exposure (high confidentiality impact) with limited integrity impact, and no availability impact. The 8.8 CVSS 4.0 base score reflects that the confidentiality loss is scored high while integrity and availability consequences remain limited; the bypass does not by itself grant code execution or privilege escalation.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N
Network-reachable and unauthenticated (PR:N) once host filtering is configured; bypassing the filter exposes restricted resources (C:H) with limited integrity effect (I:L) and no availability impact.
Primary rating from Vendor (eclipse).
CVSS VectorVendor: eclipse
DescriptionCVE.org
In Eclipse Jetty, across various versions of jetty-server, and jetty-proxy, the host whitelist/blacklist is case-sensitive, and would allow hosts through that only differ by case.
Technical POC Analysis
CWE-178 (Improper Handling of Case Sensitivity), scored by the advisory additionally as CWE-918 (SSRF).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Eclipse Jetty's jetty-server and jetty-proxy modules contain a high-severity flaw (CVE-2026-18660) where host whitelist/blacklist enforcement is case-sensitive, allowing an unauthenticated remote attacker to bypass the filter by altering the case of the Host header. Organizations that have explicitly configured host-based filtering as a security boundary are affected, potentially exposing internal or restricted hosts to unauthorized access. With no vendor patch available and no public exploit identified at time of analysis, leadership should prioritize assessing exposure and implementing interim mitigations.
No vendor-released patch identified at time of analysis. Interim mitigations: enforce case-insensitive host validation at an upstream proxy/WAF, disable host whitelist/blacklist if not essential, restrict network access to trusted hosts, and monitor for mixed-case Host headers.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
GitHub
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Exploit-DB