Apache Solr VEX
← Back to the dependency CVE table
Description
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.
References
Description
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.
References
Description
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.
References
Description
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 ByteBufs 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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
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.
References
Description
CVE-2026-5795 (CVSS 7.4) is a broken-access-control / privilege-escalation issue in Eclipse Jetty's
JASPIAuthenticator (the JSR-196 / Jakarta Authentication "JASPI" integration). During an
authentication check it sets thread-local state and, on an early return, fails to clear it, so a
subsequent request served by the same pooled thread can inherit that authentication state. It
affects Jetty 9.4.0–9.4.60, 10.0.0–10.0.28, 11.0.0–11.0.28, 12.0.0–12.0.33 and 12.1.0–12.1.7; it is
fixed in 9.4.61, 10.0.29, 11.0.29, 12.0.34 and 12.1.8.
Apache Solr 9.x bundles an affected Jetty (jetty-server-10.0.26.jar in the current 9.x line, and
Jetty 9.4.44 in earlier 9.x releases), so dependency scanners flag this CVE. Solr is not affected:
- The vulnerable code is not shipped.
JASPIAuthenticator lives in Jetty's jetty-jaspi
module. Solr does not depend on jetty-jaspi — it is absent from Solr's dependency set (the build
pulls in jetty-server, jetty-security, jetty-servlet, etc., but not jetty-jaspi), so the
vulnerable class is not on the classpath.
- Solr does not use JASPI. Solr authenticates requests in a servlet filter
(
SolrDispatchFilter) through its own AuthenticationPlugin framework (Basic, JWT, Kerberos,
PKI, etc.). It never installs a Jetty SecurityHandler/Authenticator, and never the JASPI
mechanism, so the vulnerable code path is unreachable even if the module were present.
Solr has bundled a Jetty version in an affected branch (≥ 9.4.0) since Solr 7.3.0 — Jetty 9.4.x
through Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (below the fixed
12.0.34) — so scanners flag this CVE across Solr 7.3.0 – 10.0.0. Solr remains not affected
throughout that range because it never ships the jetty-jaspi module, regardless of the bundled
Jetty version.
References
Description
CVE-2026-2332 (CVSS 9.1) is an HTTP request-smuggling issue (CWE-444) in Eclipse Jetty's HTTP/1.1
parser: the chunk-extension parser stops at a \r\n inside a quoted string instead of treating it
as an error, so a crafted chunk extension can desynchronize request boundaries between Jetty and a
front-end HTTP intermediary. It affects Jetty 9.4.0–9.4.59, 10.0.0–10.0.27, 11.0.0–11.0.27,
12.0.0–12.0.32 and 12.1.0–12.1.6; it is fixed in 9.4.60, 10.0.28, 11.0.28, 12.0.33 and 12.1.7.
Unlike optional Jetty features (for example the JASPI authenticator), this is core request-parsing
code. Solr embeds Jetty as its HTTP server and bundles the vulnerable jetty-http module
(HttpParser) — jetty-http-10.0.26.jar in the Solr 9.x line, and Jetty 9.4.44 in earlier 9.x
releases. Solr does not replace Jetty's wire-level HTTP parser, and it accepts chunked request
bodies, so the vulnerable parser handles incoming requests and the code path is reachable.
Exploitability depends on a fronting proxy
Request smuggling is a desynchronization attack: it requires a second HTTP processor in front of
Jetty that parses the crafted chunk extension differently. It is therefore only exploitable when Solr
is deployed behind an HTTP intermediary — a reverse proxy, load balancer, TLS terminator, or API
gateway — that disagrees with Jetty on request boundaries. This is a common Solr deployment, because
operators frequently front Solr with such a proxy to add TLS and authentication. A Solr instance that
is not fronted by a mis-parsing intermediary has no second parser to desync against, so this
particular attack does not apply to it.
The most damaging scenario is when that fronting proxy is the only security boundary (it enforces
authentication or restricts which Solr paths are reachable): a smuggled request rides past the proxy
and reaches Solr's APIs directly, bypassing those controls.
Mitigation
- Use a re-encoding reverse proxy. A reverse proxy that fully parses and re-encodes the HTTP/1.1
request body before forwarding to Jetty eliminates the attack at the network boundary: the proxy
reads the attacker's malformed chunk extensions, then emits a clean, standards-conformant chunked
(or
Content-Length) request to Solr. No attacker-controlled chunk extension survives the trip, so
Jetty never sees the malformed framing that triggers the desynchronization. nginx (proxy_pass
in HTTP mode) and HAProxy (in http mode) both re-encode by default. Proxies configured in
TCP pass-through or tunnel mode (e.g., HAProxy tcp mode, nginx stream) do not re-encode and
do not mitigate this CVE.
- Enable Solr's built-in authentication and authorization. Solr enforces access control in its
own servlet filter (
SolrDispatchFilter / the AuthenticationPlugin framework), not at the
Jetty layer, so a request smuggled past a front-end proxy still has to pass Solr's own
authentication and authorization. Enabling them removes the "proxy is the only gate" exposure that
makes this attack most severe. (This is a mitigating control, not a complete fix — it does not
eliminate cross-connection effects such as request hijacking or response desync.)
- Upgrade the bundled Jetty to a patched release (≥ 10.0.28 on the 10.0.x line), which is the
full fix, however that requires commercial support. See https://webtide.com/end-of-life/ for options.
Solr has bundled a Jetty version in an affected branch (≥ 9.4.0) since Solr 7.3.0 — Jetty 9.4.x
through Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (which is still
below the fixed 12.0.33). Earlier releases shipped Jetty 9.2.x/9.3.x or 8.1.x, which pre-date the
affected 9.4.0 branch. The affected range is therefore 7.3.0 – 10.0.0; no released Solr yet bundles a
fixed Jetty (≥ 10.0.28 / 12.0.33).
References
Description
CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation) is an improper-input-validation issue
(CWE-20) in Eclipse Jetty's URI parser (HttpURI): it interprets some invalid or unusual URIs
differently from other common HTTP parsers. When a component in front of Jetty parses the same URI
differently, an attacker can craft a malformed URI to bypass URI-based security controls (such as
path allow/deny lists) or to reveal implementation details. It affects Jetty 9.4.0–9.4.58,
10.0.0–10.0.26, 11.0.0–11.0.26, 12.0.0–12.0.30 and 12.1.0–12.1.4; it is fixed in 9.4.59, 10.0.27,
11.0.27, 12.0.31 and 12.1.5.
CVE-2025-11143 is not considered exploitable in production deployments of Apache Solr.
Successful exploitation requires a specific, non-recommended configuration — all of the following
conditions must be true:
- Solr must be deployed behind an HTTP intermediary (reverse proxy, load balancer, or API gateway)
that enforces URI-based access rules (for example, blocking
/solr/admin/* at the proxy layer).
- That intermediary must be the sole security gate — Solr's own authentication and
authorization must not be enabled.
Why Solr auth is a complete fix
This is a differential-parsing issue: it only has security impact when a front-end proxy makes an
access-control decision based on its own URI interpretation and Solr has no independent access control
of its own. Solr enforces access control in its own servlet filter (SolrDispatchFilter /
the AuthenticationPlugin framework) after Jetty has parsed the URI. Because Solr's auth layer
operates on the same already-resolved path that Jetty produced, it cannot be confused by differential
proxy/Jetty parsing — the bypass that the proxy grants does not help an attacker get past Solr's own
auth. Enabling Solr auth provides complete protection, not merely a mitigating control. (This
distinguishes CVE-2025-11143 from request-smuggling issues such as CVE-2026-2332, where Solr auth
reduces impact but does not eliminate all cross-connection effects.)
The Apache Solr project considers authentication and authorization a prerequisite for any
production-secure deployment and explicitly warns against relying on network-perimeter controls as the
sole access mechanism. A deployment without Solr auth that relies on a proxy's URI rules as its only
security boundary is therefore outside the project's supported production configuration.
Solr has bundled a Jetty version in an affected branch (≥ 9.4.0) since Solr 7.3.0 — Jetty 9.4.x
through Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (below the fixed
12.0.31) — so scanners flag this CVE across Solr 7.3.0 – 10.0.0. As explained above, Solr is not
affected in a supported (authenticated) configuration throughout that range.
References
Description
CVE-2026-42440 (CVSS 7.5) is an out-of-memory denial-of-service issue in Apache OpenNLP's binary
model reader. The AbstractModelReader methods getOutcomes(), getOutcomePatterns() and
getPredicates() read a 32-bit signed integer count field from a binary model stream and pass it
directly to an array allocation without validating it. An attacker who can supply a crafted .bin
model file with a count set to Integer.MAX_VALUE triggers an immediate OutOfMemoryError during
model deserialization, before any substantial data is consumed.
The vulnerable code is present in the opennlp-tools-1.9.4.jar that Solr pulls in transitively via
lucene-analysis-opennlp (Lucene 9.12.3). The issue is fixed upstream in OpenNLP 2.5.9 (and
3.0.0-M3), and backported to the end-of-life 1.9.x line as opennlp-tools-1.9.5; all of these
validate the count against an upper bound (default 10,000,000, configurable via the
OPENNLP_MAX_ENTRIES system property) before allocating.
When Solr is exposed
OpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed
modules are enabled. The vulnerable model-loading code path becomes reachable when:
- The
analysis-extras and/or langid modules are enabled — they are not loaded by default.
- OpenNLP analysis components or update processors are configured to load OpenNLP model files (the
schema-configured OpenNLP analyzers — tokenizer, POS, chunker, lemmatizer, name-finder — or the
langid / analysis-extras update processors).
Any deployment that enables these modules and loads an OpenNLP model an attacker can influence is
exploitable. A deployment that does not enable them never deserializes an OpenNLP model and is not
exposed.
Mitigation
The most reliable mitigation is to not enable the OpenNLP-backed analysis-extras or langid
modules unless they are required. If you do use OpenNLP, load model files only from locations you
fully control and never from untrusted or user-supplied sources.
This flaw is present in every OpenNLP release before 2.5.9. Solr has bundled OpenNLP (transitively,
via lucene-analysis-opennlp) since Solr 7.3.0, so every release from 7.3.0 through 10.0.0 ships an
affected version (1.8.3 through 2.5.6). The affected range is therefore 7.3.0 – 10.0.0.
Fixed in Solr 9.11, which bundles the patched opennlp-tools 1.9.5, and in Solr 10.1, which upgrades
the bundled OpenNLP (via lucene-analysis-opennlp) to 2.5.9. Solr 10.0 remains affected (it ships
OpenNLP 2.5.6).
References
Description
CVE-2026-42027 (CVSS 9.8) is an arbitrary class instantiation issue in Apache OpenNLP's
ExtensionLoader. The instantiateExtension(Class, String) method loads a class named in a
model archive's manifest.properties via Class.forName() and only performs its
isAssignableFrom type check after the class has been loaded. Because Class.forName()
runs the target class's static initializer at load time, an attacker who can supply a crafted
model archive can trigger the static initializer of any class on the classpath (e.g. one that
performs a JNDI lookup, outbound network I/O, or filesystem access), regardless of the
type check that follows.
The vulnerable code is present in the opennlp-tools-1.9.4.jar that Solr pulls in transitively
via lucene-analysis-opennlp (Lucene 9.12.3). There is a opennlp-tools-1.9.5 release happening, but it hasn't finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9 (and 3.0.0-M3), which consults a
package-prefix allowlist before calling Class.forName().
When Solr is exposed
OpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed
modules are enabled. The vulnerable code path becomes reachable when:
- The
analysis-extras and/or langid modules are enabled — they are not loaded by default.
- OpenNLP analysis components or update processors are configured to load model files.
Any deployment that enables these modules and loads an OpenNLP model an attacker can influence is
exploitable. A deployment that does not enable them never invokes ExtensionLoader and is not
exposed.
Mitigation
The most reliable mitigation is to not enable the OpenNLP-backed analysis-extras or langid
modules unless they are required. If you do use OpenNLP, load model files only from locations you
fully control and never from untrusted or user-supplied sources.
In Solr 9.11.0 the upstream allowlist defense is backfilled at the application layer, since the
vulnerable jar cannot yet be upgraded (Solr must track the OpenNLP version used by
lucene-analysis-opennlp). Every OpenNLP model is loaded as a resource through Solr's resource
loaders, so the archive is validated at that single chokepoint before OpenNLP is allowed to
deserialize it:
- The archive is opened as a ZIP and every class name it declares — the
manifest.properties
factory entry and any class referenced from embedded feature-generator XML descriptors — must
resolve under the opennlp. package prefix.
- A model that names a class outside that prefix is rejected and never reaches
ExtensionLoader,
so no attacker-controlled static initializer can run.
- Validation covers both standalone (filesystem configset) and SolrCloud (ZooKeeper) deployments,
and applies whether the model is loaded by the
langid / analysis-extras update processors or
by the schema-configured OpenNLP analyzers (tokenizer, POS, chunker, lemmatizer, name-finder).
Solr's own usage only ever references built-in opennlp.* factories, so legitimate models load
unchanged; only crafted models that try to instantiate arbitrary classes are blocked.
This flaw is present in every OpenNLP release before 2.5.9 (fixed in 2.5.9 / 3.0.0-M3, backported to
1.9.5). Solr has bundled OpenNLP (transitively, via lucene-analysis-opennlp) since Solr 7.3.0, so
every release from 7.3.0 through 10.0.0 ships an affected version (1.8.3 through 2.5.6). The affected
range is therefore 7.3.0 – 10.0.0.
Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via lucene-analysis-opennlp) to 2.5.9.
References
Description
CVE-2026-40682 (CVSS 9.1) is an XML External Entity (XXE) vulnerability in Apache OpenNLP's
dictionary parsing. The DictionaryEntryPersistor class and the public Dictionary(InputStream)
constructor create a SAX parser without enabling FEATURE_SECURE_PROCESSING or disabling DTD
processing, so external entity resolution and DOCTYPE declarations remain fully enabled. An attacker
who can supply a crafted dictionary file — either directly or embedded in a model archive that
OpenNLP deserializes — can therefore read local files from the server or trigger outbound requests
(server-side request forgery). Other OpenNLP XML parsing paths route through the hardened
XmlUtil.createSaxParser() helper, but this code path does not.
The vulnerable code is present in the opennlp-tools-1.9.4.jar that Solr pulls in transitively via
lucene-analysis-opennlp (Lucene 9.12.3). There is a opennlp-tools-1.9.5 release happening, but it hasn't finished or been integrated into Solr 9; the issue is fixed in OpenNLP 2.5.9 (and 3.0.0-M3), which parse dictionaries with secure
XML processing that rejects DOCTYPE declarations and external entities.
When Solr is exposed
OpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed
modules are enabled. The vulnerable dictionary-parsing code path becomes reachable when:
- The
analysis-extras and/or langid modules are enabled — they are not loaded by default.
- OpenNLP analysis components or update processors are configured to load OpenNLP model or
dictionary files (the schema-configured OpenNLP analyzers — tokenizer, POS, chunker, lemmatizer,
name-finder — or the
langid / analysis-extras update processors).
Any deployment that enables these modules and parses an OpenNLP model or dictionary an attacker can
influence is exploitable. A deployment that does not enable them never parses an OpenNLP dictionary
and is not exposed.
Mitigation
The most reliable mitigation is to not enable the OpenNLP-backed analysis-extras or langid
modules unless they are required. If you do use OpenNLP, load model and dictionary files only from
locations you fully control, since the bundled OpenNLP 1.9.4 does not disable external entities when
parsing dictionaries.
Every OpenNLP model and dictionary is loaded as a resource through Solr's resource loaders, so the
archive passes through a single chokepoint before OpenNLP is allowed to deserialize it. This applies
to both standalone (filesystem configset) and SolrCloud (ZooKeeper) deployments, and whether the
dictionary is loaded by the langid / analysis-extras update processors or by the
schema-configured OpenNLP analyzers.
This flaw is present in every OpenNLP release before 2.5.9 (fixed in 2.5.9 / 3.0.0-M3, backported to
1.9.5). Solr has bundled OpenNLP (transitively, via lucene-analysis-opennlp) since Solr 7.3.0, so
every release from 7.3.0 through 10.0.0 ships an affected version (1.8.3 through 2.5.6). The affected
range is therefore 7.3.0 – 10.0.0.
Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via lucene-analysis-opennlp) to 2.5.9.
References
Description
CVE-2026-34481 is not considered exploitable in any deployment of the Apache Solr binary distribution.
Successful exploitation requires the application to log a MapMessage (or one of its subclasses)
carrying a non-finite floating-point value (NaN, Infinity or -Infinity) through JsonTemplateLayout,
which the layout then serializes as invalid JSON, in breach of RFC 8259.
Producing a MapMessage requires application code, and users of the binary distribution run only the code shipped by Apache Solr.
A scan of the bytecode of all JAR files in the distribution confirms that the MapMessage family
(MapMessage, StringMapMessage and StructuredDataMessage)
is referenced only inside Log4j's own JARs.
Neither Solr nor any of its bundled dependencies ever constructs or logs such a message.
Because no shipped code can hand a triggering value to the layout,
the vulnerable code path cannot be reached regardless of the configured layout,
and the Solr community considers this vulnerability non-exploitable in the binary distribution.
References
Description
CVE-2026-34480 is not considered exploitable in typical deployments of Apache Solr.
Successful exploitation requires a specific, non-default logging configuration.
The following conditions must all be met:
- The Log4j configuration is modified to write events through
XmlLayout.
- A log message or MDC value contains characters forbidden by the XML 1.0 specification.
When triggered, the layout produces malformed XML, which downstream log processors may reject:
silently with the JRE built-in StAX, or by dropping the event with alternative implementations such as Woodstox.
None of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution reference XmlLayout.
They only use PatternLayout, so the vulnerable code path is never reached.
The MDC values that Solr populates (collection, shard, replica, core and node names, plus a trace id) are not emitted as XML either.
A configuration that does meet the conditions above looks like this:
<Appenders>
<RollingFile name="xml" fileName="${sys:solr.log.dir}/solr-events.xml"
filePattern="${sys:solr.log.dir}/solr-events.xml.%i">
<XmlLayout/>
</RollingFile>
</Appenders>
Operators who do configure XmlLayout should replace the vulnerable JAR file
(server/lib/ext/log4j-core-2.25.3.jar)
with log4j-core-2.25.4.jar.
References
Description
CVE-2026-34479 is not considered exploitable in typical deployments of Apache Solr.
Successful exploitation requires a specific, non-default logging configuration.
The following conditions must all be met:
- The Log4j 1-to-Log4j 2 bridge emits logs through
Log4j1XmlLayout,
either configured directly in a Log4j 2 configuration
or selected as org.apache.log4j.xml.XMLLayout through the Log4j 1 compatibility layer.
- The logged data contains characters forbidden by the XML 1.0 specification.
The log4j-1.2-api JAR is shipped so that third-party libraries that still call the Log4j 1 API keep working.
However, Solr is configured through Log4j 2 configuration files that only use PatternLayout,
and the distribution ships no Log4j 1 (log4j.properties or log4j.xml) configuration file,
so the vulnerable layout is never instantiated.
A configuration that does meet the conditions above looks like this:
<Appenders>
<File name="xml" fileName="${sys:solr.log.dir}/solr-events.xml">
<Log4j1XmlLayout/>
</File>
</Appenders>
Operators who use legacy Log4j 1 configuration files or Log4j1XmlLayout should replace the vulnerable JAR file
(server/lib/ext/log4j-1.2-api-2.25.3.jar)
with log4j-1.2-api-2.25.4.jar.
Support for Log4j1XmlLayout and legacy Log4j 1 configuration files may be removed in a future Solr release,
so migrating to a native Log4j 2 configuration is recommended.
References
Description
CVE-2026-34478 is not considered exploitable in typical deployments of Apache Solr.
Successful exploitation requires a specific, non-default logging configuration.
The following conditions must all be met:
- The Log4j configuration is modified to send logs to a stream-based (TCP or TLS) syslog service using
Rfc5424Layout directly.
- An attacker is able to inject CRLF sequences into the logged data.
Because the newLineEscape and useTlsMessageFormat attributes were silently renamed in Log4j Core 2.21.0,
newline escaping stopped working and TLS framing was downgraded to plain TCP,
leaving such configurations exposed to CRLF log injection.
None of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution reference Rfc5424Layout.
They only use PatternLayout, so the issue cannot be triggered.
Users of the Syslog appender are not affected either, since its attributes were not renamed.
A configuration that does meet the conditions above looks like this:
<Appenders>
<Socket name="syslog" host="logs.example.com" port="601" protocol="TCP">
<Rfc5424Layout appName="Solr" newLineEscape="\\n"/>
</Socket>
</Appenders>
Operators who do configure Rfc5424Layout should either:
- replace
newLineEscape with escapeNL and useTlsMessageFormat with useTLSMessageFormat
(note the capitalization), or
- replace the vulnerable JAR file
(
server/lib/ext/log4j-core-2.25.3.jar)
with log4j-core-2.25.4.jar.
References
Description
CVE-2026-34477 is not considered exploitable in typical deployments of Apache Solr.
Successful exploitation requires a specific, non-default logging configuration together with a privileged network position.
The following conditions must all be met:
- The Log4j configuration is modified to add an
SMTP, Socket or Syslog appender that ships logs over TLS through a nested <Ssl> element.
- That appender relies on the
verifyHostName attribute to authenticate the remote receiver, which was silently ignored through Log4j Core 2.25.3.
- A man-in-the-middle attacker can intercept the connection and present a certificate issued by a CA trusted by the configured (or default) trust store.
None of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution define such an appender.
They only use Console and RollingRandomAccessFile appenders, which open no network connection,
so no TLS hostname verification ever takes place.
The HTTP appender is not affected either, as it uses a separate verifyHostname attribute that verifies host names by default.
A configuration that does meet the conditions above looks like this:
<Appenders>
<Socket name="remote" host="logs.example.com" port="6514">
<!-- verifyHostName="true" was silently ignored through 2.25.3 -->
<Ssl verifyHostName="true">
<KeyStore location="..." password="..."/>
<TrustStore location="..." password="..."/>
</Ssl>
<PatternLayout pattern="%m%n"/>
</Socket>
</Appenders>
Operators who do configure TLS network appenders should replace the vulnerable JAR file
(server/lib/ext/log4j-core-2.25.3.jar)
with log4j-core-2.25.4.jar.
References
Description
CVE-2025-48924 is an uncontrolled-recursion issue in Apache Commons Lang's
ClassUtils.getClass(...): a very long, deeply-nested class name can exhaust the stack and
throw StackOverflowError. It affects commons-lang3 from 3.0 up to (but not including) 3.18.0,
so dependency scanners flag the commons-lang3 JAR bundled in Solr 9.x (which ships versions
3.12.0 through 3.15.0 across the 9.0–9.9 line).
Solr is not affected. The vulnerable ClassUtils.getClass(...) code path is only reachable via
commons-configuration2, which Solr uses solely in its Hadoop Kerberos support
(solr-hadoop-auth) to load administrator-provided Hadoop configuration files. Class names are not
attacker-controlled in that path, so the recursion cannot be driven by an adversary and the
vulnerability is not exploitable in Solr.
References
Description
When parsing unknown fields in the Protobuf Java Lite and Full library, a maliciously crafted message can cause a StackOverflow error and lead to a program crash.
CVE-2024-7254 affects all protobuf-java releases before 3.25.5 (per the upstream advisory the
flaw was introduced at version 0, and is fixed in 3.25.5 / 4.27.5 / 4.28.2). Apache Solr has bundled
protobuf-java (transitively, via Hadoop and ZooKeeper) since Solr 4.4.0 (which shipped 2.4.0a),
and every release from 4.4.0 through 9.9.0 ships an affected version (2.4.0a through 3.25.3). Solr
9.10.0 was the first release to ship a fixed protobuf-java (3.25.8), so the affected range is
4.4.0 – 9.9.0.
References
Description
CVE-2024-51504 is not considered exploitable in typical production deployments of Apache Solr.
Successful exploitation requires a very specific and non-standard configuration.
The following conditions must all be met:
- Solr must be deployed in SolrCloud mode, which relies on ZooKeeper for coordination.
- The embedded ZooKeeper server must be in use: a setup that is explicitly discouraged for production.
Solr emits a warning when this configuration is detected, and it is not commonly used outside of development or experimentation.
- The ZooKeeper Admin Server must be manually enabled in the ZooKeeper configuration file (
server/solr/zoo.cfg).
By default, this feature is disabled:
# Disable ZK AdminServer since we do not use it
admin.enableServer=false
Because these conditions are highly unlikely in secure, production-grade environments,
the Solr community considers this vulnerability non-exploitable under standard operating conditions.
References
Description
CVE-2024-6763 is an improper-input-validation issue in Eclipse Jetty's HttpURI parser, affecting
Jetty from 7.0.0 up to (but not including) 12.0.12 (fixed in 12.0.12, with a 9.4.57 backport on the
still-supported 9.4.x branch). Solr bundles Jetty as its HTTP server, so scanners flag this CVE on
every Solr release whose Jetty predates 12.0.12 — Jetty 8.1.x/9.4.x/10.0.x from Solr 4.0.0 through
Solr 9.10.1. Solr 10.0.0 ships Jetty 12.0.27 (≥ 12.0.12) and is not affected. The affected range is
therefore 4.0.0 – 9.10.1.
Solr is not affected: it does not use the Jetty "HttpURI" utility class necessary for the vulnerability.
References
Description
Core creation allows users to replace "trusted" configset files with arbitrary configuration
Solr instances are vulnerable if they:
- use the
FileSystemConfigSetService component (the default in "standalone" or "user-managed" mode), and
- run without authentication and authorization enabled
In this configuration, attackers can exploit a privilege escalation issue by replacing individual "trusted" configset files with potentially untrusted files from elsewhere on the filesystem.
These replacements are incorrectly treated as "trusted" and can leverage <lib> tags to add arbitrary code to Solr's classpath, potentially allowing malicious plugins or components to be loaded.
This issue affects all Apache Solr versions up through Solr 9.7. The vulnerable behavior lives in
the filesystem-backed config-set service used in standalone / user-managed mode — named
FileSystemConfigSetService since Solr 9.0.0 (SOLR-15258), but present as its functional predecessor
ConfigSetService.Standalone all the way back to Solr 4.8.0 (SOLR-4478). The affected range is
therefore 4.8.0 – 9.7.0; Solr 9.8.0 mitigates it by disabling <lib> tags by default.
Mitigation
Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from "FileSystemConfigSetService").
Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of "" tags by default.
Credit
pwn null (reporter)
References
Description
The only places we use json-path is for querying (via Calcite) and for transforming/indexing custom JSON. Since the advisory describes a problem that is limited to the current thread, and users that are allowed to query/transform/index are already trusted to cause load to some extent, this advisory does not appear to have impact on the way json-path is used in Solr.
CVE-2023-51074 affects json-path 2.2.0 through 2.8.0 (fixed in 2.9.0). Solr first bundled json-path
in Solr 8.1.0 (2.4.0) and shipped an affected version — 2.4.0, then 2.7.0, then 2.8.0 — through Solr
9.5.0; Solr 9.6.0 upgraded to the fixed 2.9.0. The affected range is therefore 8.1.0 – 9.5.0.
References
Description
CVE-2022-42889 ("Text4Shell") is a code-execution issue in Apache Commons Text: from version 1.5
through 1.9, the default StringSubstitutor interpolators included script, dns and url
lookups that could execute arbitrary code (fixed in 1.10.0). Solr bundled an affected commons-text
in 8.1.0 (1.6) through 9.0.0 (1.8); Solr 8.0.0 shipped 1.4 (before the flaw was introduced) and Solr
9.1.0 upgraded to the fixed 1.10.0. The affected range is therefore 8.1.0 – 9.0.0.
Solr uses commons-text directly (StringEscapeUtils.escapeEcmaScript) in LoadAdminUiServlet that is not vulnerable. Solr also has a "hadoop-auth" module that uses Apache Hadoop which uses commons-text through commons-configuration2. For Solr, the concern is limited to loading Hadoop configuration files that would only ever be provided by trusted administrators, not externally (untrusted).
References
Description
Apache Calcite has a vulnerability, CVE-2022-39135, that is exploitable in Apache Solr in SolrCloud mode. If an untrusted user can supply SQL queries to Solr's '/sql' handler (even indirectly via proxies / other apps), then the user could perform an XML External Entity (XXE) attack. This might have been exposed by some deployers of Solr in order for internal analysts to use JDBC based tooling, but would have unlikely been granted to wider audiences.
References
Description
CVE-2022-33980 is a code-execution issue in Apache Commons Configuration: versions 2.4 through 2.7
performed variable interpolation with script, dns and url lookups enabled by default (fixed in
2.8.0). Only Solr 9.0.0 shipped an affected version (commons-configuration2 2.7); Solr 8.x shipped
2.1.1 (before the flaw was introduced) and Solr 9.1.0 upgraded to the fixed 2.8.0. The affected
version is therefore 9.0.0 only.
Solr uses commons-configuration2 for "hadoop-auth" only (for Kerberos). It is only used for loading Hadoop configuration files that would only ever be provided by trusted administrators, not externally (untrusted).
References
Description
CVE-2022-25168 is a command-injection flaw in Apache Hadoop's FileUtil.unTar(...), which fails to
escape the input filename before passing it to a shell. It affects hadoop-common 2.0.0–2.10.1,
3.0.0-alpha–3.2.3 and 3.3.0–3.3.2 (fixed in 2.10.2, 3.2.4 and 3.3.3). Solr has bundled an affected
hadoop-common (transitively, for HDFS support) since Solr 4.4.0, through Solr 9.0.0 (which ships
3.3.2); Solr 9.1.0 upgraded to the fixed 3.3.4. The affected range is therefore 4.4.0 – 9.0.0.
The vulnerable code won't be used by Solr because Solr only is only using HDFS as a client.
References
Description
The MDC data used by Solr are for the collection, shard, replica, core and node names, and a potential trace id, which are all sanitized. Furthermore, Solr's default log configuration doesn't use double-dollar-sign and we don't imagine a user would want to do that.
References
Description
Solr's default log configuration doesn't use JDBCAppender and we don't imagine a user would want to use it or other obscure appenders.
References
Description
CVE-2021-33813 is an XML external entity (XXE) issue in JDOM's SAXBuilder, affecting all JDOM
releases up to and including 2.0.6 (fixed in 2.0.6.1). Solr has bundled JDOM (transitively, via
Apache Tika / Solr Cell) since Solr 3.6.0 — jdom 1.0, then jdom 2.0.2, then jdom2 2.0.6 —
through the last 8.x release; Solr 9.0.0 upgraded to the fixed jdom2 2.0.6.1. The affected range is
therefore 3.6.0 – 8.8.1.
JDOM is only used in Solr Cell, which should not be used in production which makes the vulnerability unexploitable. It is a dependency of Apache Tika, which has analyzed the issue and determined the vulnerability is limited to two libraries not commonly used in search applications, see TIKA-3488 for details. Since Tika should be used outside of Solr, use a version of Tika which updates the affected libraries if concerned about exposure to this issue.
References
Description
Only exploitable if Solr's webapp directory is deployed as a symlink, which is not Solr's default.
References
Description
Only exploitable through use of Jetty's GzipHandler, which is only implemented in Embedded Solr Server.
References
Description
Solr's SQL adapter does not use the vulnerable class "HttpUtils". Calcite only used it to talk to Druid or Splunk.
References
Description
This is not included in Solr but is a dependency of ZooKeeper 3.5.5. The version was upgraded in ZooKeeper 3.5.6, included with Solr 8.3. The specific classes mentioned in the CVE are not used in Solr (nor in ZooKeeper as far as the Solr community can determine).
References
Description
Solr upgraded to Jetty 9.4.19 for the 8.2 release. Additionally, the path to exploit these vulnerabilities was fixed in 8.1 and 7.7.2. Earlier versions can manually patch their configurations as described in SOLR-13409.
References
Description
While commons-beanutils was removed in 7.5, it was added back in 8.0 in error and removed again in 8.3. The vulnerable class was not used in any Solr code path. This jar remains a dependency of both Velocity and hadoop-common, but Solr does not use it in our implementations.
References
Description
The reported CVE impacts org.slf4j.ext.EventData, which is not used in Solr.
References
Description
Dependency of Carrot2 and used during compilation, not at runtime (see SOLR-769. This .jar was replaced in Solr 8.3 and backported to 7.7.3 (see SOLR-13779).
References
Description
Solr does not run tika-server, so this is not a problem.
References
Description
Only used with the Carrot2 clustering engine.
References
Description
Only used in tests.
References
Description
Only used in Solr tests.
References
Description
JUnit only used in tests; CVE only refers to a Jenkins plugin not used by Solr.
References
Description
Does not impact Solr because Solr uses Hadoop as a client library.
References
Description
These CVEs, and most of the known jackson-databind CVEs since 2017, are all related to problematic 'gadgets' that could be exploited during deserialization of untrusted data. The Jackson developers described 4 conditions that must be met in order for a problematic gadget to be exploited. See https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062. Solr's use of jackson-databind does not meet 1 of the 4 conditions described which makes these CVEs unexploitable. The specific condition that Solr does not meet is the 3rd one: 'Enable polymorphic type handling' Solr does not include any polymorphic type handling, and Solr does not configure jackson-databind de/serialization to expect or include class names in serialized JSON. Two CVEs, 2019-14540 & 2019-16335, are related to HikariConfig and HikariDataSource classes, neither of which are used in Solr's code base.
References
- CVE: CVE-2017-15095, CVE-2017-17485, CVE-2017-7525, CVE-2018-5968, CVE-2018-7489, CVE-2019-12086, CVE-2019-12384, CVE-2018-12814, CVE-2019-14379, CVE-2019-14439, CVE-2020-35490, CVE-2020-35491, CVE-2021-20190, CVE-2019-14540, CVE-2019-16335
Description
Issue applies only to the C++ release of ICU and not ICU4J, which is what Lucene uses. ICU4J is at v63.2 as of Lucene/Solr 7.6.0
References
Description
Solr should not be exposed outside a firewall where bad actors can send HTTP requests. These two CVEs specifically involve classes (SimpleXMLProvider and XmlRepresentation, respectively) that Solr does not use in any code path.
References
Description
See https://github.com/Gagravarr/VorbisJava/issues/30; reported CVEs are not related to OggVorbis at all.
Tika as an in-process component was removed in Solr 9.11.
References
Description
Scanners flag velocity-tools-2.0.jar with Apache Struts 1 CVEs because its POM declares a
transitive dependency on struts-core, struts-taglib and struts-tiles 1.3.8. Solr does not
ship any Struts jar — the dependency is excluded and only appears as a transitive POM listing
(see SOLR-2849) — so these Struts vulnerabilities are not present in, or exploitable through, Solr.
References
Description
Dependency for Hadoop and Calcite. ??
References
Description
All of these issues apply to the C++ release of ICU and not ICU4J, which is what Lucene uses.
References
Description
This is only used at compile time and it cannot be used to attack Solr. Since it is generally unnecessary, the dependency has been removed as of 7.5.0. See SOLR-12617.
References
Description
Only used in test framework and at build time.
References
Description
Only used in Lucene Benchmarks and Solr tests.
References