Skip to content

CVE-2026-19203

WSO2 Products impacted: no

Customer action required: no

REPORTED VULNERABILITY

A client may send specially crafted HTTP/1.1 chunked requests to a Jetty server that cause Jetty and an intermediary proxy to interpret request boundaries differently, potentially resulting in HTTP request smuggling. This happens because Jetty accepts a lone LF character as a terminator in parts of chunked request parsing, such as chunk extensions, chunk data termination, or trailer termination 1.

REPORTED PRODUCTS

  • WSO2 Identity Server : 5.11.0, 6.0.0, 6.1.0, 7.0.0, 7.1.0, 7.2.0

WSO2 JUSTIFICATION

This vulnerability has been addressed in Jetty versions 12.0.38 and above in the 12.0.x series, and 12.1.12 and above in the 12.1.x series 2. The Jetty 9.4.x, 10.0.x and 11.0.x series have reached end of life, and no open-source fixed release is available for them. The vulnerable jetty-http dependency is an embedded dependency of Apache Solr, which supports registry indexing and search in the affected WSO2 Identity Server versions. Depending on the product version, WSO2 Identity Server bundles either the Solr 8.x line, which is built on Jetty 9.4, or the Solr 9.x line, which is built on Jetty 10. Jetty 12 is supported only from Solr 10.x onwards. Migrating to Solr 10.x introduces significant breaking changes in the context of WSO2 Identity Server, and Solr 10.x requires Java 21 or higher, while the listed WSO2 Identity Server versions support Java versions earlier than 21. Due to these constraints, we are publishing this CVE justification with a detailed analysis of the CVE, outlining how associated risks are mitigated in WSO2 products.

CVE-2026-19203 is exploitable only when Jetty's HttpParser parses inbound HTTP/1.1 chunked requests, that is, when Jetty operates as an HTTP server that receives attacker-controlled requests through an intermediary proxy 2. A thorough analysis of all Solr-related code paths in WSO2 Identity Server confirms that this execution path is never reached:

No Jetty HTTP server is present: WSO2 Identity Server serves all inbound HTTP traffic through Apache Tomcat. The packaged Solr component includes only Jetty client-side modules, and no Jetty HTTP server is started anywhere in the product. Therefore, there is no Jetty endpoint that can receive a smuggled request.

Default embedded Solr mode: In the default product configuration, Solr runs in embedded mode through the EmbeddedSolrServer API, which communicates with Solr through direct in-process Java method calls. No HTTP connections are made, and Jetty's HttpParser is never invoked.

Remote Solr mode: When a remote Solr server is configured, WSO2 Identity Server uses SolrJ's HttpSolrClient, which is based on Apache HttpClient and not on Jetty. The product does not use Solr's distributed or SolrCloud request features, which are the only paths that use Solr's internal Jetty client.

In addition, registry indexing is disabled by default in WSO2 Identity Server.

Therefore, although the vulnerable jetty-http dependency is present in the packaged Solr component, the vulnerable HTTP/1.1 chunked request parsing code path is not reachable through any of the Solr usage patterns in the above-mentioned WSO2 products.

CONCLUSION

  • WSO2 Identity Server does not run a Jetty HTTP server, and all inbound HTTP traffic is handled by Apache Tomcat.
  • Solr is used through in-process API calls or an Apache HttpClient-based client, so the vulnerable Jetty request parsing code is never invoked.

Therefore, WSO2 concludes that this vulnerability does not pose a security risk to the aforementioned WSO2 products, and a dependency upgrade will not be carried out solely based on the detection of CVE-2026-19203.

REFERENCES

  1. https://nvd.nist.gov/vuln/detail/CVE-2026-19203 ↩

  2. https://github.com/jetty/jetty.project/security/advisories/GHSA-xc35-c22g-239h ↩↩