CVE-2026-18659 in Jetty
Summary
by MITRE • 10/15/2026
In Eclipse Jetty, across various versions of `jetty-security`, and `jetty-eeN-security`, and `jetty-eeN-servlet`, the Jakarta Spec constraints defined as `http-method-omission` can be bypassed by using substrings of the defined HTTP Methods.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability in question resides within the security configuration mechanisms of Eclipse Jetty, specifically affecting components such as jetty-security and its Enterprise Edition counterparts like jetty-eeN-security and jetty-eeN-servlet. This issue pertains to a critical flaw in how HTTP method constraints are enforced against incoming requests. In web application architectures, particularly those adhering to the Jakarta EE specifications, developers often define security constraints that restrict which HTTP methods (such as GET, POST, PUT, DELETE) are permitted for specific URL patterns or resources. The intended behavior is strict enforcement where only explicitly allowed methods should be processed by the protected resource, while all others must be rejected with an appropriate error code, typically 405 Method Not Allowed.
The core technical flaw involves a logic error in the method matching algorithm used during request processing. When a security constraint specifies that certain HTTP methods are permitted via the http-method-omission configuration or similar inclusion lists, Jetty’s implementation incorrectly validates incoming requests by checking if the requested method is a substring of any allowed method rather than requiring an exact match. For instance, if a developer configures the system to allow only the POST method for a sensitive endpoint, this vulnerability allows attackers to bypass that restriction by sending methods like PROPFIND or MKCOL, which contain the sequence "POST" as a substring. This behavior deviates significantly from standard HTTP specification expectations and common security best practices where exact string comparison is required for method validation.
This flaw has significant operational implications for application security posture. By exploiting this bypass, an attacker can perform actions that were explicitly intended to be restricted by the web application’s deployment descriptor or programmatic configuration. For example, if a REST API endpoint is designed to accept only POST requests for data creation but inadvertently allows PUT operations due to substring matching, an attacker could potentially update or overwrite existing data structures without authorization. This undermines the principle of least privilege and can lead to unauthorized data modification, information disclosure, or even remote code execution depending on how the application handles these unexpected input vectors. The vulnerability effectively neutralizes a primary layer of defense provided by server-side security constraints, forcing developers to rely solely on application-level logic for method validation, which is often less robust if not carefully implemented.
From an industry standards perspective, this issue aligns with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials or Configuration Values when the misconfiguration stems from incorrect implementation of security policies. It also relates to ATT&CK technique T1059 Command and Scripting Interpreter if the bypass leads to further exploitation, although primarily it is an access control failure categorized under privilege escalation within the context of HTTP methods. The flaw highlights a common pitfall in web server implementations where performance optimizations or loose parsing logic inadvertently weaken security boundaries.
To mitigate this vulnerability, organizations running affected versions of Eclipse Jetty must upgrade to patched releases that correct the method matching algorithm to enforce strict equality checks rather than substring matches. Until an upgrade is feasible, administrators can implement additional layers of defense at the reverse proxy level, such as using Nginx or Apache HTTP Server, to filter and validate HTTP methods before they reach the Jetty application server. Additionally, developers should audit their security configurations to ensure that no critical endpoints rely solely on these vulnerable constraints for protection against method-based attacks. It is also advisable to review custom filters or servlets within the application to explicitly reject any HTTP methods not strictly defined in a whitelist approach, thereby adding redundancy to the access control mechanism and ensuring compliance with secure coding standards.