CVE-2026-18661 in Jetty
Summary
by MITRE • 10/15/2026
In Eclipse Jetty, across various versions of `jetty-annotations`, and `jetty-eeN-annotations`, the Jakarta Spec authoritative url-pattern rules for mixed `@ServletSecurity` annotation, and `web.xml` defined `security-constraint` on the same `url-pattern` were not being applied if the `web.xml` had more than 1 `url-pattern` for a servlet, and had a `security-constraint` applying to only some of those `url-pattern` definitions.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability in Eclipse Jetty represents a critical deviation from the Jakarta Servlet specification regarding security constraint enforcement when multiple URL patterns are associated with a single servlet definition. In standard web application architecture, developers often map several distinct URI paths to one underlying servlet class for efficiency or logical grouping. The Jakarta EE specifications mandate that if any part of this mapping is secured via annotations such as @ServletSecurity, those constraints must be rigorously applied regardless of how the URL patterns are defined in the deployment descriptor, commonly known as web.xml. However, a flaw existed in Jetty's security filter chain logic where the presence of multiple url-pattern entries within a single servlet-mapping element caused the container to ignore or incorrectly process mixed security definitions derived from both programmatic annotations and declarative XML configurations.
Specifically, the technical failure occurred when a developer defined a servlet mapping with more than one url-pattern but applied a security-constraint in web.xml that targeted only a subset of those patterns while simultaneously using @ServletSecurity on the same servlet class for other paths or overlapping scopes. In this scenario, Jetty failed to correctly resolve which constraints applied to which specific URL pattern during request processing. Instead of applying granular access control based on the intersection of annotation-based and XML-based rules, the container either bypassed security checks entirely for certain patterns or applied incorrect default permissions. This behavior violates the principle of least privilege by potentially exposing sensitive endpoints that were intended to be protected under strict authentication or authorization policies defined in the application's configuration files.
The operational impact of this vulnerability is severe for applications relying on mixed security configurations, which are common in legacy enterprise systems transitioning from XML-based security models to annotation-driven approaches. Attackers who can identify these specific servlet mappings may exploit the misconfiguration to access restricted resources without valid credentials or with elevated privileges. Since the flaw depends on a specific structural arrangement of web.xml entries and annotations, it is not universally exploitable across all Jetty deployments but poses a significant risk to applications that utilize complex security constraints involving multiple URL patterns per servlet. The inconsistency in enforcement undermines the integrity of the application's access control layer, potentially leading to unauthorized data exposure or remote code execution if combined with other vulnerabilities such as insecure direct object references.
Mitigation strategies require both immediate remediation and long-term architectural adjustments. For organizations using affected versions of jetty-annotations and jetty-eeN-annotations, upgrading to the latest patched release is essential to restore compliance with Jakarta Spec authoritative url-pattern rules. Developers should also audit their web.xml configurations to ensure that security constraints are explicitly defined for all relevant URL patterns rather than relying on implicit inheritance or incomplete mappings. Where possible, consolidating servlet mappings into single-url-pattern definitions can simplify the security model and reduce the likelihood of configuration errors. Furthermore, implementing comprehensive integration testing that validates access control behavior across diverse URI paths is recommended to detect any residual misconfigurations before deployment in production environments. This issue aligns with CWE-284 Improper Access Control as it involves a failure to enforce proper restrictions on authenticated users regarding specific resources and functions within the application. From an ATT&CK perspective, this vulnerability facilitates lateral movement or privilege escalation by allowing attackers to bypass intended security boundaries through configuration exploitation rather than code-level exploits.