Document Netty CVE's impact on Solr

content/solr/vex/2026-07-18-cve-2026-41417.md

@@ -0,0 +1,50 @@
+---
+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.
+
+The `netty-codec-http` jar this CVE concerns was first shipped by Solr in **9.2.0** (SOLR-16532),
+when the optional `opentelemetry` module started pulling it in transitively via `grpc-netty`. That
+doesn't mean Solr had no HTTP codec classes before then, though: earlier Solr releases (7.x through
+8.2.x) already shipped this same `DefaultHttpRequest`/`DefaultFullHttpRequest` code, bundled in the
+older `netty-all` uber-jar — just not as this specific modular jar. Every release since 9.2.0 has
+shipped a vulnerable `netty-codec-http`: 4.1.114.Final (before 4.1.133.Final) through the
+9.2.0–9.9.0 line, and 4.2.6.Final (within the vulnerable 4.2.0.Alpha1–4.2.12.Final range,
+`netty-codec-http-4.2.6.Final.jar`) in the current 9.10.x and 10.0.x lines. So dependency scanners
+flag this CVE across the whole 9.2.0–10.x range. Solr is **not affected**:
+
+* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java
+  sources. Netty is a transitive dependency, not something Solr calls directly.
+* **The only production path is an outbound gRPC client, not an HTTP server.** The optional
+  `opentelemetry` module (`solr/modules/opentelemetry`) pulls in `io.grpc:grpc-netty` to export
+  trace spans over OTLP/gRPC to an operator-configured collector endpoint. That is a client
+  connection Solr *initiates* to a trusted, configured address — Netty never parses inbound,
+  attacker-controlled HTTP requests in this path, and nothing in that flow calls `setUri()` on a
+  request built from untrusted input.
+* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs are handled by
+  Jetty's servlet stack (`SolrDispatchFilter`); Netty is never in that request path at all.
+* **The other place `netty-codec-http` appears is test-only.** The `jwt-auth` module depends on it
+  as `testRuntimeOnly` (required by the `mock-oauth2-server` test dependency), so it is not part of
+  any shipped Solr artifact.
+
+Since the vulnerable `setUri()` bypass is never exercised — Solr neither constructs nor mutates
+Netty HTTP requests from attacker-controlled data — the vulnerable code is present on the classpath
+but not in any reachable execution path.
+
+No released Solr version ships the fix yet. On Solr's `main` development branch, Netty was bumped
+4.2.6.Final → 4.2.12.Final (still within the vulnerable range) → 4.2.15.Final in June 2026, which is
+fixed — and will be released in Solr versions 9.11.0 and 10.1.

content/solr/vex/2026-07-18-cve-2026-42577.md

