Apache Solr VEX
← Back to the dependency CVE table
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). 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 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.
Fully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via lucene-analysis-opennlp) to 2.5.9.
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.
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.
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
The vulnerable functionality is only reachable via commons-configuration2, which is used in Solr's Hadoop Kerberos support (solr-hadoop-auth) to load administrator-provided Hadoop configuration files. As such, 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.
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
Solr 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.
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.
Regardless, Solr upgraded the bundled json-path to 2.9.0 — which fixes CVE-2023-51074 — in Solr 9.6.0, so the vulnerable json-path (≤ 2.8.0) only shipped through Solr 9.5.
References
Description
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
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
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
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