Skip to content
The NetSec Tribune
Friday, October 16, 2026Security news, verified and fast163 reports
High-severity Jetty flaw CVE-2026-18661 allows security bypass in versions up to 12.1.11
Vulnerabilities

High-severity Jetty flaw CVE-2026-18661 allows security bypass in versions up to 12.1.11

A high-severity vulnerability in Eclipse Jetty allows security bypasses when web.xml and annotations are used together, affecting versions up to 12.1.11.

Key points

  • The flaw affects Eclipse Jetty versions up to 12.1.11 and older supported branches.
  • It occurs when mixed security annotations and web.xml constraints target the same URL pattern.
  • The National Vulnerability Database rates the issue as high severity with a CVSS score of 8.8.

Eclipse Jetty contains a security flaw that allows attackers to bypass intended access controls in specific configurations. This vulnerability, identified as CVE-2026-18661, impacts environments where developers mix Jakarta specification annotations with traditional web.xml security definitions.

What happened

The National Vulnerability Database describes a logic error in how Eclipse Jetty processes security rules. The flaw exists across various versions of the jetty-annotations and jetty-eeN-annotations modules. It specifically affects systems where the Jakarta Spec authoritative url-pattern rules are applied to mixed configurations. These configurations combine the @ServletSecurity annotation with security-constraint definitions found in the web.xml file.

The bypass occurs under a very specific condition involving URL patterns. If the web.xml file defines more than one url-pattern for a single servlet, the security logic can fail. Furthermore, the security-constraint in the web.xml must apply to only some of those url-pattern definitions. When these conditions are met, the Jetty server does not properly apply the security rules. This leaves the application exposed despite the presence of both annotation-based and XML-based security measures.

Why it matters

This vulnerability affects a wide range of Eclipse Jetty versions currently in use. According to the advisory, Eclipse Jetty versions up to 12.1.11 are impacted. The flaw also extends to older supported branches, including versions up to 12.0.38. Additionally, legacy versions such as 11.0.32, 10.0.32, and 9.4.64 are listed as affected. Organizations running these older branches remain exposed to the same configuration-based bypass.

The severity of this issue is rated as high by the National Vulnerability Database. The CVSS score assigned to CVE-2026-18661 is 8.8. This rating reflects the potential for unauthorized access when the specific mixed configuration is present. Security teams must verify if their deployments use this combination of annotations and web.xml constraints. Environments that do not use this specific mixing of security definitions are likely unaffected by this particular logic error.

Our take on the response

No patch or update has been confirmed in the provided source material. Security teams should assume that affected versions remain vulnerable until an official release is announced. Organizations should audit their Jetty configurations immediately to identify instances of mixed security definitions. If a fix becomes available, it should be prioritized for deployment. Until then, compensating controls such as network segmentation may reduce the risk of exploitation.

What defenders should look for

Teams should review web server logs for requests to endpoints that should be restricted but are returning successful responses. Look for access attempts from unauthorized IP addresses or users to sensitive servlet paths. Monitor for unusual traffic patterns that might indicate an attacker probing for configuration weaknesses. Check whether security constraints are being enforced consistently across all defined URL patterns. Investigate any discrepancies between expected and actual access control behavior. Contain potential compromises by isolating affected servers from critical network segments.

Background: Compensating controls

Compensating controls are alternative measures used when primary security requirements cannot be met due to technical or operational constraints. They must provide equivalent protection against specific threats. These controls require rigorous documentation and regular review to ensure they remain effective as systems and threats evolve.

Read the full guide: Compensating Controls: When Standard Fixes Fail

What to do and how to stay safe: Eclipse Jetty

  • Audit all Eclipse Jetty instances to identify if they use mixed @ServletSecurity annotations and web.xml security-constraints on the same URL patterns.
  • Review web.xml files to check if any servlet has more than one url-pattern defined with partial security-constraint application.
  • Monitor server logs for unauthorized access to endpoints that should be protected by the mixed security configuration.
  • Prepare to apply updates once the vendor releases a patch for CVE-2026-18661, and test the fix in a non-production environment first.

Step-by-step guide: Vulnerability Management Myths That Waste Your Time and Budget

General security guidance from the NetSec Tribune newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of Eclipse Jetty are affected by CVE-2026-18661?

Versions up to 12.1.11, 12.0.38, 11.0.32, 10.0.32, and 9.4.64 are affected by this vulnerability.

What is the severity rating of this vulnerability?

The National Vulnerability Database rates CVE-2026-18661 as high severity with a CVSS score of 8.8.

Is there a fix available for this issue?

No fix has been confirmed in the provided source material. Users should wait for an official vendor update.

Sources

  1. CVE Program
Eclipse JettyCVE-2026-18661Jakarta Specweb.xmlsecurity bypass

Related stories

GitPython Argument Injection Flaw Lets Attackers Read Files via Branch Names

A high-severity flaw in GitPython before 3.2.0 allows attackers to leak arbitrary files by manipulating branch names during repository checkout operations.