@@ -0,0 +1,69 @@
+---
+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: requires_configuration
+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.
+
+`netty-transport-native-epoll` — the modular jar this CVE concerns — has been part of Solr's
+dependency graph since **8.3.0** (SOLR-13665), as 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. Older Solr releases (7.x through 8.2.x)
+already bundled Netty's Epoll transport code too, in the older `netty-all` uber-jar, but at ancient
+4.0.x Netty versions — well below this CVE's affected range regardless. From 8.3.0 through 9.9.0,
+the modular jar stayed on Netty 4.1.x, still outside this CVE's affected range. 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.
+
+CVE-2026-42577 is **not** considered exploitable in typical deployments of Apache Solr. Successful
+exploitation requires a specific, non-default configuration together with a hostile or compromised
+peer on that connection:
+
+* ZooKeeper client TLS must be explicitly enabled, following **ZooKeeper's own** documented
+  instructions — setting `zookeeper.client.secure=true` and
+  `zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty` (typically as JVM system
+  properties in `solr.in.sh`/`SOLR_OPTS`), plus the corresponding `zookeeper.ssl.*` keystore/truststore
+  properties. ZooKeeper's own documentation states this plainly: "SSL feature will be enabled when
+  user plugs-in zookeeper.serverCnxnFactory, zookeeper.clientCnxnSocket as Netty" — the default
+  plain-NIO socket (`ClientCnxnSocketNIO`) has no TLS support at all. This is not something Solr
+  ships, sets, or documents in its own reference guide; it requires an operator to configure it
+  directly via ZooKeeper's own mechanism, independent of Solr.
+* That alone is enough to make the Epoll transport reachable: ZooKeeper's Netty client
+  (`org.apache.zookeeper.common.NettyUtils`) explicitly prefers the Epoll event loop over plain NIO
+  whenever the native library is available, which it is on the common case of Linux.
+* An attacker still needs to be able to trigger the RST-after-half-close condition against that
+  specific connection — meaning a compromised ZooKeeper ensemble member, or a network position
+  able to manipulate that TCP connection. ZooKeeper ensemble members are ordinarily trusted,
+  operator-controlled infrastructure, which narrows this further even when the configuration
+  precondition is met.
+
+Solr's default configuration never enables ZooKeeper client TLS, so ZooKeeper's client socket
+defaults to the plain-NIO `ClientCnxnSocketNIO`, and the bundled `netty-transport-native-epoll` jar
+sits completely unused on the classpath — ZooKeeper connections go through the default NIO socket,
+never through Netty's Epoll channel implementation, unless an operator has taken the additional
+step above. The other place Netty appears in Solr — the optional `opentelemetry` module's
+`grpc-netty` OTLP exporter — never depends on `netty-transport-native-epoll` at all, so it offers no
+alternate path to this code. No Solr code instantiates an Epoll channel directly either: there are
+no `io.netty` imports anywhere in Solr's own Java sources.
+
+Only operators who have both enabled ZooKeeper client TLS and are exposed to a hostile or
+compromised ZooKeeper peer are affected. Operators who do enable ZooKeeper client TLS should treat
+their ZooKeeper ensemble as they would any other TLS endpoint pending an upgrade, or restrict
+network access to it in the interim.
+
+No released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the
+`branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but hasn't reached a
+released line yet.

content/solr/vex/2026-07-18-cve-2026-42578.md

@@ -0,0 +1,47 @@
+---
+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 **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 this jar. It arrives as a transitive runtime dependency of `grpc-netty`,
+used only by the optional `opentelemetry` module's OTLP gRPC exporter. Solr is **not affected**:
+
+* **Solr never configures an HTTP/SOCKS proxy for its OTLP exporter.** `HttpProxyHandler` is only
+  instantiated when grpc-netty's channel is told to tunnel through a proxy — via gRPC's default
+  `ProxyDetector`, which honors the JVM's standard `http.proxyHost`/`https.proxyHost` system
+  properties. Solr sets none of this itself; a proxy tunnel (and therefore `HttpProxyHandler`) is
+  only in play if an operator has separately configured JVM-wide HTTP proxy settings, which isn't
+  Solr's default posture.
+* **Even with a proxy configured, nothing attacker-controlled reaches `outboundHeaders`.** The flaw
+  only bites through caller-supplied header values passed into `HttpProxyHandler`. Any values Solr's
+  (or grpc's) proxy path would ever supply — the collector address, proxy credentials sourced from
+  JVM properties — are operator-configured, never derived from a client request to Solr's search
+  APIs.
+* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java
+  sources, so nothing in Solr itself constructs or feeds data into an `HttpProxyHandler`.
+
+Exploiting this requires both a non-default proxy configuration and attacker-controlled header
+data that Solr's OTLP export path never supplies, so the vulnerable code is present on the
+classpath but not reachable in any real Solr deployment.
+
+No released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the
+`branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but hasn't reached a
+released line yet.

content/solr/vex/2026-07-18-cve-2026-42580.md

