diff --git a/content/solr/vex/2026-08-23-cve-2025-24970.md b/content/solr/vex/2026-08-23-cve-2025-24970.md
new file mode 100644
index 000000000..5f733b73d
--- /dev/null
+++ b/content/solr/vex/2026-08-23-cve-2025-24970.md
@@ -0,0 +1,47 @@
+---
+cve: CVE-2025-24970
+jira: SOLR-17826
+category:
+  - solr/vex
+versions: "9.3.0-9.9.0"
+jars:
+  - netty-handler-4.1.114.Final.jar
+analysis:
+  state: not_affected
+  justification: requires_configuration
+title: "Netty: SslHandler native crash on crafted packets"
+---
+CVE-2025-24970 is a flaw in Netty's `SslHandler`: when the native (OpenSSL/BoringSSL, via
+`netty-tcnative`) TLS engine is in use, a specially crafted packet received during TLS
+processing is not properly validated, which can trigger a native crash (JVM segfault) rather
+than a clean exception. It affects Netty `netty-handler` versions 4.1.91.Final through
+4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at
+all — 4.2.0.Final was cut after the fix had already landed upstream.
+
+Solr shipped an affected `netty-handler` from 9.3.0 (4.1.93.Final) through 9.9.0
+(4.1.114.Final), arriving as a transitive runtime dependency of `io.grpc:grpc-netty`, used only
+by the optional **opentelemetry** module's OTLP gRPC trace exporter. Solr 9.10.0 onward already
+ships Netty 4.2.6.Final or later — outside the affected range — so no currently released Solr
+version bundles a vulnerable `netty-handler`. Solr is **not affected** even on the older,
+already-released 9.3.0–9.9.0 line:
+
+* **The opentelemetry module is optional and disabled by default.** It must be explicitly
+  enabled (e.g. via `-Dsolr.modules=opentelemetry`) before `grpc-netty`, and therefore
+  `netty-handler`, is even loaded.
+* **Netty is used only as an outbound gRPC client dialing the operator's own configured OTLP
+  collector**, not as a listener accepting arbitrary inbound connections. `SslHandler`'s
+  crafted-packet validation only matters for TLS data arriving from the remote peer on that
+  connection — here, the operator-designated collector endpoint, not an attacker-facing socket.
+* **Solr's own request-handling surface is Jetty, not Netty.** Every attacker-facing API call
+  Solr accepts is parsed and served by Jetty; `io.netty` code is never invoked to process
+  inbound requests to Solr itself.
+* Exploitation would additionally require the operator to have pointed OTLP export at a
+  compromised or malicious collector (or accepted an on-path attacker on that egress route) —
+  a threat model outside standard use of this optional telemetry feature.
+
+No released Solr version ships a fix for this specific line, because none currently needs one:
+9.10.0+ already carries a post-fix Netty. The `branch_9x` (→ 9.11.0) and `main`/`branch_10x`
+(→ 10.x) development branches have since moved further still, to Netty 4.2.15.Final and
+4.2.17.Final respectively — picked up incidentally through routine dependency updates rather
+than a targeted SOLR-17826 fix commit. SOLR-17826 remains open upstream and should be closed
+out to reflect that no supported or in-development Solr line is exposed.