From 870c9e3d4b099e0971f412416a6671584608c87d Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sat, 18 Jul 2026 09:56:38 -0300 Subject: [PATCH 1/3] Document Netty CVE's impact on Solr --- content/solr/vex/2026-07-18-cve-2026-41417.md | 48 +++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42577.md | 48 +++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42578.md | 48 +++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42580.md | 49 ++++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42581.md | 43 ++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42583.md | 41 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42584.md | 43 ++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42585.md | 39 ++++++++++++++ content/solr/vex/2026-07-18-cve-2026-42587.md | 41 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-44249.md | 41 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-45416.md | 42 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-45536.md | 45 ++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-47244.md | 43 ++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-47691.md | 25 +++++++++ content/solr/vex/2026-07-18-cve-2026-48043.md | 40 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-50010.md | 51 +++++++++++++++++++ content/solr/vex/2026-07-18-cve-2026-50020.md | 41 +++++++++++++++ content/solr/vex/2026-07-18-cve-2026-50560.md | 40 +++++++++++++++ 18 files changed, 768 insertions(+) create mode 100644 content/solr/vex/2026-07-18-cve-2026-41417.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42577.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42578.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42580.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42581.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42583.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42584.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42585.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-42587.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-44249.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-45416.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-45536.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-47244.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-47691.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-48043.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-50010.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-50020.md create mode 100644 content/solr/vex/2026-07-18-cve-2026-50560.md diff --git a/content/solr/vex/2026-07-18-cve-2026-41417.md b/content/solr/vex/2026-07-18-cve-2026-41417.md new file mode 100644 index 000000000..589e4963a --- /dev/null +++ b/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 +(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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42577.md b/content/solr/vex/2026-07-18-cve-2026-42577.md new file mode 100644 index 000000000..dccd6a8e0 --- /dev/null +++ b/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**: + +* **Solr never selects ZooKeeper's Netty transport.** ZooKeeper picks its client socket + implementation via the `zookeeper.clientCnxnSocket` system property, defaulting to the + plain-NIO `ClientCnxnSocketNIO`. Solr never sets that property (or configures + `NettyServerCnxnFactory`) anywhere in its own source, scripts, or documentation, so the bundled + `netty-transport-native-epoll` jar sits unused on the classpath — ZooKeeper connections always go + through the default NIO socket, never through Netty's Epoll channel implementation. +* **The gRPC/OpenTelemetry path doesn't touch it either.** 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. +* **No Solr code instantiates an Epoll channel.** There are no `io.netty` imports anywhere in + Solr's own Java sources, and nothing in Solr's dependency graph exercises the Epoll transport + classes at runtime. + +Since the vulnerable Epoll channel-close logic is never invoked — it's present on the classpath +only as an unreferenced, unused transitive jar — Solr is not affected regardless of whether the +pinned Netty falls in the vulnerable range. + +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42578.md b/content/solr/vex/2026-07-18-cve-2026-42578.md new file mode 100644 index 000000000..f54aa615e --- /dev/null +++ b/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 +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42580.md b/content/solr/vex/2026-07-18-cve-2026-42580.md new file mode 100644 index 000000000..6ce34f10a --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42580.md @@ -0,0 +1,49 @@ +--- +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. +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42581.md b/content/solr/vex/2026-07-18-cve-2026-42581.md new file mode 100644 index 000000000..0519ab388 --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42581.md @@ -0,0 +1,43 @@ +--- +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. +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42583.md b/content/solr/vex/2026-07-18-cve-2026-42583.md new file mode 100644 index 000000000..49d1e992f --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42583.md @@ -0,0 +1,41 @@ +--- +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` is not a dependency Solr has carried since 9.2.0, when Netty first +became a transitive dependency — it's a byproduct of Netty's own 4.2 module split (compression +codecs, which used to live in `netty-codec`, were broken out into their own artifact) and so first +appears starting with Solr 9.10.0/10.0.0, where Solr moved to Netty 4.2.6.Final (in range for this +CVE). Solr 9.2.0–9.9.0, still on Netty 4.1.x, never carry this artifact at all. 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42584.md b/content/solr/vex/2026-07-18-cve-2026-42584.md new file mode 100644 index 000000000..7b33039cd --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42584.md @@ -0,0 +1,43 @@ +--- +cve: CVE-2026-42584 +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: HttpClientCodec request/response desync via 1xx responses" +--- +CVE-2026-42584 (CVSS up to 9.1, CWE-444) is a request-smuggling issue in `netty-codec-http`'s +`HttpClientCodec`: it pairs each inbound response with the next outbound request by calling +`queue.poll()` exactly once per response, including for 1xx informational responses. When a server +sends a 1xx response ahead of the real final response, the codec's request/response pairing slips, +and a later response's body gets parsed from the wrong offset. 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. + +`HttpClientCodec` is the HTTP/1.1 client-side codec Solr's dependency graph only ever uses inside +Netty's `HttpProxyHandler`, to send an HTTP CONNECT request and parse the proxy's response when +tunneling `grpc-netty`'s OTLP export traffic through an HTTP proxy — itself a non-default +configuration, since Solr never sets any JVM-wide HTTP proxy properties itself. Solr is **not +affected**: + +* **The bug requires a pipelined sequence of requests/responses (including 1xx) to desync.** A + CONNECT tunnel is a single request/response exchange — once established, the connection carries + opaque HTTP/2 gRPC bytes, not further HTTP/1.1 messages for `HttpClientCodec` to mis-pair. There's + no second request in flight for the queue to get out of sync with. +* **The proxy path itself is non-default.** `HttpProxyHandler`/`HttpClientCodec` are only + instantiated at all if an operator has separately configured an HTTP proxy for the OTLP exporter, + which isn't Solr's default posture. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources, and Solr's own HTTP server is Jetty, not Netty, so no inbound Solr traffic is ever parsed + by `HttpClientCodec` either way (it's a client-side class regardless). + +Since Solr never exercises a multi-request HTTP/1.1 exchange over any Netty channel, the +request/response pairing this bug corrupts never has more than one entry to desync, 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42585.md b/content/solr/vex/2026-07-18-cve-2026-42585.md new file mode 100644 index 000000000..0f0a58264 --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42585.md @@ -0,0 +1,39 @@ +--- +cve: CVE-2026-42585 +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 malformed Transfer-Encoding parsing" +--- +CVE-2026-42585 (CWE-444) is a request-smuggling issue in `netty-codec-http`'s HTTP/1.x +decoder: a malformed `Transfer-Encoding` header value is parsed incorrectly, so Netty and a +front-end HTTP intermediary can disagree about whether a request is chunked. 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. +This is a **decoder**-side issue — it only bites when Netty parses an inbound HTTP/1.x 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, and Solr's + outbound gRPC client only ever decodes a proxy's CONNECT *response* (if a proxy is configured at + all, an optional non-default setup), never an inbound HTTP/1.x request. +* **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.x 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42587.md b/content/solr/vex/2026-07-18-cve-2026-42587.md new file mode 100644 index 000000000..c2420c1bf --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-42587.md @@ -0,0 +1,41 @@ +--- +cve: CVE-2026-42587 +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: HttpContentDecompressor maxAllocation bypass for br/zstd/snappy" +--- +CVE-2026-42587 (CVSS 7.5, CWE-400 / CWE-770) is a resource-exhaustion issue in `netty-codec-http`'s +`HttpContentDecompressor`: its `maxAllocation` parameter, meant to cap decompression-buffer size +and prevent decompression-bomb attacks, is correctly enforced for `gzip`/`deflate` (via +`ZlibDecoder`) but silently ignored for `br` (Brotli), `zstd`, and `snappy` content encodings — so +a compressed body using one of those encodings can bypass the limit and trigger unbounded memory +allocation. 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. + +`HttpContentDecompressor` is part of `netty-codec-http`. 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. Solr is **not affected**: + +* **`HttpContentDecompressor` is never added to any pipeline Solr builds.** It's an opt-in handler + for automatic HTTP/1.x content decoding; gRPC has its own separate message-compression framework + (negotiated at the gRPC layer, using `gzip`/`identity`) that doesn't route through Netty's HTTP + content-encoding decompressor at all. +* **The only HTTP/1.x traffic Solr's Netty usage ever generates is a proxy CONNECT exchange** + (an optional, non-default setup for the OTLP exporter), and CONNECT responses don't carry a + compressed body for this handler to decompress in the first place. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. + +Since `HttpContentDecompressor` is never installed in any pipeline Solr's dependencies construct, +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-44249.md b/content/solr/vex/2026-07-18-cve-2026-44249.md new file mode 100644 index 000000000..e6a52226a --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-44249.md @@ -0,0 +1,41 @@ +--- +cve: CVE-2026-44249 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-handler-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: IPv6 subnet-filter bypass in IpSubnetFilterRule" +--- +CVE-2026-44249 (CVSS 8.1, CWE-284 / CWE-697 / CWE-1287) is an access-control bypass in +`netty-handler`'s `IpSubnetFilterRule.compareTo()`: an incorrect IPv6 masking operation lets a +valid public IPv6 address slip past a configured subnet allow/deny rule. `IpSubnetFilterRule` (and +the `RuleBasedIpFilter` that uses it) is a server-side feature an application installs in a Netty +pipeline to accept or reject *inbound* connections by source IP. It affects Netty before +4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-handler-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. +Solr is **not affected**: + +* **Solr never runs a Netty server.** `IpSubnetFilterRule` only matters for filtering *inbound* + connections; Solr's own HTTP server is Jetty, and the only Netty channel in Solr's dependency + graph is `grpc-netty`'s outbound OTLP client, which never accepts an inbound connection to filter + in the first place. +* **Nothing in Solr's dependency graph ever constructs an `IpSubnetFilterRule`.** There's no IP + allow/deny-list feature anywhere in Solr, or in `grpc-netty`'s client channel construction, that + uses this class. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. Any IP-based access control an operator configures for Solr (e.g., at a fronting reverse + proxy, or Jetty's own connection-level controls) is implemented entirely outside Netty. + +Since `IpSubnetFilterRule` is never installed or evaluated anywhere in Solr's dependency graph, 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-45416.md b/content/solr/vex/2026-07-18-cve-2026-45416.md new file mode 100644 index 000000000..47ddfa669 --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-45416.md @@ -0,0 +1,42 @@ +--- +cve: CVE-2026-45416 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-handler-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: unbounded allocation in SNI ClientHello sniffing (SslClientHelloHandler)" +--- +CVE-2026-45416 (CVSS 7.5, CWE-770) is a resource-exhaustion issue in `netty-handler`'s +`SslClientHelloHandler.decode()`: it reads the 24-bit TLS handshake length from an inbound +ClientHello and eagerly allocates a buffer sized to it without a configured limit +(`maxClientHelloLength` defaults to `0`, meaning unlimited), so a crafted ~16 MiB ClientHello can +force a huge, unpooled allocation. This only matters for applications using `SniHandler` (or +`AbstractSniHandler` directly) to peek at a TLS ClientHello's SNI extension and pick a per-hostname +`SSLContext` — a **server-side** TLS-termination feature for inbound connections. It affects Netty +before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-handler-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. +Solr is **not affected**: + +* **Solr never runs a Netty server, let alone a TLS-terminating one that inspects ClientHello + SNI.** `SniHandler`/`SslClientHelloHandler` only matter for a server accepting inbound TLS + connections and routing by SNI hostname. The only Netty channel in Solr's dependency graph is + `grpc-netty`'s outbound OTLP client — a client never receives a ClientHello to sniff. +* **Nothing in Solr's dependency graph installs `SniHandler`.** There's no per-hostname TLS + routing feature anywhere in Solr, or in `grpc-netty`'s client channel construction, that would + need it. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. Solr's own TLS termination (when enabled) is handled entirely by Jetty, not Netty. + +Since `SslClientHelloHandler` is never installed or invoked anywhere in Solr's dependency graph, +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-45536.md b/content/solr/vex/2026-07-18-cve-2026-45536.md new file mode 100644 index 000000000..2bf95e94c --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-45536.md @@ -0,0 +1,45 @@ +--- +cve: CVE-2026-45536 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-transport-native-unix-common-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: file-descriptor leak in Unix domain socket recvFd()" +--- +CVE-2026-45536 (CVSS 4.0, CWE-200 / CWE-772) is a file-descriptor leak in the native/JNI code +backing `netty-transport-native-unix-common`: `netty_unix_socket_recvFd` allocates only 24 bytes +for the ancillary-data control message, so when a peer sends an `SCM_RIGHTS` message carrying two +file descriptors over a Unix domain socket, the kernel installs both fds but Netty's code only +accounts for one, leaking the other on every such message. Its CVSS vector is Attack Vector: +**Local** — this requires a local peer with an existing Unix-domain-socket connection to the +affected process, not a remote/network attacker. It affects Netty before 4.1.135.Final and +4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-transport-native-unix-common` since 9.2.0 (4.1.x through +9.9.0, 4.2.x — `netty-transport-native-unix-common-4.2.6.Final.jar` — from 9.10.0/10.0.0 onward), +the shared native support library underneath Netty's Epoll and KQueue transports. Solr is **not +affected**: + +* **Solr never opens a Unix domain socket via Netty.** `netty_unix_socket_recvFd` is only invoked + when a `DomainSocketChannel`/`UnixChannel` is actually used. Solr's only Netty channel — + `grpc-netty`'s outbound OTLP exporter for the optional `opentelemetry` module — connects over + TCP/IP to a configured collector address, never a local Unix socket. Solr also never enables + ZooKeeper's optional Netty-based connection transport (ZooKeeper's Java client defaults to a + plain-NIO socket implementation, and Solr never overrides that), so there's no Unix-domain-socket + connection anywhere in Solr's dependency graph to leak a file descriptor from. +* **Even where the jar is present, there's no peer positioned to send `SCM_RIGHTS`.** Exploitation + requires a local process already connected over a Unix domain socket to the target, which never + exists here. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. + +Since Solr never establishes a Unix-domain-socket channel through Netty, this native code path 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-47244.md b/content/solr/vex/2026-07-18-cve-2026-47244.md new file mode 100644 index 000000000..7239c537c --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-47244.md @@ -0,0 +1,43 @@ +--- +cve: CVE-2026-47244 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-codec-http2-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: unbounded HTTP/2 concurrent streams (Rapid-Reset-style DoS)" +--- +CVE-2026-47244 (CVSS 5.3, CWE-400) is a resource-exhaustion issue in `netty-codec-http2`: +`DefaultHttp2Connection.DefaultEndpoint` initializes `maxActiveStreams`/`maxStreams` to +`Integer.MAX_VALUE`, and `Http2Settings` doesn't enforce `SETTINGS_MAX_CONCURRENT_STREAMS` unless +an application explicitly configures it. A peer can open hundreds of thousands of stream objects on +a single TCP connection, the same amplification pattern as the 2023 HTTP/2 "Rapid Reset" family +(CVE-2023-44487) — this is a **server-side** concern, since it's the endpoint *accepting* streams +whose limit matters. It affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in +4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-codec-http2-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. +Solr is **not affected**: + +* **Solr never runs an HTTP/2 server.** The unbounded-streams condition only matters for the local + endpoint that accepts streams opened by a remote peer. Solr's only Netty/HTTP2 channel is + `grpc-netty`'s outbound OTLP client — Solr is the one *opening* streams (its own trace-export + RPCs), not accepting an unbounded number of them from arbitrary attackers. +* **The remote peer is a single, operator-configured collector, not an open attack surface.** Even + in the worst case of a malicious or compromised collector opening many streams back at the + client, that's a single trusted, operator-chosen endpoint — not the "hundreds of thousands of + streams from an internet-facing listener" amplification scenario this CVE targets. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. + +Since Solr never accepts inbound HTTP/2 connections through Netty, 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-47691.md b/content/solr/vex/2026-07-18-cve-2026-47691.md new file mode 100644 index 000000000..79305b289 --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-47691.md @@ -0,0 +1,25 @@ +--- +cve: CVE-2026-47691 +category: + - solr/vex +analysis: + state: not_affected + justification: code_not_present +title: "Netty: DNS cache poisoning via insufficient NS record bailiwick checking (netty-resolver-dns not shipped)" +--- +CVE-2026-47691 (CVSS up to 10.0, CWE-345 / CWE-346) is a DNS cache-poisoning issue in Netty's +asynchronous DNS resolver (`io.netty:netty-resolver-dns`): it accepts any NS record from a DNS +response's AUTHORITY section as long as its name is a suffix of the question name, without properly +validating that the record is actually in that nameserver's bailiwick, then caches the associated A +records directly. An attacker who controls an authoritative nameserver for any subdomain can use +this to poison the resolver's cache for parent domains. It affects Netty before 4.1.135.Final and +4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. + +This CVE does not apply to Solr at all — `netty-resolver-dns` isn't in Solr's dependency graph in +the first place. Solr's transitive Netty footprint (via `grpc-netty`, the optional `opentelemetry` +module's OTLP gRPC exporter) pulls in the generic `io.netty:netty-resolver` API module, but never +`netty-resolver-dns`, the separate artifact that contains the actual DNS resolver implementation +this CVE lives in. Neither Solr nor any of its other dependencies (ZooKeeper, gRPC, etc.) uses +Netty for DNS resolution — name lookups go through the JDK's standard `InetAddress`/`java.net` +machinery instead. Solr is **not affected**: the vulnerable component is not shipped, in any +version, on any Solr release line. diff --git a/content/solr/vex/2026-07-18-cve-2026-48043.md b/content/solr/vex/2026-07-18-cve-2026-48043.md new file mode 100644 index 000000000..d70f41799 --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-48043.md @@ -0,0 +1,40 @@ +--- +cve: CVE-2026-48043 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-codec-http2-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: pooled ByteBuf leak in HTTP/2 auto-decompression on flow-control errors" +--- +CVE-2026-48043 (CVSS up to 7.5, CWE-400 / CWE-401 / CWE-772) is a resource-leak issue in +`netty-codec-http2`'s `DelegatingDecompressorFrameListener`: it decompresses `gzip`/`deflate`/`zstd` +HTTP/2 message bodies using a per-stream embedded channel, but when a flow-controller exception +occurs, the pooled `ByteBuf`s involved aren't released — repeated triggering leaks pooled memory +and can eventually crash the JVM with an OOM. `DelegatingDecompressorFrameListener` is an opt-in +listener applications install to get automatic content-encoding-based decompression for generic +HTTP/2 traffic; it affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in +4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-codec-http2-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. +Solr is **not affected**: + +* **`grpc-netty` never installs `DelegatingDecompressorFrameListener`.** gRPC has its own + message-level compression framework, negotiated via `grpc-encoding` request/response metadata and + handled by grpc's own `Codec`/`Compressor` classes — it doesn't route through Netty's generic + HTTP/2 content-encoding auto-decompression listener at all. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources, so nothing in Solr itself installs this listener either. + +Since `DelegatingDecompressorFrameListener` is never installed in any pipeline Solr's dependencies +construct, 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-50010.md b/content/solr/vex/2026-07-18-cve-2026-50010.md new file mode 100644 index 000000000..53a94acad --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-50010.md @@ -0,0 +1,51 @@ +--- +cve: CVE-2026-50010 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-handler-4.2.6.Final.jar +analysis: + state: not_affected + justification: requires_configuration +title: "Netty: hostname verification silently disabled for custom TrustManagers (SimpleTrustManagerFactory)" +--- +CVE-2026-50010 (CVSS 7.5, CWE-347) is a TLS hostname-verification bypass in `netty-handler`: +`SimpleTrustManagerFactory` wraps a user-supplied `X509TrustManager` in an adapter that extends +`X509ExtendedTrustManager` (required by the JDK's `SSLEngine`) but discards the `SSLEngine` +parameters during certificate validation. Because those parameters carry the endpoint identity +Java uses for hostname checking, wrapping a *custom* trust manager this way silently disables +hostname verification — even when `endpointIdentificationAlgorithm` is set to `HTTPS` (Netty +4.2's own default) — leaving the connection open to a man-in-the-middle who presents any +CA-trusted certificate, valid hostname or not. This wrapper only fires when an application supplies +its **own** `TrustManager`/certificate to Netty's `SslContextBuilder`; Netty's normal path of +loading the platform's default trust store never goes through it. It affects Netty before +4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. + +Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-handler-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. +CVE-2026-50010 is **not** considered +exploitable in typical deployments of Apache Solr. Successful exploitation requires a specific, +non-default configuration together with a privileged network position: + +* The `opentelemetry` module is enabled **and** the operator has configured a custom trusted + certificate for the OTLP collector connection (e.g. via `OTEL_EXPORTER_OTLP_CERTIFICATE`, used to + trust a private/internal CA or self-signed collector certificate). That certificate-override path + is exactly what causes the OTLP exporter's `NettyChannelBuilder` to build its `SslContext` via + Netty's `SslContextBuilder.trustManager(...)`, the code path this bug affects. +* A man-in-the-middle attacker able to intercept the connection to the configured OTLP endpoint + presents a certificate issued by that same trusted CA, for any hostname. + +Solr's default configuration ships the `opentelemetry` module disabled, and even when enabled, OTLP +export defaults to the JVM's ordinary default trust store — which loads trust managers through the +platform `TrustManagerFactory`, not Netty's `SimpleTrustManagerFactory` wrapper, and is therefore +unaffected. Only operators who have both enabled OTLP tracing *and* pointed it at a custom trusted +certificate are exposed, and even then only to an attacker already positioned to intercept that +specific outbound connection. + +Operators who do configure a custom OTLP trusted certificate should either restrict network access +to the collector endpoint (e.g. a private network path with no attacker-reachable intercept point) +until upgrading, or upgrade the bundled Netty once a Solr release ships 4.1.135.Final/4.2.15.Final — +already present on the `branch_9x` (→ 9.11.0) and `branch_10x` (→ 10.1.0) development branches, but +not yet in any released Solr line. diff --git a/content/solr/vex/2026-07-18-cve-2026-50020.md b/content/solr/vex/2026-07-18-cve-2026-50020.md new file mode 100644 index 000000000..7303e3c2a --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-50020.md @@ -0,0 +1,41 @@ +--- +cve: CVE-2026-50020 +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 overly permissive leading control-character skipping" +--- +CVE-2026-50020 (CVSS 5.3, CWE-444) is a request-smuggling issue in `netty-codec-http`'s +`HttpObjectDecoder`: before parsing a request line, it skips leading control characters +(0x00–0x1F and 0x7F) and whitespace, more permissive than RFC 9112, which only allows ignoring an +empty leading CRLF. This over-tolerant framing can let a crafted request boundary be interpreted +differently by Netty than by a front-end intermediary. It affects Netty before 4.1.135.Final and +4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.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. +This is a **decoder**-side issue — it only bites when Netty parses an inbound HTTP/1.x 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, and Solr's + outbound gRPC client only ever decodes a proxy's CONNECT *response* (if a proxy is configured at + all, an optional non-default setup), never an inbound HTTP/1.x request. +* **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.x 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. diff --git a/content/solr/vex/2026-07-18-cve-2026-50560.md b/content/solr/vex/2026-07-18-cve-2026-50560.md new file mode 100644 index 000000000..092a9953f --- /dev/null +++ b/content/solr/vex/2026-07-18-cve-2026-50560.md @@ -0,0 +1,40 @@ +--- +cve: CVE-2026-50560 +category: + - solr/vex +versions: "9.2.0-9.10.x,10.0.x" +jars: + - netty-codec-http2-4.2.6.Final.jar +analysis: + state: not_affected + justification: code_not_reachable +title: "Netty: HTTP/2 max-header-size handling enables Rapid-Reset-style DoS" +--- +CVE-2026-50560 (CVSS 5.3, CWE-770) is a resource-exhaustion issue in `netty-codec-http2`, in the +same "HTTP/2 Rapid Reset" family of attacks as the 2023 stream-reset issue (CVE-2023-44487) but +with a different trigger: a client that advertises `SETTINGS_MAX_HEADER_LIST_SIZE` can cause the +server to read a request, start proxying/processing it, attempt to generate a response, and then +throw an exception while writing the response headers — repeating this cheaply, many times, wastes +server-side resources with a different signature than a classic stream reset. This is a +**server-side** concern: it targets the endpoint accepting and processing inbound requests. It +affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and +4.2.15.Final. + +Solr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — +`netty-codec-http2-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. +Solr is **not affected**: + +* **Solr never runs an HTTP/2 server.** This attack requires a server that reads and attempts to + process many abusive client requests. Solr's only Netty/HTTP2 channel is `grpc-netty`'s outbound + OTLP client — Solr is the one sending requests to a single, operator-configured collector, not + accepting them from arbitrary attackers. +* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java + sources. + +Since Solr never accepts inbound HTTP/2 connections through Netty, 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. From 511e2a7fb875179df0398c8d147b276dd1b18f10 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 19 Jul 2026 10:39:41 -0300 Subject: [PATCH 2/3] Provide more detailed history of netty in Solr, looking back at the netty-all uber jar. --- content/solr/vex/2026-07-18-cve-2026-41417.md | 16 ++++++------ content/solr/vex/2026-07-18-cve-2026-42577.md | 18 +++++++------ content/solr/vex/2026-07-18-cve-2026-42578.md | 9 +++---- content/solr/vex/2026-07-18-cve-2026-42580.md | 8 +++--- content/solr/vex/2026-07-18-cve-2026-42581.md | 6 +++-- content/solr/vex/2026-07-18-cve-2026-42583.md | 12 +++++---- content/solr/vex/2026-07-18-cve-2026-42584.md | 14 +++++++---- content/solr/vex/2026-07-18-cve-2026-42585.md | 6 +++-- content/solr/vex/2026-07-18-cve-2026-42587.md | 4 ++- content/solr/vex/2026-07-18-cve-2026-44249.md | 23 ++++++++++------- content/solr/vex/2026-07-18-cve-2026-45416.md | 25 ++++++++++++------- content/solr/vex/2026-07-18-cve-2026-45536.md | 15 +++++++---- content/solr/vex/2026-07-18-cve-2026-50010.md | 17 +++++++------ content/solr/vex/2026-07-18-cve-2026-50020.md | 6 +++-- 14 files changed, 109 insertions(+), 70 deletions(-) diff --git a/content/solr/vex/2026-07-18-cve-2026-41417.md b/content/solr/vex/2026-07-18-cve-2026-41417.md index 589e4963a..b8edddc59 100644 --- a/content/solr/vex/2026-07-18-cve-2026-41417.md +++ b/content/solr/vex/2026-07-18-cve-2026-41417.md @@ -17,13 +17,15 @@ construction has no equivalent validation, so an attacker who controls a value l `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 -(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**: +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. diff --git a/content/solr/vex/2026-07-18-cve-2026-42577.md b/content/solr/vex/2026-07-18-cve-2026-42577.md index dccd6a8e0..36c4a4861 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42577.md +++ b/content/solr/vex/2026-07-18-cve-2026-42577.md @@ -17,14 +17,16 @@ CPU. It affects Netty 4.2.0.Final up to (but not including) 4.2.13.Final — the 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**: +`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. Solr is **not affected**: * **Solr never selects ZooKeeper's Netty transport.** ZooKeeper picks its client socket implementation via the `zookeeper.clientCnxnSocket` system property, defaulting to the diff --git a/content/solr/vex/2026-07-18-cve-2026-42578.md b/content/solr/vex/2026-07-18-cve-2026-42578.md index f54aa615e..2f9ad91d6 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42578.md +++ b/content/solr/vex/2026-07-18-cve-2026-42578.md @@ -19,11 +19,10 @@ influences those header values can inject arbitrary headers, or split, the CONNE 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 -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 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 diff --git a/content/solr/vex/2026-07-18-cve-2026-42580.md b/content/solr/vex/2026-07-18-cve-2026-42580.md index 6ce34f10a..c745c16e2 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42580.md +++ b/content/solr/vex/2026-07-18-cve-2026-42580.md @@ -22,9 +22,11 @@ bugs that have affected HTTP implementations. It affects Netty before 4.1.133.Fi 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. -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**: +`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 diff --git a/content/solr/vex/2026-07-18-cve-2026-42581.md b/content/solr/vex/2026-07-18-cve-2026-42581.md index 0519ab388..4c03e35df 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42581.md +++ b/content/solr/vex/2026-07-18-cve-2026-42581.md @@ -20,8 +20,10 @@ 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. -This is a **decoder**-side bug — it only bites when Netty parses an inbound HTTP/1.0/1.1 request. -Solr is **not affected**: +`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 diff --git a/content/solr/vex/2026-07-18-cve-2026-42583.md b/content/solr/vex/2026-07-18-cve-2026-42583.md index 49d1e992f..a4900bed2 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42583.md +++ b/content/solr/vex/2026-07-18-cve-2026-42583.md @@ -17,11 +17,13 @@ crafted frame that lies about its decompressed size can force large allocations 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` is not a dependency Solr has carried since 9.2.0, when Netty first -became a transitive dependency — it's a byproduct of Netty's own 4.2 module split (compression -codecs, which used to live in `netty-codec`, were broken out into their own artifact) and so first -appears starting with Solr 9.10.0/10.0.0, where Solr moved to Netty 4.2.6.Final (in range for this -CVE). Solr 9.2.0–9.9.0, still on Netty 4.1.x, never carry this artifact at all. Solr is **not +`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 diff --git a/content/solr/vex/2026-07-18-cve-2026-42584.md b/content/solr/vex/2026-07-18-cve-2026-42584.md index 7b33039cd..1be6db025 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42584.md +++ b/content/solr/vex/2026-07-18-cve-2026-42584.md @@ -17,11 +17,15 @@ sends a 1xx response ahead of the real final response, the codec's request/respo and a later response's body gets parsed from the wrong offset. 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. -`HttpClientCodec` is the HTTP/1.1 client-side codec Solr's dependency graph only ever uses inside -Netty's `HttpProxyHandler`, to send an HTTP CONNECT request and parse the proxy's response when -tunneling `grpc-netty`'s OTLP export traffic through an HTTP proxy — itself a non-default -configuration, since Solr never sets any JVM-wide HTTP proxy properties itself. Solr is **not -affected**: +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. +`HttpClientCodec` 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. It's the HTTP/1.1 +client-side codec inside that jar, and Solr's dependency graph only ever uses it inside Netty's +`HttpProxyHandler`, to send an HTTP CONNECT request and parse the proxy's response when tunneling +`grpc-netty`'s OTLP export traffic through an HTTP proxy — itself a non-default configuration, +since Solr never sets any JVM-wide HTTP proxy properties itself. Solr is **not affected**: * **The bug requires a pipelined sequence of requests/responses (including 1xx) to desync.** A CONNECT tunnel is a single request/response exchange — once established, the connection carries diff --git a/content/solr/vex/2026-07-18-cve-2026-42585.md b/content/solr/vex/2026-07-18-cve-2026-42585.md index 0f0a58264..663cb8583 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42585.md +++ b/content/solr/vex/2026-07-18-cve-2026-42585.md @@ -18,8 +18,10 @@ before 4.1.133.Final and 4.2.0.Alpha1–4.2.12.Final; fixed in 4.1.133.Final and 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. -This is a **decoder**-side issue — it only bites when Netty parses an inbound HTTP/1.x request. -Solr is **not affected**: +This HTTP/1.x decoder itself isn't new at that point — earlier Solr releases (7.x through 8.2.x) +already shipped this same code, bundled in the older `netty-all` uber-jar. This is a +**decoder**-side issue — it only bites when Netty parses an inbound HTTP/1.x 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 diff --git a/content/solr/vex/2026-07-18-cve-2026-42587.md b/content/solr/vex/2026-07-18-cve-2026-42587.md index c2420c1bf..1b7122c64 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42587.md +++ b/content/solr/vex/2026-07-18-cve-2026-42587.md @@ -21,7 +21,9 @@ allocation. It affects Netty before 4.1.133.Final and 4.2.0.Alpha1–4.2.12.Fina `HttpContentDecompressor` is part of `netty-codec-http`. 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. Solr is **not affected**: +by the optional `opentelemetry` module's OTLP gRPC exporter. `HttpContentDecompressor` 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. Solr is **not affected**: * **`HttpContentDecompressor` is never added to any pipeline Solr builds.** It's an opt-in handler for automatic HTTP/1.x content decoding; gRPC has its own separate message-compression framework diff --git a/content/solr/vex/2026-07-18-cve-2026-44249.md b/content/solr/vex/2026-07-18-cve-2026-44249.md index e6a52226a..088aea05b 100644 --- a/content/solr/vex/2026-07-18-cve-2026-44249.md +++ b/content/solr/vex/2026-07-18-cve-2026-44249.md @@ -2,7 +2,7 @@ cve: CVE-2026-44249 category: - solr/vex -versions: "9.2.0-9.10.x,10.0.x" +versions: "8.3.0-9.10.x,10.0.x" jars: - netty-handler-4.2.6.Final.jar analysis: @@ -17,18 +17,23 @@ the `RuleBasedIpFilter` that uses it) is a server-side feature an application in pipeline to accept or reject *inbound* connections by source IP. It affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. -Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — -`netty-handler-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. +Solr has shipped `netty-handler` — the modular jar this CVE concerns — since **8.3.0** (SOLR-13665, +`netty-handler-4.2.6.Final.jar` in the current 9.10.x/10.0.x lines), as a transitive dependency of +**Apache ZooKeeper**'s client library (`org.apache.zookeeper:zookeeper`), which optionally supports +a Netty-based connection socket. Earlier Solr releases (7.x through 8.2.x) already shipped this +same `IpSubnetFilterRule` class too, bundled in the older `netty-all` uber-jar; 8.3.0 is when Solr's +build started declaring the modular artifacts explicitly instead. Since **9.2.0** `netty-handler` +has also arrived via `grpc-netty`, used by the optional `opentelemetry` module's OTLP gRPC exporter. Solr is **not affected**: * **Solr never runs a Netty server.** `IpSubnetFilterRule` only matters for filtering *inbound* - connections; Solr's own HTTP server is Jetty, and the only Netty channel in Solr's dependency - graph is `grpc-netty`'s outbound OTLP client, which never accepts an inbound connection to filter - in the first place. + connections. Solr's own HTTP server is Jetty; ZooKeeper's optional Netty-based connection socket + is never selected (ZooKeeper defaults to a plain-NIO client, and Solr never configures otherwise); + and `grpc-netty`'s outbound OTLP client never accepts an inbound connection to filter in the + first place. * **Nothing in Solr's dependency graph ever constructs an `IpSubnetFilterRule`.** There's no IP - allow/deny-list feature anywhere in Solr, or in `grpc-netty`'s client channel construction, that - uses this class. + allow/deny-list feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s + client channel construction, that uses this class. * **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java sources. Any IP-based access control an operator configures for Solr (e.g., at a fronting reverse proxy, or Jetty's own connection-level controls) is implemented entirely outside Netty. diff --git a/content/solr/vex/2026-07-18-cve-2026-45416.md b/content/solr/vex/2026-07-18-cve-2026-45416.md index 47ddfa669..6d4c6e295 100644 --- a/content/solr/vex/2026-07-18-cve-2026-45416.md +++ b/content/solr/vex/2026-07-18-cve-2026-45416.md @@ -2,7 +2,7 @@ cve: CVE-2026-45416 category: - solr/vex -versions: "9.2.0-9.10.x,10.0.x" +versions: "8.6.0-9.10.x,10.0.x" jars: - netty-handler-4.2.6.Final.jar analysis: @@ -19,18 +19,25 @@ force a huge, unpooled allocation. This only matters for applications using `Sni `SSLContext` — a **server-side** TLS-termination feature for inbound connections. It affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. -Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — -`netty-handler-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. -Solr is **not affected**: +`netty-handler` has shipped in Solr since 8.3.0 (SOLR-13665), via **Apache ZooKeeper**'s client +library, but `SslClientHelloHandler` — the specific class this CVE concerns — didn't exist yet at +that point: Solr 8.3.0–8.5.2 pinned Netty 4.1.29.Final, which lacks it entirely (Netty only +introduced it in 4.1.47.Final). Solr picked up that version starting at **8.6.0**, so that's the +true first-shipped point for this specific vulnerability, not 8.3.0. `SniHandler` itself (the +class applications actually configure) existed earlier, in both 4.1.29.Final and the older +`netty-all` uber-jar Solr shipped before 8.3.0 — but the unbounded-allocation bug lives in +`SslClientHelloHandler`, a piece `SniHandler` was refactored to delegate to only later. Since +**9.2.0**, `netty-handler` has also arrived via `grpc-netty`, used by the optional `opentelemetry` +module's OTLP gRPC exporter. Solr is **not affected**: * **Solr never runs a Netty server, let alone a TLS-terminating one that inspects ClientHello SNI.** `SniHandler`/`SslClientHelloHandler` only matter for a server accepting inbound TLS - connections and routing by SNI hostname. The only Netty channel in Solr's dependency graph is - `grpc-netty`'s outbound OTLP client — a client never receives a ClientHello to sniff. + connections and routing by SNI hostname. ZooKeeper's optional Netty-based connection socket is + never selected (ZooKeeper defaults to a plain-NIO client, and Solr never configures otherwise), + and `grpc-netty`'s outbound OTLP client never receives a ClientHello to sniff either way. * **Nothing in Solr's dependency graph installs `SniHandler`.** There's no per-hostname TLS - routing feature anywhere in Solr, or in `grpc-netty`'s client channel construction, that would - need it. + routing feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s client + channel construction, that would need it. * **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java sources. Solr's own TLS termination (when enabled) is handled entirely by Jetty, not Netty. diff --git a/content/solr/vex/2026-07-18-cve-2026-45536.md b/content/solr/vex/2026-07-18-cve-2026-45536.md index 2bf95e94c..8d583b52d 100644 --- a/content/solr/vex/2026-07-18-cve-2026-45536.md +++ b/content/solr/vex/2026-07-18-cve-2026-45536.md @@ -2,7 +2,7 @@ cve: CVE-2026-45536 category: - solr/vex -versions: "9.2.0-9.10.x,10.0.x" +versions: "8.3.0-9.10.x,10.0.x" jars: - netty-transport-native-unix-common-4.2.6.Final.jar analysis: @@ -19,10 +19,15 @@ accounts for one, leaking the other on every such message. Its CVSS vector is At affected process, not a remote/network attacker. It affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. -Solr has shipped a vulnerable `netty-transport-native-unix-common` since 9.2.0 (4.1.x through -9.9.0, 4.2.x — `netty-transport-native-unix-common-4.2.6.Final.jar` — from 9.10.0/10.0.0 onward), -the shared native support library underneath Netty's Epoll and KQueue transports. Solr is **not -affected**: +`netty-transport-native-unix-common` — the modular jar this CVE concerns — has been part of Solr's +dependency graph since **8.3.0** (SOLR-13665, `netty-transport-native-unix-common-4.2.6.Final.jar` +in the current 9.10.x/10.0.x lines), the shared native support library underneath Netty's Epoll and +KQueue transports, pulled in via **Apache ZooKeeper**'s client library and, since 9.2.0, also +directly by `grpc-netty`. Older Solr releases (7.x through 8.2.x) already bundled this same native +Unix-domain-socket code, in the older `netty-all` uber-jar at ancient 4.0.x Netty versions — the +same architectural reasoning below (Solr never opens a Unix domain socket via Netty) applies to +those releases just as it does here, independent of which jar or Netty version carries the code. +Solr is **not affected**: * **Solr never opens a Unix domain socket via Netty.** `netty_unix_socket_recvFd` is only invoked when a `DomainSocketChannel`/`UnixChannel` is actually used. Solr's only Netty channel — diff --git a/content/solr/vex/2026-07-18-cve-2026-50010.md b/content/solr/vex/2026-07-18-cve-2026-50010.md index 53a94acad..1f76fd0c9 100644 --- a/content/solr/vex/2026-07-18-cve-2026-50010.md +++ b/content/solr/vex/2026-07-18-cve-2026-50010.md @@ -2,7 +2,7 @@ cve: CVE-2026-50010 category: - solr/vex -versions: "9.2.0-9.10.x,10.0.x" +versions: "8.3.0-9.10.x,10.0.x" jars: - netty-handler-4.2.6.Final.jar analysis: @@ -22,12 +22,15 @@ its **own** `TrustManager`/certificate to Netty's `SslContextBuilder`; Netty's n loading the platform's default trust store never goes through it. It affects Netty before 4.1.135.Final and 4.2.0.Final–4.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final. -Solr has shipped a vulnerable `netty-handler` since 9.2.0 (4.1.x through 9.9.0, 4.2.x — -`netty-handler-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. -CVE-2026-50010 is **not** considered -exploitable in typical deployments of Apache Solr. Successful exploitation requires a specific, -non-default configuration together with a privileged network position: +Solr has shipped `netty-handler` — the modular jar this CVE concerns — since **8.3.0** (SOLR-13665, +`netty-handler-4.2.6.Final.jar` in the current 9.10.x/10.0.x lines), as a transitive dependency of +**Apache ZooKeeper**'s client library (earlier Solr releases, 7.x through 8.2.x, already shipped +this same `SimpleTrustManagerFactory` class too, bundled in the older `netty-all` uber-jar). None of +that matters for this specific CVE, though: the vulnerable scenario only becomes *possible* starting +in **9.2.0**, when the optional `opentelemetry` module (and its `grpc-netty` OTLP exporter) was +introduced — Solr versions before 9.2.0 don't have this module at all. CVE-2026-50010 is **not** +considered exploitable in typical deployments of Apache Solr. Successful exploitation requires a +specific, non-default configuration together with a privileged network position: * The `opentelemetry` module is enabled **and** the operator has configured a custom trusted certificate for the OTLP collector connection (e.g. via `OTEL_EXPORTER_OTLP_CERTIFICATE`, used to diff --git a/content/solr/vex/2026-07-18-cve-2026-50020.md b/content/solr/vex/2026-07-18-cve-2026-50020.md index 7303e3c2a..709acf709 100644 --- a/content/solr/vex/2026-07-18-cve-2026-50020.md +++ b/content/solr/vex/2026-07-18-cve-2026-50020.md @@ -20,8 +20,10 @@ differently by Netty than by a front-end intermediary. It affects Netty before 4 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. -This is a **decoder**-side issue — it only bites when Netty parses an inbound HTTP/1.x request. -Solr is **not affected**: +`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 issue — it only bites when Netty parses an inbound HTTP/1.x 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 From b636c0eb6ceb0416d2240df4e810ef5438b34628 Mon Sep 17 00:00:00 2001 From: Eric Pugh Date: Sun, 19 Jul 2026 11:01:01 -0300 Subject: [PATCH 3/3] Be more explicit about zk and ssl... --- content/solr/vex/2026-07-18-cve-2026-42577.md | 53 +++++++++++++------ content/solr/vex/2026-07-18-cve-2026-44249.md | 10 ++-- content/solr/vex/2026-07-18-cve-2026-45416.md | 8 +-- content/solr/vex/2026-07-18-cve-2026-45536.md | 10 ++-- 4 files changed, 53 insertions(+), 28 deletions(-) diff --git a/content/solr/vex/2026-07-18-cve-2026-42577.md b/content/solr/vex/2026-07-18-cve-2026-42577.md index 36c4a4861..82033bcfe 100644 --- a/content/solr/vex/2026-07-18-cve-2026-42577.md +++ b/content/solr/vex/2026-07-18-cve-2026-42577.md @@ -7,7 +7,7 @@ jars: - netty-transport-native-epoll-4.2.6.Final.jar analysis: state: not_affected - justification: code_not_reachable + 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 @@ -26,24 +26,43 @@ already bundled Netty's Epoll transport code too, in the older `netty-all` uber- 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. Solr is **not affected**: +on the classpath. -* **Solr never selects ZooKeeper's Netty transport.** ZooKeeper picks its client socket - implementation via the `zookeeper.clientCnxnSocket` system property, defaulting to the - plain-NIO `ClientCnxnSocketNIO`. Solr never sets that property (or configures - `NettyServerCnxnFactory`) anywhere in its own source, scripts, or documentation, so the bundled - `netty-transport-native-epoll` jar sits unused on the classpath — ZooKeeper connections always go - through the default NIO socket, never through Netty's Epoll channel implementation. -* **The gRPC/OpenTelemetry path doesn't touch it either.** 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. -* **No Solr code instantiates an Epoll channel.** There are no `io.netty` imports anywhere in - Solr's own Java sources, and nothing in Solr's dependency graph exercises the Epoll transport - classes at runtime. +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: -Since the vulnerable Epoll channel-close logic is never invoked — it's present on the classpath -only as an unreferenced, unused transitive jar — Solr is not affected regardless of whether the -pinned Netty falls in the vulnerable range. +* 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 diff --git a/content/solr/vex/2026-07-18-cve-2026-44249.md b/content/solr/vex/2026-07-18-cve-2026-44249.md index 088aea05b..5cb3e04b0 100644 --- a/content/solr/vex/2026-07-18-cve-2026-44249.md +++ b/content/solr/vex/2026-07-18-cve-2026-44249.md @@ -27,10 +27,12 @@ has also arrived via `grpc-netty`, used by the optional `opentelemetry` module's Solr is **not affected**: * **Solr never runs a Netty server.** `IpSubnetFilterRule` only matters for filtering *inbound* - connections. Solr's own HTTP server is Jetty; ZooKeeper's optional Netty-based connection socket - is never selected (ZooKeeper defaults to a plain-NIO client, and Solr never configures otherwise); - and `grpc-netty`'s outbound OTLP client never accepts an inbound connection to filter in the - first place. + connections at a server. Solr's own HTTP server is Jetty. ZooKeeper's client socket defaults to + plain NIO, and Solr never enables its Netty alternative by default — but even an operator who + does enable it (following ZooKeeper's own TLS instructions) only switches Solr's ZooKeeper + *client* socket; that never makes Solr run the corresponding `NettyServerCnxnFactory` server, + which Solr never uses at all. `grpc-netty`'s outbound OTLP client is a client too, and never + accepts an inbound connection to filter either. * **Nothing in Solr's dependency graph ever constructs an `IpSubnetFilterRule`.** There's no IP allow/deny-list feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s client channel construction, that uses this class. diff --git a/content/solr/vex/2026-07-18-cve-2026-45416.md b/content/solr/vex/2026-07-18-cve-2026-45416.md index 6d4c6e295..fd299e9e3 100644 --- a/content/solr/vex/2026-07-18-cve-2026-45416.md +++ b/content/solr/vex/2026-07-18-cve-2026-45416.md @@ -32,9 +32,11 @@ module's OTLP gRPC exporter. Solr is **not affected**: * **Solr never runs a Netty server, let alone a TLS-terminating one that inspects ClientHello SNI.** `SniHandler`/`SslClientHelloHandler` only matter for a server accepting inbound TLS - connections and routing by SNI hostname. ZooKeeper's optional Netty-based connection socket is - never selected (ZooKeeper defaults to a plain-NIO client, and Solr never configures otherwise), - and `grpc-netty`'s outbound OTLP client never receives a ClientHello to sniff either way. + connections and routing by SNI hostname. ZooKeeper's client socket defaults to plain NIO, and + Solr never enables its Netty alternative by default — but even if an operator does (following + ZooKeeper's own TLS instructions), that only switches Solr's ZooKeeper *client* socket, which + never receives a ClientHello to sniff in the first place (a client sends one; it doesn't parse + one). `grpc-netty`'s outbound OTLP client is in the same position. * **Nothing in Solr's dependency graph installs `SniHandler`.** There's no per-hostname TLS routing feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s client channel construction, that would need it. diff --git a/content/solr/vex/2026-07-18-cve-2026-45536.md b/content/solr/vex/2026-07-18-cve-2026-45536.md index 8d583b52d..3176c3720 100644 --- a/content/solr/vex/2026-07-18-cve-2026-45536.md +++ b/content/solr/vex/2026-07-18-cve-2026-45536.md @@ -32,10 +32,12 @@ Solr is **not affected**: * **Solr never opens a Unix domain socket via Netty.** `netty_unix_socket_recvFd` is only invoked when a `DomainSocketChannel`/`UnixChannel` is actually used. Solr's only Netty channel — `grpc-netty`'s outbound OTLP exporter for the optional `opentelemetry` module — connects over - TCP/IP to a configured collector address, never a local Unix socket. Solr also never enables - ZooKeeper's optional Netty-based connection transport (ZooKeeper's Java client defaults to a - plain-NIO socket implementation, and Solr never overrides that), so there's no Unix-domain-socket - connection anywhere in Solr's dependency graph to leak a file descriptor from. + TCP/IP to a configured collector address, never a local Unix socket. ZooKeeper's client socket + defaults to plain NIO, and Solr never enables its Netty alternative by default — but even if an + operator does (following ZooKeeper's own TLS instructions), that transport still addresses the + ensemble over ordinary TCP/IP host:port connections, never a local Unix domain socket, so there's + still no Unix-domain-socket connection anywhere in Solr's dependency graph to leak a file + descriptor from. * **Even where the jar is present, there's no peer positioned to send `SCM_RIGHTS`.** Exploitation requires a local process already connected over a Unix domain socket to the target, which never exists here.