Eclipse Jetty

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Separately, for a merged upstream patch : up to $5,000 Google Patch Rewards pays for a patch you get accepted upstream and that stays merged, without reverts, for one month, not for the report. Jetty sits in Tier 2, which caps at $5,000; the $15,000 headline is the Tier 1 column and is not reachable here. You must sign the Eclipse Contributor Agreement before the patch can merge, patches must be no more than twelve months old, submissions are rate-limited to three per person per month, and sanctions and territory exclusions apply. CVE history 6 Last 12 months 34 Lifetime Denial of service 35 % Access control 25 % Info disclosure 20 % Injection 15 % Latest advisories Loading the feed Overview Jetty's real footprint is as an embedded component, and it is enormous: the HTTP layer inside Jenkins, Apache Solr, Apache Spark, Hadoop, HBase, Kafka Connect, Google App Engine's Java runtime, Eclipse IDE tooling, Alfresco and a very long tail of Java products that never mention it in their marketing. The embedding is what makes it dangerous. A Jetty path-traversal ships silently into dozens of downstream products at once, each of them patching on its own schedule, so Jetty defects have repeatedly turned into multi-product advisory cascades. The project pays nothing for a vulnerability report; reports go to [email protected] . sorona.xyz pays you directly on qualified, reproduced findings. In scope Reports go to [email protected] against any currently supported branch, and nothing narrower than the Jetty server itself is carved out. The patch pathway attaches to github.com/jetty/jetty.project The HTTP protocol implementation across every version the server speaks: HTTP/1.1, HTTP/2, the HTTP/3 implementation in Jetty 12, and the request-smuggling and desync surface between them Static content and resource serving as a whole, covering ResourceHandler , DefaultServlet , path resolution, alias checking and the %2e and %2f normalisation logic The security subsystem end to end: the security-constraint matcher, ConstraintSecurityHandler , the authenticators and the login services behind them Session management, including session identifiers, the clustered and persistent session stores, and the servlet context isolation around them WebSocket framing and the HTTP upgrade path, both the Jakarta and the native Jetty APIs Request body handling in full: MultiPartFormInputStream , the file-upload parsers, form decoding and the compression handlers The servlet container and deployment machinery: context handling, the deployer, JNDI and annotation scanning The proxy, rewrite and gzip handler modules the project ships, and the connector and buffer layer underneath all of it Out of scope Applications deployed on Jetty rather than defects in Jetty itself Servlet-specification behaviour that is correct but surprising, which is a specification argument rather than a vulnerability Bugs in the JDK or in Netty, which belong to their own upstreams Jetty 9.x and earlier, which are end-of-life upstream and maintained only under Webtide commercial contract One-line non-exploitable crash fixes, which sit at the bottom of the reward ladder Patches with no signed Eclipse Contributor Agreement behind them, since they cannot merge and the reward depends on the merge Most-valued findings Request smuggling or desync between the HTTP/1.1, HTTP/2 and HTTP/3 paths. Denial of service and access control together are 60% of Jetty's bug history, and a desync is how one request becomes another user's Path traversal or source disclosure through %2e / %2f normalisation and alias checking in DefaultServlet , where Jetty's most consequential path-traversal bugs have lived and the class that has cascaded through Jenkins and Solr before Authorisation bypass where the security-constraint matcher and the dispatcher disagree about what a URI means, so a protected path resolves unprotected Structural hardening of the multipart and file-upload parsers against memory and disk exhaustion, rather than a per-endpoint limit. That surface has been a recurring denial-of-service source Information disclosure across a shared connection: response mixing, buffer reuse or header leakage between concurrent requests, which in an embedded deployment crosses tenants Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. The cash on Google's rail is paid for a merged upstream patch rather than for a vulnerability report. A report on its own earns nothing there You must sign the Eclipse Contributor Agreement before a patch can merge, and the merge is a precondition of payment Patches must be no more than twelve months old when you submit them for reward Three Patch Rewards submissions per person per month is the hard cap Show the bug on a supported branch: Jetty 9.x and earlier are end-of-life upstream and a fix there cannot merge Google cannot pay individuals or entities on sanctions lists, in sanctioned territories, or located in Russia or Belarus Disclosure Coordinated with the Jetty security team at [email protected] ; the project publishes GitHub Security Advisories promptly and credits reporters. That matters here because the downstream products that embed Jetty need their own window to re-ship. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability