dsmiley commented on code in PR #206: URL: https://github.com/apache/solr-site/pull/206#discussion_r3608633988
########## content/solr/vex/2026-07-18-cve-2026-41417.md: ########## @@ -0,0 +1,48 @@ +--- +cve: CVE-2026-41417 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-codec-http-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: HTTP request smuggling via setUri() CRLF-validation bypass" +--- +CVE-2026-41417 (CVSS 5.3) is a request-smuggling issue (CWE-93 / CWE-444) in Netty's HTTP/1.1 +codec. `DefaultHttpRequest` and `DefaultFullHttpRequest` reject CRLF and whitespace characters in +their constructors, but the `setUri()` method that lets a request's URI be rewritten after +construction has no equivalent validation, so an attacker who controls a value later passed to +`setUri()` can inject CRLF sequences and smuggle a second request. It affects Netty versions before +4.1.133.Final and 4.2.0.Alpha1–4.2.12.Final; it is fixed in 4.1.133.Final and 4.2.13.Final. + +Solr first started shipping Netty as a transitive dependency in **9.2.0** (SOLR-16532), when the +optional `opentelemetry` module was added; Solr versions before 9.2.0 don't include that module and +never carry Netty at all. Every release since 9.2.0 has pinned a vulnerable Netty: 4.1.114.Final Review Comment: > ever carry Netty at all Jeesh that is so false. ########## content/solr/vex/2026-07-18-cve-2026-42580.md: ########## Review Comment: When a dependency comes transitively via OTEL (a major subsystem, popular project), I hope one day we can instead have _transitive VEX statements_ instead of having to explain why the dependencies of our dependencies of our dependencies are not vulnerable. ########## content/solr/vex/2026-07-18-cve-2026-41417.md: ########## @@ -0,0 +1,48 @@ +--- +cve: CVE-2026-41417 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-codec-http-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: HTTP request smuggling via setUri() CRLF-validation bypass" +--- +CVE-2026-41417 (CVSS 5.3) is a request-smuggling issue (CWE-93 / CWE-444) in Netty's HTTP/1.1 +codec. `DefaultHttpRequest` and `DefaultFullHttpRequest` reject CRLF and whitespace characters in +their constructors, but the `setUri()` method that lets a request's URI be rewritten after +construction has no equivalent validation, so an attacker who controls a value later passed to +`setUri()` can inject CRLF sequences and smuggle a second request. It affects Netty versions before +4.1.133.Final and 4.2.0.Alpha1–4.2.12.Final; it is fixed in 4.1.133.Final and 4.2.13.Final. + +Solr first started shipping Netty as a transitive dependency in **9.2.0** (SOLR-16532), when the Review Comment: The narrative here speaks of Netty in an unqualified way, thus I'm thinking of any and all of Netty. Solr has shipped Netty (in whole or part) for much longer prior to 9.2. ########## content/solr/vex/2026-07-18-cve-2026-42577.md: ########## @@ -0,0 +1,48 @@ +--- +cve: CVE-2026-42577 +category: + - solr/vex +versions: "9.10.x,10.0.x" +jars: + - netty-transport-native-epoll-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: Epoll transport CPU busy-loop DoS via unclosed half-closed connections" +--- +CVE-2026-42577 (CVSS 7.5, CWE-772) is a resource-leak / denial-of-service issue in Netty's Epoll +native transport: a TCP connection that receives a RST after being half-closed isn't properly +closed, so stale channels accumulate and can eventually pin the owning event-loop thread at 100% +CPU. It affects Netty 4.2.0.Final up to (but not including) 4.2.13.Final — the Epoll transport code +in question was introduced by the 4.2 rewrite, so the older 4.1.x line is unaffected regardless of +patch version. It is fixed in 4.2.13.Final. + +Solr shipped Netty 4.1.x from 9.2.0 through 9.9.0, entirely outside this CVE's affected range, so +those releases aren't relevant here. Starting with 9.10.0 (and 10.0.0), Solr moved to Netty +4.2.6.Final, which does fall in the vulnerable range, and dependency scanners flag +`netty-transport-native-epoll-4.2.6.Final.jar` (classifier `linux-x86_64`) on the classpath. +Notably, this jar doesn't come from Solr's OTLP/gRPC export path at all — `grpc-netty`'s own POM +only pulls in `netty-transport-native-unix-common`, never the Epoll transport. It's a transitive dependency of **Apache ZooKeeper**'s client library +(`org.apache.zookeeper:zookeeper`), which optionally supports a Netty-based connection socket for +both its client and server roles. Solr is **not affected**: Review Comment: correct... Note: if someone chooses to use a SSL/TLS based ZooKeeper connections and follows ZooKeeper instructions to do so, then Netty will be used. ########## content/solr/vex/2026-07-18-cve-2026-42578.md: ########## @@ -0,0 +1,48 @@ +--- +cve: CVE-2026-42578 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-handler-proxy-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: HTTP header injection via HttpProxyHandler CONNECT request" +--- +CVE-2026-42578 (CVSS 7.5, CWE-93 / CWE-113) is a header-injection issue in +`io.netty:netty-handler-proxy`'s `HttpProxyHandler`, used when a Netty client tunnels a connection +through an HTTP proxy via CONNECT. Its `newInitialMessage()` method builds the CONNECT request's +headers with validation explicitly disabled (`DefaultHttpHeadersFactory...withValidation(false)`), +then appends the caller-supplied `outboundHeaders` without any CRLF check — so an attacker who +influences those header values can inject arbitrary headers, or split, the CONNECT request sent to +the proxy. It affects Netty before 4.1.133.Final and 4.2.0.Alpha1–4.2.12.Final; fixed in +4.1.133.Final and 4.2.13.Final. + +Solr has shipped a vulnerable `netty-handler-proxy` since Netty first became a transitive +dependency in 9.2.0 (4.1.x through the 9.2.0–9.9.0 line, 4.2.x — `netty-handler-proxy-4.2.6.Final.jar` +— from 9.10.0/10.0.0 onward); Solr versions before 9.2.0 don't ship Netty at all. This artifact Review Comment: > don't ship Netty at all Again, a totally false statement. I won't repeat this claim but I bet it repeats. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
