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..b8edddc59
--- /dev/null
+++ b/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.
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..82033bcfe
--- /dev/null
+++ b/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.
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..2f9ad91d6
--- /dev/null
+++ b/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.
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..c745c16e2
--- /dev/null
+++ b/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.
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..4c03e35df
--- /dev/null
+++ b/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.
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..a4900bed2
--- /dev/null
+++ b/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.
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..1be6db025
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-42584.md
@@ -0,0 +1,47 @@
+---
+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.
+
+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
+  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..663cb8583
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-42585.md
@@ -0,0 +1,41 @@
+---
+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 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
+  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..1b7122c64
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-42587.md
@@ -0,0 +1,43 @@
+---
+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. `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
+  (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..5cb3e04b0
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-44249.md
@@ -0,0 +1,48 @@
+---
+cve: CVE-2026-44249
+category:
+  - solr/vex
+versions: "8.3.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 `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 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.
+* **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..fd299e9e3
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-45416.md
@@ -0,0 +1,51 @@
+---
+cve: CVE-2026-45416
+category:
+  - solr/vex
+versions: "8.6.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.
+
+`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. 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.
+* **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..3176c3720
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-45536.md
@@ -0,0 +1,52 @@
+---
+cve: CVE-2026-45536
+category:
+  - solr/vex
+versions: "8.3.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.
+
+`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 —
+  `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. 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.
+* **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..1f76fd0c9
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-50010.md
@@ -0,0 +1,54 @@
+---
+cve: CVE-2026-50010
+category:
+  - solr/vex
+versions: "8.3.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 `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
+  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..709acf709
--- /dev/null
+++ b/content/solr/vex/2026-07-18-cve-2026-50020.md
@@ -0,0 +1,43 @@
+---
+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.
+`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
+  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.