@@ -0,0 +1,51 @@
+---
+cve: CVE-2026-42580
+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 chunk-size integer overflow"
+---
+CVE-2026-42580 (CVSS 6.5, CWE-190 / CWE-444) is a request-smuggling issue in `netty-codec-http`'s
+`HttpObjectDecoder`: when parsing a chunked HTTP/1.1 message, the hex chunk-size field is parsed
+into a 32-bit int without an overflow check, so an oversized chunk-size value silently wraps
+around to a small (or negative) number instead of being rejected. A crafted chunk whose declared
+size doesn't match the bytes actually sent can desynchronize how Netty and a front-end HTTP
+intermediary frame the request, the same general smuggling pattern as other chunk/header parsing
+bugs that have affected HTTP implementations. 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-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x —
+`netty-codec-http-4.2.6.Final.jar` — from 9.10.0/10.0.0 onward), arriving as a transitive runtime
+dependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.
+`HttpObjectDecoder` itself isn't new at that point — earlier Solr releases (7.x through 8.2.x)
+already shipped this same class, bundled in the older `netty-all` uber-jar. This is a
+**decoder**-side bug — it only bites when Netty is parsing an inbound chunked HTTP/1.1 message,
+which makes Solr's exposure narrow to begin with, since Solr's own HTTP server never uses this
+decoder at all (see below). Solr is **not affected**:
+
+* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a
+  Netty decoder at all; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every
+  attacker-facing request.
+* **The OTLP gRPC path never parses chunked HTTP/1.1.** gRPC traffic is HTTP/2 framed, not
+  HTTP/1.1 chunked transfer-encoding, so `HttpObjectDecoder`'s chunk-size parsing is never invoked
+  by the actual trace-export traffic.
+* **The only place this decoder could run is an optional proxy CONNECT response**, and only if an
+  operator has separately configured an HTTP proxy for the OTLP exporter — itself non-default, since
+  Solr never sets any JVM-wide HTTP proxy properties itself — and only if that operator-configured,
+  trusted proxy sent back a chunked response, which isn't how CONNECT responses are normally
+  constructed.
+* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java
+  sources.
+
+Since there is no attacker-reachable path where Solr (or its dependencies) ever decodes an
+attacker-supplied chunked HTTP/1.1 message through this Netty codec, the vulnerable code is present
+on the classpath but not reachable in any real Solr deployment.
+
+No released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the
+`branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but hasn't reached a
+released line yet.

content/solr/vex/2026-07-18-cve-2026-42581.md

@@ -0,0 +1,45 @@
+---
+cve: CVE-2026-42581
+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 conflicting Content-Length/Transfer-Encoding"
+---
+CVE-2026-42581 (CWE-444) is a request-smuggling issue in `netty-codec-http`'s
+`HttpObjectDecoder`: for an HTTP/1.0 request that carries both `Transfer-Encoding: chunked` and a
+`Content-Length` header, the decoder fails to strip the conflicting `Content-Length`, so
+downstream proxies or handlers that pick a different header to trust can disagree with Netty about
+where the request body ends. 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-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x —
+`netty-codec-http-4.2.6.Final.jar` — from 9.10.0/10.0.0 onward), arriving as a transitive runtime
+dependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.
+`HttpObjectDecoder` itself isn't new at that point — earlier Solr releases (7.x through 8.2.x)
+already shipped this same class, bundled in the older `netty-all` uber-jar. This is a
+**decoder**-side bug — it only bites when Netty parses an inbound HTTP/1.0/1.1 request. Solr is
+**not affected**:
+
+* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a
+  Netty decoder; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every attacker-facing
+  request.
+* **The OTLP gRPC path never parses HTTP/1.x requests.** gRPC traffic is HTTP/2 framed, so
+  `HttpObjectDecoder` (an HTTP/1.x-only class) is never invoked by the actual trace-export traffic,
+  and Solr's outbound gRPC client never *receives* an HTTP/1.x request to decode in the first place
+  — it only ever decodes a proxy's CONNECT *response*, if a proxy is configured at all (an
+  optional, non-default setup for the OTLP exporter).
+* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java
+  sources.
+
+Since there is no attacker-reachable path where Solr (or its dependencies) ever decodes an
+attacker-supplied HTTP/1.0 or HTTP/1.1 request through this Netty codec, the vulnerable code is
+present on the classpath but not reachable in any real Solr deployment.
+
+No released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the
+`branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but hasn't reached a
+released line yet.

content/solr/vex/2026-07-18-cve-2026-42583.md

@@ -0,0 +1,43 @@
+---
+cve: CVE-2026-42583
+category:
+  - solr/vex
+versions: "9.10.x,10.0.x"
+jars:
+  - netty-codec-compression-4.2.6.Final.jar
+analysis:
+  state: not_affected
+  justification: code_not_reachable
+title: "Netty: Lz4FrameDecoder unbounded allocation before decompression"
+---
+CVE-2026-42583 (CVSS 7.5, CWE-400 / CWE-770) is a resource-exhaustion issue in
+`netty-codec-compression`'s `Lz4FrameDecoder`: it allocates a `ByteBuf` sized to the frame's
+claimed `decompressedLength` (up to 32 MB per block) *before* running LZ4 decompression, so a
+crafted frame that lies about its decompressed size can force large allocations regardless of how
+much data was actually sent — a decompression-bomb-style DoS. 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.
+
+`netty-codec-compression` — the specific jar this entry tracks — first appears in Solr's dependency
+graph in **9.10.0/10.0.0** (`netty-codec-compression-4.2.6.Final.jar`); it's a byproduct of Netty's
+own 4.2 module split, which broke compression codecs out of the general-purpose `netty-codec`
+artifact into their own jar. `Lz4FrameDecoder` itself is not new at that point, though: it already
+existed in `netty-codec` going back to Solr 8.3.0 (SOLR-13665), when Solr first shipped modular
+Netty jars at all. The same reasoning below has applied for that whole span — Solr has never wired
+this decoder into anything, regardless of which jar happens to contain it. Solr is **not
+affected**:
+
+* **Nothing in Solr's dependency graph ever instantiates `Lz4FrameDecoder`.** It arrives purely as
+  a transitive dependency of Netty's own HTTP/2 and proxy-handler modules (used by `grpc-netty`,
+  the optional `opentelemetry` module's OTLP exporter), not because anything negotiates or uses LZ4
+  compression. gRPC's own message-compression layer uses `gzip`/`identity`, never LZ4, so this
+  decoder is never added to any pipeline Solr builds.
+* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java
+  sources, and no Solr build file references LZ4, Snappy, Brotli, or Zstd Netty codec classes.
+
+Since the vulnerable decoder is never wired into any pipeline that processes attacker-supplied
+data, the vulnerable code is present on the classpath (where it exists at all) but not reachable in
+any real Solr deployment.
+
+No released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the
+`branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but hasn't reached a
+released line yet.