{ "@context": "https://openvex.dev/ns/v0.2.0", "@id": "https://solr.apache.org/solr.openvex.json", "author": "Apache Solr Project (security@apache.org)", "timestamp": "2026-07-18T00:00:00Z", "version": 1, "statements": [ { "vulnerability": { "name": "CVE-2012-0881" }, "products": [ { "@id": "pkg:maven/xerces/xercesImpl@2.12.0" }, { "@id": "pkg:maven/xerces/xercesImpl@2.12.2" }, { "@id": "pkg:maven/xerces/xercesImpl@2.9.1" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only used in Lucene Benchmarks and Solr tests.", "status_notes": "Affected Apache Solr versions: 2.9-9.10." }, { "vulnerability": { "name": "CVE-2012-2098", "aliases": [ "CVE-2018-1324", "CVE-2018-11771" ] }, "products": [ { "@id": "commons-compress (only as part of Ant 1.8.2)" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only used in test framework and at build time.", "status_notes": "Affected Apache Solr versions: 4.6.0-7.x." }, { "vulnerability": { "name": "CVE-2014-0114" }, "products": [ { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.8.3" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 4.9.0-7.5.0." }, { "vulnerability": { "name": "CVE-2014-7940", "aliases": [ "CVE-2016-6293", "CVE-2016-7415", "CVE-2017-14952", "CVE-2017-17484", "CVE-2017-7867", "CVE-2017-7868" ] }, "products": [ { "@id": "pkg:maven/org.apache.lucene/lucene-analyzers-icu@7.3.1" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "All of these issues apply to the C++ release of ICU and not ICU4J, which is what Lucene uses.", "status_notes": "Affected Apache Solr versions: 7.3.1." }, { "vulnerability": { "name": "CVE-2015-5237" }, "products": [ { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.1.0" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Dependency for Hadoop and Calcite. ??", "status_notes": "Affected Apache Solr versions: 6.5.0-7.x." }, { "vulnerability": { "name": "CVE-2015-0899", "aliases": [ "CVE-2016-1181", "CVE-2016-1182" ] }, "products": [ { "@id": "pkg:maven/org.apache.velocity/velocity-tools@2.0" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Scanners flag `velocity-tools-2.0.jar` with Apache Struts 1 CVEs because its POM declares a\ntransitive dependency on `struts-core`, `struts-taglib` and `struts-tiles` 1.3.8. Solr does not\nship any Struts jar \u2014 the dependency is excluded and only appears as a transitive POM listing\n(see SOLR-2849) \u2014 so these Struts vulnerabilities are not present in, or exploitable through, Solr.", "status_notes": "Affected Apache Solr versions: 6.6.2-8.x." }, { "vulnerability": { "name": "CVE-2016-6809", "aliases": [ "CVE-2018-1335", "CVE-2018-1338", "CVE-2018-1339" ] }, "products": [ { "@id": "pkg:maven/org.gagravarr/vorbis-java-tika@0.6" }, { "@id": "pkg:maven/org.gagravarr/vorbis-java-tika@0.8" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "See https://github.com/Gagravarr/VorbisJava/issues/30; reported CVEs are not related to OggVorbis at all.\n\nTika as an in-process component was removed in Solr 9.11.", "status_notes": "Affected Apache Solr versions: 5.5.5, 6.2.0-9.10." }, { "vulnerability": { "name": "CVE-2017-14868", "aliases": [ "CVE-2017-14949" ] }, "products": [ { "@id": "pkg:maven/org.restlet.jee/org.restlet@2.3.0" }, { "@id": "pkg:maven/org.restlet.jee/org.restlet@2.4.0" }, { "@id": "pkg:maven/org.restlet.jee/org.restlet@2.4.3" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 5.2.0-8.x." }, { "vulnerability": { "name": "CVE-2017-14952" }, "products": [ { "@id": "pkg:maven/com.ibm.icu/icu4j@56.1" }, { "@id": "pkg:maven/com.ibm.icu/icu4j@59.1" }, { "@id": "pkg:maven/com.ibm.icu/icu4j@61.1" }, { "@id": "pkg:maven/com.ibm.icu/icu4j@62.1" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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", "status_notes": "Affected Apache Solr versions: 6.0.0-7.5.0." }, { "vulnerability": { "name": "CVE-2017-15095", "aliases": [ "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" ] }, "products": [ { "@id": "jackson-databind-*.jar" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.x." }, { "vulnerability": { "name": "CVE-2017-15718" }, "products": [ { "@id": "pkg:maven/org.apache.hadoop/hadoop-auth@2.7.4" }, { "@id": "hadoop-hdfs-2.7.4.jar (all Hadoop)" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Does not impact Solr because Solr uses Hadoop as a client library.", "status_notes": "Affected Apache Solr versions: 6.6.1-7.6.0." }, { "vulnerability": { "name": "CVE-2018-1000056" }, "products": [ { "@id": "pkg:maven/junit/junit@4.10" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "JUnit only used in tests; CVE only refers to a Jenkins plugin not used by Solr.", "status_notes": "Affected Apache Solr versions: 4.6.0-7.6.0." }, { "vulnerability": { "name": "CVE-2018-1000632" }, "products": [ { "@id": "pkg:maven/dom4j/dom4j@1.6.1" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only used in Solr tests.", "status_notes": "Affected Apache Solr versions: 4.6.0-8.x." }, { "vulnerability": { "name": "CVE-2018-10237" }, "products": [ { "@id": "guava-*.jar" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only used in tests.", "status_notes": "Affected Apache Solr versions: 4.6.0-8.x." }, { "vulnerability": { "name": "CVE-2018-10237" }, "products": [ { "@id": "pkg:maven/org.carrot2.shaded/carrot2-guava@18.0" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only used with the Carrot2 clustering engine.", "status_notes": "Affected Apache Solr versions: 5.4.0-8.x." }, { "vulnerability": { "name": "CVE-2018-1335" }, "products": [ { "@id": "pkg:maven/org.apache.tika/tika-core@1.17" }, { "@id": "pkg:maven/org.apache.tika/tika-core@1.18" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Solr does not run tika-server, so this is not a problem.", "status_notes": "Affected Apache Solr versions: 7.3.1-7.5.0." }, { "vulnerability": { "name": "CVE-2018-1471" }, "products": [ { "@id": "pkg:maven/org.simpleframework/simple-xml@2.7.1" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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).", "status_notes": "Affected Apache Solr versions: 5.4.0-7.7.2, 8.0-8.3." }, { "vulnerability": { "name": "CVE-2018-8088" }, "products": [ { "@id": "pkg:maven/org.slf4j/slf4j-api@1.6.4" }, { "@id": "pkg:maven/org.slf4j/slf4j-api@1.6.6" }, { "@id": "pkg:maven/org.slf4j/slf4j-api@1.7.24" }, { "@id": "pkg:maven/org.slf4j/slf4j-api@1.7.36" }, { "@id": "pkg:maven/org.slf4j/slf4j-api@1.7.6" }, { "@id": "pkg:maven/org.slf4j/slf4j-api@1.7.7" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.6.4" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.6.6" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.7.24" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.7.36" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.7.6" }, { "@id": "pkg:maven/org.slf4j/jcl-over-slf4j@1.7.7" }, { "@id": "pkg:maven/org.slf4j/jul-to-slf4j@1.6.6" }, { "@id": "pkg:maven/org.slf4j/jul-to-slf4j@1.7.24" }, { "@id": "pkg:maven/org.slf4j/jul-to-slf4j@1.7.36" }, { "@id": "pkg:maven/org.slf4j/jul-to-slf4j@1.7.6" }, { "@id": "pkg:maven/org.slf4j/jul-to-slf4j@1.7.7" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "The reported CVE impacts org.slf4j.ext.EventData, which is not used in Solr.", "status_notes": "Affected Apache Solr versions: 4.x-9.1." }, { "vulnerability": { "name": "CVE-2019-10086" }, "products": [ { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.9.3" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 8.0.0-8.3.0." }, { "vulnerability": { "name": "CVE-2019-10241", "aliases": [ "CVE-2019-10247" ] }, "products": [ { "@id": "jetty-9.4.14" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 7.7.0-8.2." }, { "vulnerability": { "name": "CVE-2019-16869" }, "products": [ { "@id": "pkg:maven/io.netty/netty-all@4.0.52.Final" }, { "@id": "pkg:maven/io.netty/netty-all@4.1.29.Final" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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).", "status_notes": "Affected Apache Solr versions: 8.2-8.3." }, { "vulnerability": { "name": "CVE-2020-13955" }, "products": [ { "@id": "pkg:maven/org.apache.calcite.avatica/avatica-core@1.13.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.18.0" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Solr's SQL adapter does not use the vulnerable class \"HttpUtils\". Calcite only used it to talk to Druid or Splunk.", "status_notes": "Affected Apache Solr versions: 8.1.0-8.x." }, { "vulnerability": { "name": "CVE-2020-27218" }, "products": [ { "@id": "jetty-9.4.0 to 9.4.34" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only exploitable through use of Jetty's GzipHandler, which is only implemented in Embedded Solr Server.", "status_notes": "Affected Apache Solr versions: 7.3.0-8.8.0." }, { "vulnerability": { "name": "CVE-2020-27223" }, "products": [ { "@id": "jetty-9.4.6 to 9.4.36" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "Only exploitable if Solr's webapp directory is deployed as a symlink, which is not Solr's default.", "status_notes": "Affected Apache Solr versions: 7.3.0-8.x." }, { "vulnerability": { "name": "CVE-2021-33813" }, "products": [ { "@id": "pkg:maven/org.jdom/jdom@1.0" }, { "@id": "pkg:maven/org.jdom/jdom@2.0.2" }, { "@id": "pkg:maven/org.jdom/jdom2@2.0.6" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "CVE-2021-33813 is an XML external entity (XXE) issue in JDOM's `SAXBuilder`, affecting all JDOM\nreleases up to and including 2.0.6 (fixed in 2.0.6.1). Solr has bundled JDOM (transitively, via\nApache Tika / Solr Cell) since Solr 3.6.0 \u2014 `jdom` 1.0, then `jdom` 2.0.2, then `jdom2` 2.0.6 \u2014\nthrough the last 8.x release; Solr 9.0.0 upgraded to the fixed `jdom2` 2.0.6.1. The affected range is\ntherefore 3.6.0 \u2013 8.8.1.\n\nJDOM 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.", "status_notes": "Affected Apache Solr versions: 3.6.0-8.8.1." }, { "vulnerability": { "name": "CVE-2021-44832" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.11.0" }, { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.11.2" }, { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.13.2" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 7.4-8.11.1." }, { "vulnerability": { "name": "CVE-2021-45105", "aliases": [ "CVE-2021-45046" ] }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.11.0" }, { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.11.2" }, { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.13.2" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "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.", "status_notes": "Affected Apache Solr versions: 7.4-8.11.1." }, { "vulnerability": { "name": "CVE-2022-25168" }, "products": [ { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.0.5-alpha" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.2.0" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.3.0" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.6.0" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.7.2" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@2.7.4" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@3.2.0" }, { "@id": "pkg:maven/org.apache.hadoop/hadoop-common@3.3.2" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "CVE-2022-25168 is a command-injection flaw in Apache Hadoop's `FileUtil.unTar(...)`, which fails to\nescape the input filename before passing it to a shell. It affects `hadoop-common` 2.0.0\u20132.10.1,\n3.0.0-alpha\u20133.2.3 and 3.3.0\u20133.3.2 (fixed in 2.10.2, 3.2.4 and 3.3.3). Solr has bundled an affected\n`hadoop-common` (transitively, for HDFS support) since Solr 4.4.0, through Solr 9.0.0 (which ships\n3.3.2); Solr 9.1.0 upgraded to the fixed 3.3.4. The affected range is therefore 4.4.0 \u2013 9.0.0.\n\nThe vulnerable code won't be used by Solr because Solr only is only using HDFS as a client.", "status_notes": "Affected Apache Solr versions: 4.4.0-9.0.0." }, { "vulnerability": { "name": "CVE-2022-33980" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.7" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "CVE-2022-33980 is a code-execution issue in Apache Commons Configuration: versions 2.4 through 2.7\nperformed variable interpolation with `script`, `dns` and `url` lookups enabled by default (fixed in\n2.8.0). Only Solr 9.0.0 shipped an affected version (`commons-configuration2` 2.7); Solr 8.x shipped\n2.1.1 (before the flaw was introduced) and Solr 9.1.0 upgraded to the fixed 2.8.0. The affected\nversion is therefore 9.0.0 only.\n\nSolr 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).", "status_notes": "Affected Apache Solr versions: 9.0.0." }, { "vulnerability": { "name": "CVE-2022-39135" }, "products": [ { "@id": "pkg:maven/org.apache.calcite/calcite@1.31.0" } ], "status": "affected", "timestamp": "2022-12-14T00:00:00Z", "action_statement": "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.", "status_notes": "Affected Apache Solr versions: 6.5-8.11.2, 9.0." }, { "vulnerability": { "name": "CVE-2022-42889" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-text@1.6" }, { "@id": "pkg:maven/org.apache.commons/commons-text@1.8" } ], "status": "not_affected", "timestamp": "2022-12-14T00:00:00Z", "impact_statement": "CVE-2022-42889 (\"Text4Shell\") is a code-execution issue in Apache Commons Text: from version 1.5\nthrough 1.9, the default `StringSubstitutor` interpolators included `script`, `dns` and `url`\nlookups that could execute arbitrary code (fixed in 1.10.0). Solr bundled an affected `commons-text`\nin 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\n9.1.0 upgraded to the fixed 1.10.0. The affected range is therefore 8.1.0 \u2013 9.0.0.\n\nSolr 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).", "status_notes": "Affected Apache Solr versions: 8.1.0-9.0.0." }, { "vulnerability": { "name": "CVE-2023-51074", "aliases": [ "GHSA-pfh2-hfmq-phg5" ] }, "products": [ { "@id": "pkg:maven/com.jayway.jsonpath/json-path@2.4.0" }, { "@id": "pkg:maven/com.jayway.jsonpath/json-path@2.7.0" }, { "@id": "pkg:maven/com.jayway.jsonpath/json-path@2.8.0" } ], "status": "not_affected", "timestamp": "2024-01-12T00:00:00Z", "impact_statement": "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.\n\nCVE-2023-51074 affects json-path 2.2.0 through 2.8.0 (fixed in 2.9.0). Solr first bundled json-path\nin Solr 8.1.0 (2.4.0) and shipped an affected version \u2014 2.4.0, then 2.7.0, then 2.8.0 \u2014 through Solr\n9.5.0; Solr 9.6.0 upgraded to the fixed 2.9.0. The affected range is therefore 8.1.0 \u2013 9.5.0.", "status_notes": "Affected Apache Solr versions: 8.1.0-9.5.0." }, { "vulnerability": { "name": "CVE-2025-24814" }, "products": [ { "@id": "pkg:maven/org.apache.solr/solr-core@4.8.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.8.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.9.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.9.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.10.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.10.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.10.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.10.3" }, { "@id": "pkg:maven/org.apache.solr/solr-core@4.10.4" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.0.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.1.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.2.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.2.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.3.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.3.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.3.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.4.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.4.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.3" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.4" }, { "@id": "pkg:maven/org.apache.solr/solr-core@5.5.5" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.0.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.0.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.1.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.2.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.2.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.3.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.4.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.4.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.4.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.5.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.5.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.3" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.4" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.5" }, { "@id": "pkg:maven/org.apache.solr/solr-core@6.6.6" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.0.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.0.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.1.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.2.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.2.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.3.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.3.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.4.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.5.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.6.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.7.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.7.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.7.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@7.7.3" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.0.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.1.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.1.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.2.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.3.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.3.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.4.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.4.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.5.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.5.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.5.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.6.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.6.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.6.2" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.6.3" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.7.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.8.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@8.8.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.0.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.1.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.1.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.2.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.2.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.3.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.4.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.4.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.5.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.6.0" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.6.1" }, { "@id": "pkg:maven/org.apache.solr/solr-core@9.7.0" } ], "status": "affected", "timestamp": "2025-01-26T00:00:00Z", "action_statement": "Core creation allows users to replace \"trusted\" configset files with arbitrary configuration\n\nSolr instances are vulnerable if they:\n\n1. use the `FileSystemConfigSetService` component (the default in \"standalone\" or \"user-managed\" mode), and\n2. run without authentication and authorization enabled\n\nIn this configuration, attackers can exploit a privilege escalation issue by replacing individual \"trusted\" configset files with potentially untrusted files from elsewhere on the filesystem.\nThese replacements are incorrectly treated as \"trusted\" and can leverage `` tags to add arbitrary code to Solr's classpath, potentially allowing malicious plugins or components to be loaded.\n\nThis issue affects all Apache Solr versions up through Solr 9.7. The vulnerable behavior lives in\nthe filesystem-backed config-set service used in standalone / user-managed mode \u2014 named\n`FileSystemConfigSetService` since Solr 9.0.0 (SOLR-15258), but present as its functional predecessor\n`ConfigSetService.Standalone` all the way back to Solr 4.8.0 (SOLR-4478). The affected range is\ntherefore 4.8.0 \u2013 9.7.0; Solr 9.8.0 mitigates it by disabling `` tags by default.\n\n#### Mitigation\n\nUsers can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from \"FileSystemConfigSetService\").\nUsers are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of \"\" tags by default.\n\n#### Credit\npwn null (reporter)", "status_notes": "Affected Apache Solr versions: 4.8.0-9.7.0." }, { "vulnerability": { "name": "CVE-2024-6763" }, "products": [ { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.13" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.15" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.17" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.19" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.20" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.22" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.26" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@8.1.10.v20130312" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@8.1.2.v20120308" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@8.1.8.v20121106" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.2.10.v20150310" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.2.11.v20150529" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.2.13.v20150730" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.3.14.v20161028" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.3.20.v20170531" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.3.8.v20160314" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.10.v20180503" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.11.v20180605" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.14.v20181114" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.19.v20190610" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.24.v20191120" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.27.v20200227" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.34.v20201102" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.44.v20210927" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.48.v20220622" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.8.v20171121" } ], "status": "not_affected", "timestamp": "2025-02-26T00:00:00Z", "impact_statement": "CVE-2024-6763 is an improper-input-validation issue in Eclipse Jetty's `HttpURI` parser, affecting\nJetty 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\nstill-supported 9.4.x branch). Solr bundles Jetty as its HTTP server, so scanners flag this CVE on\nevery Solr release whose Jetty predates 12.0.12 \u2014 Jetty 8.1.x/9.4.x/10.0.x from Solr 4.0.0 through\nSolr 9.10.1. Solr 10.0.0 ships Jetty 12.0.27 (\u2265 12.0.12) and is not affected. The affected range is\ntherefore 4.0.0 \u2013 9.10.1.\n\nSolr is **not affected**: it does not use the Jetty \"HttpURI\" utility class necessary for the vulnerability.", "status_notes": "Affected Apache Solr versions: 4.0.0-9.10.1." }, { "vulnerability": { "name": "CVE-2024-51504" }, "products": [ { "@id": "pkg:maven/org.apache.zookeeper/zookeeper@3.9.0" }, { "@id": "pkg:maven/org.apache.zookeeper/zookeeper@3.9.1" }, { "@id": "pkg:maven/org.apache.zookeeper/zookeeper@3.9.2" } ], "status": "not_affected", "timestamp": "2025-07-25T00:00:00Z", "impact_statement": "CVE-2024-51504 is **not** considered exploitable in typical **production** deployments of Apache Solr.\nSuccessful exploitation requires a very specific and non-standard configuration.\nThe following conditions **must all be met**:\n\n* Solr must be deployed in [SolrCloud mode](https://solr.apache.org/guide/solr/latest/deployment-guide/cluster-types.html#solrcloud-mode), which relies on ZooKeeper for coordination.\n* The **embedded ZooKeeper server** must be in use: a setup that is explicitly discouraged for production.\n Solr emits a warning when this configuration is detected, and it is not commonly used outside of development or experimentation.\n* The **ZooKeeper Admin Server** must be **manually enabled** in the ZooKeeper configuration file (`server/solr/zoo.cfg`).\n By default, this feature is disabled:\n\n```properties\n# Disable ZK AdminServer since we do not use it\nadmin.enableServer=false\n```\n\nBecause these conditions are highly unlikely in secure, production-grade environments,\nthe Solr community considers this vulnerability **non-exploitable under standard operating conditions**.", "status_notes": "Affected Apache Solr versions: 9.4.0-9.8.1." }, { "vulnerability": { "name": "CVE-2024-7254" }, "products": [ { "@id": "pkg:maven/com.google.protobuf/protobuf-java@2.4.0a" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@2.5.0" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.1.0" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.11.0" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.19.4" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.21.12" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.21.4" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.23.1" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.24.0" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.25.1" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.25.3" }, { "@id": "pkg:maven/com.google.protobuf/protobuf-java@3.6.1" } ], "status": "under_investigation", "timestamp": "2025-08-02T00:00:00Z", "status_notes": "Affected Apache Solr versions: 4.4.0-9.9.0. 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.\n\nCVE-2024-7254 affects all `protobuf-java` releases before 3.25.5 (per the upstream advisory the\nflaw was introduced at version 0, and is fixed in 3.25.5 / 4.27.5 / 4.28.2). Apache Solr has bundled\n`protobuf-java` (transitively, via Hadoop and ZooKeeper) since **Solr 4.4.0** (which shipped 2.4.0a),\nand every release from 4.4.0 through 9.9.0 ships an affected version (2.4.0a through 3.25.3). Solr\n**9.10.0** was the first release to ship a fixed `protobuf-java` (3.25.8), so the affected range is\n**4.4.0 \u2013 9.9.0**." }, { "vulnerability": { "name": "CVE-2025-48924" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-lang3@3.12.0" }, { "@id": "pkg:maven/org.apache.commons/commons-lang3@3.13.0" }, { "@id": "pkg:maven/org.apache.commons/commons-lang3@3.14.0" }, { "@id": "pkg:maven/org.apache.commons/commons-lang3@3.15.0" } ], "status": "not_affected", "timestamp": "2025-08-04T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2025-48924 is an uncontrolled-recursion issue in Apache Commons Lang's\n`ClassUtils.getClass(...)`: a very long, deeply-nested class name can exhaust the stack and\nthrow `StackOverflowError`. It affects `commons-lang3` from 3.0 up to (but not including) 3.18.0,\nso dependency scanners flag the `commons-lang3` JAR bundled in Solr 9.x (which ships versions\n3.12.0 through 3.15.0 across the 9.0\u20139.9 line).\n\nSolr is **not affected**. The vulnerable `ClassUtils.getClass(...)` code path is only reachable via\n`commons-configuration2`, which Solr uses solely in its Hadoop Kerberos support\n(`solr-hadoop-auth`) to load administrator-provided Hadoop configuration files. Class names are not\nattacker-controlled in that path, so the recursion cannot be driven by an adversary and the\nvulnerability is not exploitable in Solr.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2026-34477" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.25.3" } ], "status": "not_affected", "timestamp": "2026-04-10T00:00:00Z", "impact_statement": "CVE-2026-34477 is **not** considered exploitable in typical deployments of Apache Solr.\nSuccessful exploitation requires a specific, non-default logging configuration together with a privileged network position.\nThe following conditions **must all be met**:\n\n* The Log4j configuration is modified to add an `SMTP`, `Socket` or `Syslog` appender that ships logs over TLS through a nested `` element.\n* That appender relies on the `verifyHostName` attribute to authenticate the remote receiver, which was silently ignored through Log4j Core 2.25.3.\n* 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.\n\nNone of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution define such an appender.\nThey only use `Console` and `RollingRandomAccessFile` appenders, which open no network connection,\nso no TLS hostname verification ever takes place.\nThe `HTTP` appender is not affected either, as it uses a separate `verifyHostname` attribute that verifies host names by default.\n\nA configuration that does meet the conditions above looks like this:\n\n```xml\n\n \n \n \n \n \n \n \n \n\n```\n\nOperators who do configure TLS network appenders should replace the vulnerable JAR file\n(`server/lib/ext/log4j-core-2.25.3.jar`)\nwith `log4j-core-2.25.4.jar`.", "status_notes": "Affected Apache Solr versions: 9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-34478" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.25.3" } ], "status": "not_affected", "timestamp": "2026-04-10T00:00:00Z", "impact_statement": "CVE-2026-34478 is **not** considered exploitable in typical deployments of Apache Solr.\nSuccessful exploitation requires a specific, non-default logging configuration.\nThe following conditions **must all be met**:\n\n* The Log4j configuration is modified to send logs to a stream-based (TCP or TLS) syslog service using `Rfc5424Layout` directly.\n* An attacker is able to inject CRLF sequences into the logged data.\n\nBecause the `newLineEscape` and `useTlsMessageFormat` attributes were silently renamed in Log4j Core 2.21.0,\nnewline escaping stopped working and TLS framing was downgraded to plain TCP,\nleaving such configurations exposed to CRLF log injection.\n\nNone of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution reference `Rfc5424Layout`.\nThey only use `PatternLayout`, so the issue cannot be triggered.\nUsers of the `Syslog` appender are not affected either, since its attributes were not renamed.\n\nA configuration that does meet the conditions above looks like this:\n\n```xml\n\n \n \n \n\n```\n\nOperators who do configure `Rfc5424Layout` should either:\n\n* replace `newLineEscape` with `escapeNL` and `useTlsMessageFormat` with `useTLSMessageFormat`\n (note the capitalization), or\n* replace the vulnerable JAR file\n (`server/lib/ext/log4j-core-2.25.3.jar`)\n with `log4j-core-2.25.4.jar`.", "status_notes": "Affected Apache Solr versions: 9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-34479" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-1.2-api@2.25.3" } ], "status": "not_affected", "timestamp": "2026-04-10T00:00:00Z", "impact_statement": "CVE-2026-34479 is **not** considered exploitable in typical deployments of Apache Solr.\nSuccessful exploitation requires a specific, non-default logging configuration.\nThe following conditions **must all be met**:\n\n* The Log4j 1-to-Log4j 2 bridge emits logs through `Log4j1XmlLayout`,\n either configured directly in a Log4j 2 configuration\n or selected as `org.apache.log4j.xml.XMLLayout` through the Log4j 1 compatibility layer.\n* The logged data contains characters forbidden by the XML 1.0 specification.\n\nThe `log4j-1.2-api` JAR is shipped so that third-party libraries that still call the Log4j 1 API keep working.\nHowever, Solr is configured through Log4j 2 configuration files that only use `PatternLayout`,\nand the distribution ships no Log4j 1 (`log4j.properties` or `log4j.xml`) configuration file,\nso the vulnerable layout is never instantiated.\n\nA configuration that does meet the conditions above looks like this:\n\n```xml\n\n \n \n \n\n```\n\nOperators who use legacy Log4j 1 configuration files or `Log4j1XmlLayout` should replace the vulnerable JAR file\n(`server/lib/ext/log4j-1.2-api-2.25.3.jar`)\nwith `log4j-1.2-api-2.25.4.jar`.\nSupport for `Log4j1XmlLayout` and legacy Log4j 1 configuration files may be removed in a future Solr release,\nso migrating to a native Log4j 2 configuration is recommended.", "status_notes": "Affected Apache Solr versions: 9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-34480" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-core@2.25.3" } ], "status": "not_affected", "timestamp": "2026-04-10T00:00:00Z", "impact_statement": "CVE-2026-34480 is **not** considered exploitable in typical deployments of Apache Solr.\nSuccessful exploitation requires a specific, non-default logging configuration.\nThe following conditions **must all be met**:\n\n* The Log4j configuration is modified to write events through `XmlLayout`.\n* A log message or MDC value contains characters forbidden by the XML 1.0 specification.\n\nWhen triggered, the layout produces malformed XML, which downstream log processors may reject:\nsilently with the JRE built-in StAX, or by dropping the event with alternative implementations such as Woodstox.\n\nNone of the Log4j configuration files shipped in the Solr 9.10.1 binary distribution reference `XmlLayout`.\nThey only use `PatternLayout`, so the vulnerable code path is never reached.\nThe MDC values that Solr populates (collection, shard, replica, core and node names, plus a trace id) are not emitted as XML either.\n\nA configuration that does meet the conditions above looks like this:\n\n```xml\n\n \n \n \n\n```\n\nOperators who do configure `XmlLayout` should replace the vulnerable JAR file\n(`server/lib/ext/log4j-core-2.25.3.jar`)\nwith `log4j-core-2.25.4.jar`.", "status_notes": "Affected Apache Solr versions: 9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-34481" }, "products": [ { "@id": "pkg:maven/org.apache.logging.log4j/log4j-layout-template-json@2.25.3" } ], "status": "not_affected", "timestamp": "2026-04-10T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-34481 is **not** considered exploitable in any deployment of the Apache Solr binary distribution.\nSuccessful exploitation requires the application to log a `MapMessage` (or one of its subclasses)\ncarrying a non-finite floating-point value (`NaN`, `Infinity` or `-Infinity`) through `JsonTemplateLayout`,\nwhich the layout then serializes as invalid JSON, in breach of RFC 8259.\n\nProducing a `MapMessage` requires application code, and users of the binary distribution run only the code shipped by Apache Solr.\nA scan of the bytecode of all JAR files in the distribution confirms that the `MapMessage` family\n(`MapMessage`, `StringMapMessage` and `StructuredDataMessage`)\nis referenced only inside Log4j's own JARs.\nNeither Solr nor any of its bundled dependencies ever constructs or logs such a message.\n\nBecause no shipped code can hand a triggering value to the layout,\nthe vulnerable code path cannot be reached regardless of the configured layout,\nand the Solr community considers this vulnerability **non-exploitable** in the binary distribution.", "status_notes": "Affected Apache Solr versions: 9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-40682" }, "products": [ { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.8.3" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.0" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.1" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.2" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.4" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@2.5.6" } ], "status": "affected", "timestamp": "2026-05-04T00:00:00Z", "action_statement": "CVE-2026-40682 (CVSS 9.1) is an XML External Entity (XXE) vulnerability in Apache OpenNLP's\ndictionary parsing. The `DictionaryEntryPersistor` class and the public `Dictionary(InputStream)`\nconstructor create a SAX parser without enabling `FEATURE_SECURE_PROCESSING` or disabling DTD\nprocessing, so external entity resolution and DOCTYPE declarations remain fully enabled. An attacker\nwho can supply a crafted dictionary file \u2014 either directly or embedded in a model archive that\nOpenNLP deserializes \u2014 can therefore read local files from the server or trigger outbound requests\n(server-side request forgery). Other OpenNLP XML parsing paths route through the hardened\n`XmlUtil.createSaxParser()` helper, but this code path does not.\n\nThe vulnerable code is present in the `opennlp-tools-1.9.4.jar` that Solr pulls in transitively via\n`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\nXML processing that rejects DOCTYPE declarations and external entities.\n\n#### When Solr is exposed\n\nOpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed\nmodules are enabled. The vulnerable dictionary-parsing code path becomes reachable when:\n\n* The `analysis-extras` and/or `langid` modules are enabled \u2014 they are not loaded by default.\n* OpenNLP analysis components or update processors are configured to load OpenNLP model or\n dictionary files (the schema-configured OpenNLP analyzers \u2014 tokenizer, POS, chunker, lemmatizer,\n name-finder \u2014 or the `langid` / `analysis-extras` update processors).\n\nAny deployment that enables these modules and parses an OpenNLP model or dictionary an attacker can\ninfluence is exploitable. A deployment that does not enable them never parses an OpenNLP dictionary\nand is not exposed.\n\n#### Mitigation\n\nThe most reliable mitigation is to **not enable the OpenNLP-backed `analysis-extras` or `langid`\nmodules** unless they are required. If you do use OpenNLP, load model and dictionary files only from\nlocations you fully control, since the bundled OpenNLP 1.9.4 does not disable external entities when\nparsing dictionaries.\n\nEvery OpenNLP model and dictionary is loaded as a resource through Solr's resource loaders, so the\narchive passes through a single chokepoint before OpenNLP is allowed to deserialize it. This applies\nto both standalone (filesystem configset) and SolrCloud (ZooKeeper) deployments, and whether the\ndictionary is loaded by the `langid` / `analysis-extras` update processors or by the\nschema-configured OpenNLP analyzers.\n\nThis flaw is present in every OpenNLP release before 2.5.9 (fixed in 2.5.9 / 3.0.0-M3, backported to\n1.9.5). Solr has bundled OpenNLP (transitively, via `lucene-analysis-opennlp`) since Solr 7.3.0, so\nevery release from 7.3.0 through 10.0.0 ships an affected version (1.8.3 through 2.5.6). The affected\nrange is therefore 7.3.0 \u2013 10.0.0.\n\nFully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via `lucene-analysis-opennlp`) to 2.5.9.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-42027" }, "products": [ { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.8.3" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.0" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.1" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.2" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.4" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@2.5.6" } ], "status": "affected", "timestamp": "2026-05-04T00:00:00Z", "action_statement": "CVE-2026-42027 (CVSS 9.8) is an arbitrary class instantiation issue in Apache OpenNLP's\n`ExtensionLoader`. The `instantiateExtension(Class, String)` method loads a class named in a\nmodel archive's `manifest.properties` via `Class.forName()` and only performs its\n`isAssignableFrom` type check *after* the class has been loaded. Because `Class.forName()`\nruns the target class's static initializer at load time, an attacker who can supply a crafted\nmodel archive can trigger the static initializer of any class on the classpath (e.g. one that\nperforms a JNDI lookup, outbound network I/O, or filesystem access), regardless of the\ntype check that follows.\n\nThe vulnerable code is present in the `opennlp-tools-1.9.4.jar` that Solr pulls in transitively\nvia `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\npackage-prefix allowlist *before* calling `Class.forName()`.\n\n#### When Solr is exposed\n\nOpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed\nmodules are enabled. The vulnerable code path becomes reachable when:\n\n* The `analysis-extras` and/or `langid` modules are enabled \u2014 they are not loaded by default.\n* OpenNLP analysis components or update processors are configured to load model files.\n\nAny deployment that enables these modules and loads an OpenNLP model an attacker can influence is\nexploitable. A deployment that does not enable them never invokes `ExtensionLoader` and is not\nexposed.\n\n#### Mitigation\n\nThe most reliable mitigation is to **not enable the OpenNLP-backed `analysis-extras` or `langid`\nmodules** unless they are required. If you do use OpenNLP, load model files only from locations you\nfully control and never from untrusted or user-supplied sources.\n\nIn Solr 9.11.0 the upstream allowlist defense is backfilled at the application layer, since the\nvulnerable jar cannot yet be upgraded (Solr must track the OpenNLP version used by\n`lucene-analysis-opennlp`). Every OpenNLP model is loaded as a resource through Solr's resource\nloaders, so the archive is validated at that single chokepoint before OpenNLP is allowed to\ndeserialize it:\n\n* The archive is opened as a ZIP and every class name it declares \u2014 the `manifest.properties`\n `factory` entry and any class referenced from embedded feature-generator XML descriptors \u2014 must\n resolve under the `opennlp.` package prefix.\n* A model that names a class outside that prefix is rejected and never reaches `ExtensionLoader`,\n so no attacker-controlled static initializer can run.\n* Validation covers both standalone (filesystem configset) and SolrCloud (ZooKeeper) deployments,\n and applies whether the model is loaded by the `langid` / `analysis-extras` update processors or\n by the schema-configured OpenNLP analyzers (tokenizer, POS, chunker, lemmatizer, name-finder).\n\nSolr's own usage only ever references built-in `opennlp.*` factories, so legitimate models load\nunchanged; only crafted models that try to instantiate arbitrary classes are blocked.\n\nThis flaw is present in every OpenNLP release before 2.5.9 (fixed in 2.5.9 / 3.0.0-M3, backported to\n1.9.5). Solr has bundled OpenNLP (transitively, via `lucene-analysis-opennlp`) since Solr 7.3.0, so\nevery release from 7.3.0 through 10.0.0 ships an affected version (1.8.3 through 2.5.6). The affected\nrange is therefore 7.3.0 \u2013 10.0.0.\n\nFully resolved in Solr 10.1 by upgrading the bundled OpenNLP (via `lucene-analysis-opennlp`) to 2.5.9.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-42440" }, "products": [ { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.8.3" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.0" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.1" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.2" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@1.9.4" }, { "@id": "pkg:maven/org.apache.opennlp/opennlp-tools@2.5.6" } ], "status": "affected", "timestamp": "2026-05-04T00:00:00Z", "action_statement": "CVE-2026-42440 (CVSS 7.5) is an out-of-memory denial-of-service issue in Apache OpenNLP's binary\nmodel reader. The `AbstractModelReader` methods `getOutcomes()`, `getOutcomePatterns()` and\n`getPredicates()` read a 32-bit signed integer count field from a binary model stream and pass it\ndirectly to an array allocation without validating it. An attacker who can supply a crafted `.bin`\nmodel file with a count set to `Integer.MAX_VALUE` triggers an immediate `OutOfMemoryError` during\nmodel deserialization, before any substantial data is consumed.\n\nThe vulnerable code is present in the `opennlp-tools-1.9.4.jar` that Solr pulls in transitively via\n`lucene-analysis-opennlp` (Lucene 9.12.3). The issue is fixed upstream in OpenNLP 2.5.9 (and\n3.0.0-M3), and backported to the end-of-life 1.9.x line as `opennlp-tools-1.9.5`; all of these\nvalidate the count against an upper bound (default 10,000,000, configurable via the\n`OPENNLP_MAX_ENTRIES` system property) before allocating.\n\n#### When Solr is exposed\n\nOpenNLP is not part of a default Solr installation, but it is exploitable once the OpenNLP-backed\nmodules are enabled. The vulnerable model-loading code path becomes reachable when:\n\n* The `analysis-extras` and/or `langid` modules are enabled \u2014 they are not loaded by default.\n* OpenNLP analysis components or update processors are configured to load OpenNLP model files (the\n schema-configured OpenNLP analyzers \u2014 tokenizer, POS, chunker, lemmatizer, name-finder \u2014 or the\n `langid` / `analysis-extras` update processors).\n\nAny deployment that enables these modules and loads an OpenNLP model an attacker can influence is\nexploitable. A deployment that does not enable them never deserializes an OpenNLP model and is not\nexposed.\n\n#### Mitigation\n\nThe most reliable mitigation is to **not enable the OpenNLP-backed `analysis-extras` or `langid`\nmodules** unless they are required. If you do use OpenNLP, load model files only from locations you\nfully control and never from untrusted or user-supplied sources.\n\nThis flaw is present in every OpenNLP release before 2.5.9. Solr has bundled OpenNLP (transitively,\nvia `lucene-analysis-opennlp`) since Solr 7.3.0, so every release from 7.3.0 through 10.0.0 ships an\naffected version (1.8.3 through 2.5.6). The affected range is therefore 7.3.0 \u2013 10.0.0.\n\nFixed in Solr 9.11, which bundles the patched `opennlp-tools` 1.9.5, and in Solr 10.1, which upgrades\nthe bundled OpenNLP (via `lucene-analysis-opennlp`) to 2.5.9. Solr 10.0 remains affected (it ships\nOpenNLP 2.5.6).", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-11143" }, "products": [ { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.13" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.15" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.17" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.19" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.20" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.22" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.26" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@12.0.27" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.10.v20180503" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.11.v20180605" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.14.v20181114" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.19.v20190610" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.24.v20191120" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.27.v20200227" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.34.v20201102" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.44.v20210927" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.48.v20220622" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.8.v20171121" } ], "status": "not_affected", "timestamp": "2026-06-18T00:00:00Z", "impact_statement": "CVE-2025-11143 (CVSS 6.5; 3.7 per the Eclipse Foundation) is an improper-input-validation issue\n(CWE-20) in Eclipse Jetty's URI parser (`HttpURI`): it interprets some invalid or unusual URIs\ndifferently from other common HTTP parsers. When a component in front of Jetty parses the same URI\ndifferently, an attacker can craft a malformed URI to bypass URI-based security controls (such as\npath allow/deny lists) or to reveal implementation details. It affects Jetty 9.4.0\u20139.4.58,\n10.0.0\u201310.0.26, 11.0.0\u201311.0.26, 12.0.0\u201312.0.30 and 12.1.0\u201312.1.4; it is fixed in 9.4.59, 10.0.27,\n11.0.27, 12.0.31 and 12.1.5.\n\nCVE-2025-11143 is **not** considered exploitable in production deployments of Apache Solr.\nSuccessful exploitation requires a specific, non-recommended configuration \u2014 all of the following\nconditions must be true:\n\n* Solr must be deployed behind an HTTP intermediary (reverse proxy, load balancer, or API gateway)\n that enforces **URI-based** access rules (for example, blocking `/solr/admin/*` at the proxy layer).\n* That intermediary must be the **sole** security gate \u2014 Solr's own **authentication and\n authorization must not be enabled**.\n\n#### Why Solr auth is a complete fix\n\nThis is a **differential-parsing** issue: it only has security impact when a front-end proxy makes an\naccess-control decision based on its own URI interpretation and Solr has no independent access control\nof its own. Solr enforces access control in its own servlet filter (`SolrDispatchFilter` /\nthe `AuthenticationPlugin` framework) **after** Jetty has parsed the URI. Because Solr's auth layer\noperates on the same already-resolved path that Jetty produced, it cannot be confused by differential\nproxy/Jetty parsing \u2014 the bypass that the proxy grants does not help an attacker get past Solr's own\nauth. Enabling Solr auth provides **complete** protection, not merely a mitigating control. (This\ndistinguishes CVE-2025-11143 from request-smuggling issues such as CVE-2026-2332, where Solr auth\nreduces impact but does not eliminate all cross-connection effects.)\n\nThe Apache Solr project considers authentication and authorization a prerequisite for any\nproduction-secure deployment and explicitly warns against relying on network-perimeter controls as the\nsole access mechanism. A deployment without Solr auth that relies on a proxy's URI rules as its only\nsecurity boundary is therefore outside the project's supported production configuration.\n\nSolr has bundled a Jetty version in an affected branch (\u2265 9.4.0) since Solr 7.3.0 \u2014 Jetty 9.4.x\nthrough Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (below the fixed\n12.0.31) \u2014 so scanners flag this CVE across Solr 7.3.0 \u2013 10.0.0. As explained above, Solr is not\naffected in a supported (authenticated) configuration throughout that range.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-2332" }, "products": [ { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.13" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.15" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.17" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.19" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.20" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.22" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@10.0.26" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@12.0.27" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.10.v20180503" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.11.v20180605" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.14.v20181114" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.19.v20190610" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.24.v20191120" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.27.v20200227" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.34.v20201102" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.44.v20210927" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.48.v20220622" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-http@9.4.8.v20171121" } ], "status": "affected", "timestamp": "2026-06-18T00:00:00Z", "action_statement": "CVE-2026-2332 (CVSS 9.1) is an HTTP request-smuggling issue (CWE-444) in Eclipse Jetty's HTTP/1.1\nparser: the chunk-extension parser stops at a `\\r\\n` inside a quoted string instead of treating it\nas an error, so a crafted chunk extension can desynchronize request boundaries between Jetty and a\nfront-end HTTP intermediary. It affects Jetty 9.4.0\u20139.4.59, 10.0.0\u201310.0.27, 11.0.0\u201311.0.27,\n12.0.0\u201312.0.32 and 12.1.0\u201312.1.6; it is fixed in 9.4.60, 10.0.28, 11.0.28, 12.0.33 and 12.1.7.\n\nUnlike optional Jetty features (for example the JASPI authenticator), this is **core request-parsing\ncode**. Solr embeds Jetty as its HTTP server and bundles the vulnerable `jetty-http` module\n(`HttpParser`) \u2014 `jetty-http-10.0.26.jar` in the Solr 9.x line, and Jetty 9.4.44 in earlier 9.x\nreleases. Solr does not replace Jetty's wire-level HTTP parser, and it accepts chunked request\nbodies, so the vulnerable parser handles incoming requests and the code path is reachable.\n\n#### Exploitability depends on a fronting proxy\n\nRequest smuggling is a **desynchronization** attack: it requires a second HTTP processor in front of\nJetty that parses the crafted chunk extension differently. It is therefore only exploitable when Solr\nis deployed **behind an HTTP intermediary** \u2014 a reverse proxy, load balancer, TLS terminator, or API\ngateway \u2014 that disagrees with Jetty on request boundaries. This is a common Solr deployment, because\noperators frequently front Solr with such a proxy to add TLS and authentication. A Solr instance that\nis **not** fronted by a mis-parsing intermediary has no second parser to desync against, so this\nparticular attack does not apply to it.\n\nThe most damaging scenario is when that fronting proxy is the *only* security boundary (it enforces\nauthentication or restricts which Solr paths are reachable): a smuggled request rides past the proxy\nand reaches Solr's APIs directly, bypassing those controls.\n\n#### Mitigation\n\n* **Use a re-encoding reverse proxy.** A reverse proxy that fully parses and re-encodes the HTTP/1.1\n request body before forwarding to Jetty eliminates the attack at the network boundary: the proxy\n reads the attacker's malformed chunk extensions, then emits a clean, standards-conformant chunked\n (or `Content-Length`) request to Solr. No attacker-controlled chunk extension survives the trip, so\n Jetty never sees the malformed framing that triggers the desynchronization. **nginx** (`proxy_pass`\n in HTTP mode) and **HAProxy** (in `http` mode) both re-encode by default. Proxies configured in\n TCP pass-through or tunnel mode (e.g., HAProxy `tcp` mode, nginx `stream`) do *not* re-encode and\n do not mitigate this CVE.\n* **Enable Solr's built-in authentication and authorization.** Solr enforces access control in its\n own servlet filter (`SolrDispatchFilter` / the `AuthenticationPlugin` framework), *not* at the\n Jetty layer, so a request smuggled past a front-end proxy still has to pass Solr's own\n authentication and authorization. Enabling them removes the \"proxy is the only gate\" exposure that\n makes this attack most severe. (This is a mitigating control, not a complete fix \u2014 it does not\n eliminate cross-connection effects such as request hijacking or response desync.)\n* **Upgrade the bundled Jetty** to a patched release (\u2265 10.0.28 on the 10.0.x line), which is the\n full fix, however that requires commercial support. See https://webtide.com/end-of-life/ for options.\n\nSolr has bundled a Jetty version in an affected branch (\u2265 9.4.0) since Solr 7.3.0 \u2014 Jetty 9.4.x\nthrough Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (which is still\nbelow the fixed 12.0.33). Earlier releases shipped Jetty 9.2.x/9.3.x or 8.1.x, which pre-date the\naffected 9.4.0 branch. The affected range is therefore 7.3.0 \u2013 10.0.0; no released Solr yet bundles a\nfixed Jetty (\u2265 10.0.28 / 12.0.33).", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-5795" }, "products": [ { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.13" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.15" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.17" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.19" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.20" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.22" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@10.0.26" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@12.0.27" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.10.v20180503" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.11.v20180605" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.14.v20181114" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.19.v20190610" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.24.v20191120" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.27.v20200227" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.34.v20201102" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.44.v20210927" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.48.v20220622" }, { "@id": "pkg:maven/org.eclipse.jetty/jetty-server@9.4.8.v20171121" } ], "status": "not_affected", "timestamp": "2026-06-18T00:00:00Z", "justification": "vulnerable_code_not_present", "impact_statement": "CVE-2026-5795 (CVSS 7.4) is a broken-access-control / privilege-escalation issue in Eclipse Jetty's\n`JASPIAuthenticator` (the JSR-196 / Jakarta Authentication \"JASPI\" integration). During an\nauthentication check it sets thread-local state and, on an early return, fails to clear it, so a\nsubsequent request served by the same pooled thread can inherit that authentication state. It\naffects Jetty 9.4.0\u20139.4.60, 10.0.0\u201310.0.28, 11.0.0\u201311.0.28, 12.0.0\u201312.0.33 and 12.1.0\u201312.1.7; it is\nfixed in 9.4.61, 10.0.29, 11.0.29, 12.0.34 and 12.1.8.\n\nApache Solr 9.x bundles an affected Jetty (`jetty-server-10.0.26.jar` in the current 9.x line, and\nJetty 9.4.44 in earlier 9.x releases), so dependency scanners flag this CVE. Solr is **not affected**:\n\n* **The vulnerable code is not shipped.** `JASPIAuthenticator` lives in Jetty's `jetty-jaspi`\n module. Solr does not depend on `jetty-jaspi` \u2014 it is absent from Solr's dependency set (the build\n pulls in `jetty-server`, `jetty-security`, `jetty-servlet`, etc., but not `jetty-jaspi`), so the\n vulnerable class is not on the classpath.\n* **Solr does not use JASPI.** Solr authenticates requests in a servlet filter\n (`SolrDispatchFilter`) through its own `AuthenticationPlugin` framework (Basic, JWT, Kerberos,\n PKI, etc.). It never installs a Jetty `SecurityHandler`/`Authenticator`, and never the JASPI\n mechanism, so the vulnerable code path is unreachable even if the module were present.\n\nSolr has bundled a Jetty version in an affected branch (\u2265 9.4.0) since Solr 7.3.0 \u2014 Jetty 9.4.x\nthrough Solr 9.1, Jetty 10.0.x through Solr 9.10, and Jetty 12.0.27 in Solr 10.0.0 (below the fixed\n12.0.34) \u2014 so scanners flag this CVE across Solr 7.3.0 \u2013 10.0.0. Solr remains **not affected**\nthroughout that range because it never ships the `jetty-jaspi` module, regardless of the bundled\nJetty version.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-48734" }, "products": [ { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.7.0" }, { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.8.3" }, { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.9.3" }, { "@id": "pkg:maven/commons-beanutils/commons-beanutils@1.9.4" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2025-48734 allows an attacker to access the JVM ClassLoader (and potentially execute arbitrary code) by passing a property path containing 'declaredClass' to PropertyUtilsBean.getProperty() or getNestedProperty(). Exploitation requires an application to pass externally supplied property path strings to these BeanUtils methods. A search of the Solr codebase confirms that Solr does not call PropertyUtilsBean.getProperty(), BeanUtilsBean, or any Commons BeanUtils introspection APIs directly. commons-beanutils is only ever pulled in transitively: in the 9.x line via `hadoop-common` (used by the optional Hadoop/Kerberos authentication module, which reads administrator-supplied configuration files rather than untrusted external input), and in 10.0 \u2014 after the Hadoop module was removed (SOLR-17540) \u2014 via the `cross-dc-manager` module's embedded Kafka broker (`kafka_2.13` \u2192 `commons-validator` \u2192 `commons-beanutils`). No Solr code passes externally-supplied property paths to BeanUtils in either case, so the vulnerable code path is unreachable regardless of how the jar is bundled.\n\nCVE-2025-48734 affects all Commons BeanUtils 1.x releases before 1.11.0. Solr has bundled\ncommons-beanutils since Solr 3.6.0, and every release that includes it, through Solr 10.0.0, ships an\naffected 1.x version (1.7.0, then 1.8.3, 1.9.3 and 1.9.4 \u2014 all below 1.11.0). The affected range is\ntherefore 3.6.0 \u2013 10.0.0.", "status_notes": "Affected Apache Solr versions: 3.6.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-33870", "aliases": [ "CVE-2026-33871" ] }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-33870 is an HTTP/1.1 request smuggling vulnerability via malformed chunked transfer encoding extension values in Netty's server-side HTTP codec. CVE-2026-33871 is an HTTP/2 CONTINUATION frame flood DoS against a Netty HTTP/2 server. Both require Netty to be used as an HTTP server accepting connections from untrusted clients. In Solr, Netty is a transitive dependency (via ZooKeeper 3.9.x and optionally the OpenTelemetry OTLP exporter); it is used exclusively as an HTTP client and for ZooKeeper's own non-HTTP binary protocol. Solr's HTTP server is Jetty, not Netty. No Netty ServerBootstrap or HTTP server pipeline is configured in Solr. Therefore neither CVE can be triggered against a running Solr instance.\n\nBoth CVEs affect Netty releases before 4.1.132 and 4.2.0 through 4.2.9. Solr has bundled the modular\n`netty-codec-http` / `netty-codec-http2` artifacts (transitively, via ZooKeeper and the optional\nOpenTelemetry OTLP exporter) since Solr 9.2.0 \u2014 earlier releases used the `netty-all` uber-jar \u2014 and\nevery release from 9.2.0 through 10.0.0 ships an affected version (4.1.89.Final through 4.2.6.Final).\nThe affected range is therefore 9.2.0 \u2013 10.0.0.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-41417" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-41417 (CVSS 5.3) is a request-smuggling issue (CWE-93 / CWE-444) in Netty's HTTP/1.1\ncodec. `DefaultHttpRequest` and `DefaultFullHttpRequest` reject CRLF and whitespace characters in\ntheir constructors, but the `setUri()` method that lets a request's URI be rewritten after\nconstruction has no equivalent validation, so an attacker who controls a value later passed to\n`setUri()` can inject CRLF sequences and smuggle a second request. It affects Netty versions before\n4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final; it is fixed in 4.1.133.Final and 4.2.13.Final.\n\nThe `netty-codec-http` jar this CVE concerns was first shipped by Solr in **9.2.0** (SOLR-16532),\nwhen the optional `opentelemetry` module started pulling it in transitively via `grpc-netty`. That\ndoesn't mean Solr had no HTTP codec classes before then, though: earlier Solr releases (7.x through\n8.2.x) already shipped this same `DefaultHttpRequest`/`DefaultFullHttpRequest` code, bundled in the\nolder `netty-all` uber-jar \u2014 just not as this specific modular jar. Every release since 9.2.0 has\nshipped a vulnerable `netty-codec-http`: 4.1.114.Final (before 4.1.133.Final) through the\n9.2.0\u20139.9.0 line, and 4.2.6.Final (within the vulnerable 4.2.0.Alpha1\u20134.2.12.Final range,\n`netty-codec-http-4.2.6.Final.jar`) in the current 9.10.x and 10.0.x lines. So dependency scanners\nflag this CVE across the whole 9.2.0\u201310.x range. Solr is **not affected**:\n\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources. Netty is a transitive dependency, not something Solr calls directly.\n* **The only production path is an outbound gRPC client, not an HTTP server.** The optional\n `opentelemetry` module (`solr/modules/opentelemetry`) pulls in `io.grpc:grpc-netty` to export\n trace spans over OTLP/gRPC to an operator-configured collector endpoint. That is a client\n connection Solr *initiates* to a trusted, configured address \u2014 Netty never parses inbound,\n attacker-controlled HTTP requests in this path, and nothing in that flow calls `setUri()` on a\n request built from untrusted input.\n* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs are handled by\n Jetty's servlet stack (`SolrDispatchFilter`); Netty is never in that request path at all.\n* **The other place `netty-codec-http` appears is test-only.** The `jwt-auth` module depends on it\n as `testRuntimeOnly` (required by the `mock-oauth2-server` test dependency), so it is not part of\n any shipped Solr artifact.\n\nSince the vulnerable `setUri()` bypass is never exercised \u2014 Solr neither constructs nor mutates\nNetty HTTP requests from attacker-controlled data \u2014 the vulnerable code is present on the classpath\nbut not in any reachable execution path.\n\nNo released Solr version ships the fix yet. On Solr's `main` development branch, Netty was bumped\n4.2.6.Final \u2192 4.2.12.Final (still within the vulnerable range) \u2192 4.2.15.Final in June 2026, which is\nfixed \u2014 and will be released in Solr versions 9.11.0 and 10.1.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42577" }, "products": [ { "@id": "pkg:maven/io.netty/netty-transport-native-epoll@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "impact_statement": "CVE-2026-42577 (CVSS 7.5, CWE-772) is a resource-leak / denial-of-service issue in Netty's Epoll\nnative transport: a TCP connection that receives a RST after being half-closed isn't properly\nclosed, so stale channels accumulate and can eventually pin the owning event-loop thread at 100%\nCPU. It affects Netty 4.2.0.Final up to (but not including) 4.2.13.Final \u2014 the Epoll transport code\nin question was introduced by the 4.2 rewrite, so the older 4.1.x line is unaffected regardless of\npatch version. It is fixed in 4.2.13.Final.\n\n`netty-transport-native-epoll` \u2014 the modular jar this CVE concerns \u2014 has been part of Solr's\ndependency graph since **8.3.0** (SOLR-13665), as a transitive dependency of **Apache ZooKeeper**'s\nclient library (`org.apache.zookeeper:zookeeper`), which optionally supports a Netty-based\nconnection socket for both its client and server roles. Older Solr releases (7.x through 8.2.x)\nalready bundled Netty's Epoll transport code too, in the older `netty-all` uber-jar, but at ancient\n4.0.x Netty versions \u2014 well below this CVE's affected range regardless. From 8.3.0 through 9.9.0,\nthe modular jar stayed on Netty 4.1.x, still outside this CVE's affected range. Starting with\n9.10.0 (and 10.0.0), Solr moved to Netty 4.2.6.Final, which does fall in the vulnerable range, and\ndependency scanners flag `netty-transport-native-epoll-4.2.6.Final.jar` (classifier `linux-x86_64`)\non the classpath.\n\nCVE-2026-42577 is **not** considered exploitable in typical deployments of Apache Solr. Successful\nexploitation requires a specific, non-default configuration together with a hostile or compromised\npeer on that connection:\n\n* ZooKeeper client TLS must be explicitly enabled, following **ZooKeeper's own** documented\n instructions \u2014 setting `zookeeper.client.secure=true` and\n `zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty` (typically as JVM system\n properties in `solr.in.sh`/`SOLR_OPTS`), plus the corresponding `zookeeper.ssl.*` keystore/truststore\n properties. ZooKeeper's own documentation states this plainly: \"SSL feature will be enabled when\n user plugs-in zookeeper.serverCnxnFactory, zookeeper.clientCnxnSocket as Netty\" \u2014 the default\n plain-NIO socket (`ClientCnxnSocketNIO`) has no TLS support at all. This is not something Solr\n ships, sets, or documents in its own reference guide; it requires an operator to configure it\n directly via ZooKeeper's own mechanism, independent of Solr.\n* That alone is enough to make the Epoll transport reachable: ZooKeeper's Netty client\n (`org.apache.zookeeper.common.NettyUtils`) explicitly prefers the Epoll event loop over plain NIO\n whenever the native library is available, which it is on the common case of Linux.\n* An attacker still needs to be able to trigger the RST-after-half-close condition against that\n specific connection \u2014 meaning a compromised ZooKeeper ensemble member, or a network position\n able to manipulate that TCP connection. ZooKeeper ensemble members are ordinarily trusted,\n operator-controlled infrastructure, which narrows this further even when the configuration\n precondition is met.\n\nSolr's default configuration never enables ZooKeeper client TLS, so ZooKeeper's client socket\ndefaults to the plain-NIO `ClientCnxnSocketNIO`, and the bundled `netty-transport-native-epoll` jar\nsits completely unused on the classpath \u2014 ZooKeeper connections go through the default NIO socket,\nnever through Netty's Epoll channel implementation, unless an operator has taken the additional\nstep above. The other place Netty appears in Solr \u2014 the optional `opentelemetry` module's\n`grpc-netty` OTLP exporter \u2014 never depends on `netty-transport-native-epoll` at all, so it offers no\nalternate path to this code. No Solr code instantiates an Epoll channel directly either: there are\nno `io.netty` imports anywhere in Solr's own Java sources.\n\nOnly operators who have both enabled ZooKeeper client TLS and are exposed to a hostile or\ncompromised ZooKeeper peer are affected. Operators who do enable ZooKeeper client TLS should treat\ntheir ZooKeeper ensemble as they would any other TLS endpoint pending an upgrade, or restrict\nnetwork access to it in the interim.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42578" }, "products": [ { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-handler-proxy@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42578 (CVSS 7.5, CWE-93 / CWE-113) is a header-injection issue in\n`io.netty:netty-handler-proxy`'s `HttpProxyHandler`, used when a Netty client tunnels a connection\nthrough an HTTP proxy via CONNECT. Its `newInitialMessage()` method builds the CONNECT request's\nheaders with validation explicitly disabled (`DefaultHttpHeadersFactory...withValidation(false)`),\nthen appends the caller-supplied `outboundHeaders` without any CRLF check \u2014 so an attacker who\ninfluences those header values can inject arbitrary headers, or split, the CONNECT request sent to\nthe proxy. It affects Netty before 4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final; fixed in\n4.1.133.Final and 4.2.13.Final.\n\nSolr has shipped a vulnerable `netty-handler-proxy` since **9.2.0** (4.1.x through the 9.2.0\u20139.9.0\nline, 4.2.x \u2014 `netty-handler-proxy-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward); Solr versions\nbefore 9.2.0 don't ship this jar. It arrives as a transitive runtime dependency of `grpc-netty`,\nused only by the optional `opentelemetry` module's OTLP gRPC exporter. Solr is **not affected**:\n\n* **Solr never configures an HTTP/SOCKS proxy for its OTLP exporter.** `HttpProxyHandler` is only\n instantiated when grpc-netty's channel is told to tunnel through a proxy \u2014 via gRPC's default\n `ProxyDetector`, which honors the JVM's standard `http.proxyHost`/`https.proxyHost` system\n properties. Solr sets none of this itself; a proxy tunnel (and therefore `HttpProxyHandler`) is\n only in play if an operator has separately configured JVM-wide HTTP proxy settings, which isn't\n Solr's default posture.\n* **Even with a proxy configured, nothing attacker-controlled reaches `outboundHeaders`.** The flaw\n only bites through caller-supplied header values passed into `HttpProxyHandler`. Any values Solr's\n (or grpc's) proxy path would ever supply \u2014 the collector address, proxy credentials sourced from\n JVM properties \u2014 are operator-configured, never derived from a client request to Solr's search\n APIs.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources, so nothing in Solr itself constructs or feeds data into an `HttpProxyHandler`.\n\nExploiting this requires both a non-default proxy configuration and attacker-controlled header\ndata that Solr's OTLP export path never supplies, so the vulnerable code is present on the\nclasspath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42580" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42580 (CVSS 6.5, CWE-190 / CWE-444) is a request-smuggling issue in `netty-codec-http`'s\n`HttpObjectDecoder`: when parsing a chunked HTTP/1.1 message, the hex chunk-size field is parsed\ninto a 32-bit int without an overflow check, so an oversized chunk-size value silently wraps\naround to a small (or negative) number instead of being rejected. A crafted chunk whose declared\nsize doesn't match the bytes actually sent can desynchronize how Netty and a front-end HTTP\nintermediary frame the request, the same general smuggling pattern as other chunk/header parsing\nbugs that have affected HTTP implementations. It affects Netty before 4.1.133.Final and\n4.2.0.Alpha1\u20134.2.12.Final; fixed in 4.1.133.Final and 4.2.13.Final.\n\nSolr has shipped a vulnerable `netty-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\n`HttpObjectDecoder` itself isn't new at that point \u2014 earlier Solr releases (7.x through 8.2.x)\nalready shipped this same class, bundled in the older `netty-all` uber-jar. This is a\n**decoder**-side bug \u2014 it only bites when Netty is parsing an inbound chunked HTTP/1.1 message,\nwhich makes Solr's exposure narrow to begin with, since Solr's own HTTP server never uses this\ndecoder at all (see below). Solr is **not affected**:\n\n* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a\n Netty decoder at all; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every\n attacker-facing request.\n* **The OTLP gRPC path never parses chunked HTTP/1.1.** gRPC traffic is HTTP/2 framed, not\n HTTP/1.1 chunked transfer-encoding, so `HttpObjectDecoder`'s chunk-size parsing is never invoked\n by the actual trace-export traffic.\n* **The only place this decoder could run is an optional proxy CONNECT response**, and only if an\n operator has separately configured an HTTP proxy for the OTLP exporter \u2014 itself non-default, since\n Solr never sets any JVM-wide HTTP proxy properties itself \u2014 and only if that operator-configured,\n trusted proxy sent back a chunked response, which isn't how CONNECT responses are normally\n constructed.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince there is no attacker-reachable path where Solr (or its dependencies) ever decodes an\nattacker-supplied chunked HTTP/1.1 message through this Netty codec, the vulnerable code is present\non the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42581" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42581 (CWE-444) is a request-smuggling issue in `netty-codec-http`'s\n`HttpObjectDecoder`: for an HTTP/1.0 request that carries both `Transfer-Encoding: chunked` and a\n`Content-Length` header, the decoder fails to strip the conflicting `Content-Length`, so\ndownstream proxies or handlers that pick a different header to trust can disagree with Netty about\nwhere the request body ends. It affects Netty before 4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final;\nfixed in 4.1.133.Final and 4.2.13.Final.\n\nSolr has shipped a vulnerable `netty-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\n`HttpObjectDecoder` itself isn't new at that point \u2014 earlier Solr releases (7.x through 8.2.x)\nalready shipped this same class, bundled in the older `netty-all` uber-jar. This is a\n**decoder**-side bug \u2014 it only bites when Netty parses an inbound HTTP/1.0/1.1 request. Solr is\n**not affected**:\n\n* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a\n Netty decoder; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every attacker-facing\n request.\n* **The OTLP gRPC path never parses HTTP/1.x requests.** gRPC traffic is HTTP/2 framed, so\n `HttpObjectDecoder` (an HTTP/1.x-only class) is never invoked by the actual trace-export traffic,\n and Solr's outbound gRPC client never *receives* an HTTP/1.x request to decode in the first place\n \u2014 it only ever decodes a proxy's CONNECT *response*, if a proxy is configured at all (an\n optional, non-default setup for the OTLP exporter).\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince there is no attacker-reachable path where Solr (or its dependencies) ever decodes an\nattacker-supplied HTTP/1.0 or HTTP/1.1 request through this Netty codec, the vulnerable code is\npresent on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42583" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42583 (CVSS 7.5, CWE-400 / CWE-770) is a resource-exhaustion issue in\n`netty-codec-compression`'s `Lz4FrameDecoder`: it allocates a `ByteBuf` sized to the frame's\nclaimed `decompressedLength` (up to 32 MB per block) *before* running LZ4 decompression, so a\ncrafted frame that lies about its decompressed size can force large allocations regardless of how\nmuch data was actually sent \u2014 a decompression-bomb-style DoS. It affects Netty before\n4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final; fixed in 4.1.133.Final and 4.2.13.Final.\n\n`netty-codec-compression` \u2014 the specific jar this entry tracks \u2014 first appears in Solr's dependency\ngraph in **9.10.0/10.0.0** (`netty-codec-compression-4.2.6.Final.jar`); it's a byproduct of Netty's\nown 4.2 module split, which broke compression codecs out of the general-purpose `netty-codec`\nartifact into their own jar. `Lz4FrameDecoder` itself is not new at that point, though: it already\nexisted in `netty-codec` going back to Solr 8.3.0 (SOLR-13665), when Solr first shipped modular\nNetty jars at all. The same reasoning below has applied for that whole span \u2014 Solr has never wired\nthis decoder into anything, regardless of which jar happens to contain it. Solr is **not\naffected**:\n\n* **Nothing in Solr's dependency graph ever instantiates `Lz4FrameDecoder`.** It arrives purely as\n a transitive dependency of Netty's own HTTP/2 and proxy-handler modules (used by `grpc-netty`,\n the optional `opentelemetry` module's OTLP exporter), not because anything negotiates or uses LZ4\n compression. gRPC's own message-compression layer uses `gzip`/`identity`, never LZ4, so this\n decoder is never added to any pipeline Solr builds.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources, and no Solr build file references LZ4, Snappy, Brotli, or Zstd Netty codec classes.\n\nSince the vulnerable decoder is never wired into any pipeline that processes attacker-supplied\ndata, the vulnerable code is present on the classpath (where it exists at all) but not reachable in\nany real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42584" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42584 (CVSS up to 9.1, CWE-444) is a request-smuggling issue in `netty-codec-http`'s\n`HttpClientCodec`: it pairs each inbound response with the next outbound request by calling\n`queue.poll()` exactly once per response, including for 1xx informational responses. When a server\nsends a 1xx response ahead of the real final response, the codec's request/response pairing slips,\nand a later response's body gets parsed from the wrong offset. It affects Netty before 4.1.133.Final\nand 4.2.0.Alpha1\u20134.2.12.Final; fixed in 4.1.133.Final and 4.2.13.Final.\n\nSolr has shipped a vulnerable `netty-codec-http` since **9.2.0** (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\n`HttpClientCodec` itself isn't new at that point \u2014 earlier Solr releases (7.x through 8.2.x)\nalready shipped this same class, bundled in the older `netty-all` uber-jar. It's the HTTP/1.1\nclient-side codec inside that jar, and Solr's dependency graph only ever uses it inside Netty's\n`HttpProxyHandler`, to send an HTTP CONNECT request and parse the proxy's response when tunneling\n`grpc-netty`'s OTLP export traffic through an HTTP proxy \u2014 itself a non-default configuration,\nsince Solr never sets any JVM-wide HTTP proxy properties itself. Solr is **not affected**:\n\n* **The bug requires a pipelined sequence of requests/responses (including 1xx) to desync.** A\n CONNECT tunnel is a single request/response exchange \u2014 once established, the connection carries\n opaque HTTP/2 gRPC bytes, not further HTTP/1.1 messages for `HttpClientCodec` to mis-pair. There's\n no second request in flight for the queue to get out of sync with.\n* **The proxy path itself is non-default.** `HttpProxyHandler`/`HttpClientCodec` are only\n instantiated at all if an operator has separately configured an HTTP proxy for the OTLP exporter,\n which isn't Solr's default posture.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources, and Solr's own HTTP server is Jetty, not Netty, so no inbound Solr traffic is ever parsed\n by `HttpClientCodec` either way (it's a client-side class regardless).\n\nSince Solr never exercises a multi-request HTTP/1.1 exchange over any Netty channel, the\nrequest/response pairing this bug corrupts never has more than one entry to desync, so the\nvulnerable code is present on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42585" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42585 (CWE-444) is a request-smuggling issue in `netty-codec-http`'s HTTP/1.x\ndecoder: a malformed `Transfer-Encoding` header value is parsed incorrectly, so Netty and a\nfront-end HTTP intermediary can disagree about whether a request is chunked. It affects Netty\nbefore 4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final; fixed in 4.1.133.Final and 4.2.13.Final.\n\nSolr has shipped a vulnerable `netty-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\nThis HTTP/1.x decoder itself isn't new at that point \u2014 earlier Solr releases (7.x through 8.2.x)\nalready shipped this same code, bundled in the older `netty-all` uber-jar. This is a\n**decoder**-side issue \u2014 it only bites when Netty parses an inbound HTTP/1.x request. Solr is\n**not affected**:\n\n* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a\n Netty decoder; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every attacker-facing\n request.\n* **The OTLP gRPC path never parses HTTP/1.x requests.** gRPC traffic is HTTP/2 framed, and Solr's\n outbound gRPC client only ever decodes a proxy's CONNECT *response* (if a proxy is configured at\n all, an optional non-default setup), never an inbound HTTP/1.x request.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince there is no attacker-reachable path where Solr (or its dependencies) ever decodes an\nattacker-supplied HTTP/1.x request through this Netty codec, the vulnerable code is present on the\nclasspath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-42587" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-42587 (CVSS 7.5, CWE-400 / CWE-770) is a resource-exhaustion issue in `netty-codec-http`'s\n`HttpContentDecompressor`: its `maxAllocation` parameter, meant to cap decompression-buffer size\nand prevent decompression-bomb attacks, is correctly enforced for `gzip`/`deflate` (via\n`ZlibDecoder`) but silently ignored for `br` (Brotli), `zstd`, and `snappy` content encodings \u2014 so\na compressed body using one of those encodings can bypass the limit and trigger unbounded memory\nallocation. It affects Netty before 4.1.133.Final and 4.2.0.Alpha1\u20134.2.12.Final; fixed in\n4.1.133.Final and 4.2.13.Final.\n\n`HttpContentDecompressor` is part of `netty-codec-http`. Solr has shipped a vulnerable\n`netty-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014 `netty-codec-http-4.2.6.Final.jar` \u2014\nfrom 9.10.0/10.0.0 onward), arriving as a transitive runtime dependency of `grpc-netty`, used only\nby the optional `opentelemetry` module's OTLP gRPC exporter. `HttpContentDecompressor` itself isn't\nnew at that point \u2014 earlier Solr releases (7.x through 8.2.x) already shipped this same class,\nbundled in the older `netty-all` uber-jar. Solr is **not affected**:\n\n* **`HttpContentDecompressor` is never added to any pipeline Solr builds.** It's an opt-in handler\n for automatic HTTP/1.x content decoding; gRPC has its own separate message-compression framework\n (negotiated at the gRPC layer, using `gzip`/`identity`) that doesn't route through Netty's HTTP\n content-encoding decompressor at all.\n* **The only HTTP/1.x traffic Solr's Netty usage ever generates is a proxy CONNECT exchange**\n (an optional, non-default setup for the OTLP exporter), and CONNECT responses don't carry a\n compressed body for this handler to decompress in the first place.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince `HttpContentDecompressor` is never installed in any pipeline Solr's dependencies construct,\nthe vulnerable code is present on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-44249" }, "products": [ { "@id": "pkg:maven/io.netty/netty-handler@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.29.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.47.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.50.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.68.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.82.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-44249 (CVSS 8.1, CWE-284 / CWE-697 / CWE-1287) is an access-control bypass in\n`netty-handler`'s `IpSubnetFilterRule.compareTo()`: an incorrect IPv6 masking operation lets a\nvalid public IPv6 address slip past a configured subnet allow/deny rule. `IpSubnetFilterRule` (and\nthe `RuleBasedIpFilter` that uses it) is a server-side feature an application installs in a Netty\npipeline to accept or reject *inbound* connections by source IP. It affects Netty before\n4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\nSolr has shipped `netty-handler` \u2014 the modular jar this CVE concerns \u2014 since **8.3.0** (SOLR-13665,\n`netty-handler-4.2.6.Final.jar` in the current 9.10.x/10.0.x lines), as a transitive dependency of\n**Apache ZooKeeper**'s client library (`org.apache.zookeeper:zookeeper`), which optionally supports\na Netty-based connection socket. Earlier Solr releases (7.x through 8.2.x) already shipped this\nsame `IpSubnetFilterRule` class too, bundled in the older `netty-all` uber-jar; 8.3.0 is when Solr's\nbuild started declaring the modular artifacts explicitly instead. Since **9.2.0** `netty-handler`\nhas also arrived via `grpc-netty`, used by the optional `opentelemetry` module's OTLP gRPC exporter.\nSolr is **not affected**:\n\n* **Solr never runs a Netty server.** `IpSubnetFilterRule` only matters for filtering *inbound*\n connections at a server. Solr's own HTTP server is Jetty. ZooKeeper's client socket defaults to\n plain NIO, and Solr never enables its Netty alternative by default \u2014 but even an operator who\n does enable it (following ZooKeeper's own TLS instructions) only switches Solr's ZooKeeper\n *client* socket; that never makes Solr run the corresponding `NettyServerCnxnFactory` server,\n which Solr never uses at all. `grpc-netty`'s outbound OTLP client is a client too, and never\n accepts an inbound connection to filter either.\n* **Nothing in Solr's dependency graph ever constructs an `IpSubnetFilterRule`.** There's no IP\n allow/deny-list feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s\n client channel construction, that uses this class.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources. Any IP-based access control an operator configures for Solr (e.g., at a fronting reverse\n proxy, or Jetty's own connection-level controls) is implemented entirely outside Netty.\n\nSince `IpSubnetFilterRule` is never installed or evaluated anywhere in Solr's dependency graph, the\nvulnerable code is present on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 8.3.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-45416" }, "products": [ { "@id": "pkg:maven/io.netty/netty-handler@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.47.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.50.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.68.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.82.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-45416 (CVSS 7.5, CWE-770) is a resource-exhaustion issue in `netty-handler`'s\n`SslClientHelloHandler.decode()`: it reads the 24-bit TLS handshake length from an inbound\nClientHello and eagerly allocates a buffer sized to it without a configured limit\n(`maxClientHelloLength` defaults to `0`, meaning unlimited), so a crafted ~16 MiB ClientHello can\nforce a huge, unpooled allocation. This only matters for applications using `SniHandler` (or\n`AbstractSniHandler` directly) to peek at a TLS ClientHello's SNI extension and pick a per-hostname\n`SSLContext` \u2014 a **server-side** TLS-termination feature for inbound connections. It affects Netty\nbefore 4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\n`netty-handler` has shipped in Solr since 8.3.0 (SOLR-13665), via **Apache ZooKeeper**'s client\nlibrary, but `SslClientHelloHandler` \u2014 the specific class this CVE concerns \u2014 didn't exist yet at\nthat point: Solr 8.3.0\u20138.5.2 pinned Netty 4.1.29.Final, which lacks it entirely (Netty only\nintroduced it in 4.1.47.Final). Solr picked up that version starting at **8.6.0**, so that's the\ntrue first-shipped point for this specific vulnerability, not 8.3.0. `SniHandler` itself (the\nclass applications actually configure) existed earlier, in both 4.1.29.Final and the older\n`netty-all` uber-jar Solr shipped before 8.3.0 \u2014 but the unbounded-allocation bug lives in\n`SslClientHelloHandler`, a piece `SniHandler` was refactored to delegate to only later. Since\n**9.2.0**, `netty-handler` has also arrived via `grpc-netty`, used by the optional `opentelemetry`\nmodule's OTLP gRPC exporter. Solr is **not affected**:\n\n* **Solr never runs a Netty server, let alone a TLS-terminating one that inspects ClientHello\n SNI.** `SniHandler`/`SslClientHelloHandler` only matter for a server accepting inbound TLS\n connections and routing by SNI hostname. ZooKeeper's client socket defaults to plain NIO, and\n Solr never enables its Netty alternative by default \u2014 but even if an operator does (following\n ZooKeeper's own TLS instructions), that only switches Solr's ZooKeeper *client* socket, which\n never receives a ClientHello to sniff in the first place (a client sends one; it doesn't parse\n one). `grpc-netty`'s outbound OTLP client is in the same position.\n* **Nothing in Solr's dependency graph installs `SniHandler`.** There's no per-hostname TLS\n routing feature anywhere in Solr, ZooKeeper's client configuration, or `grpc-netty`'s client\n channel construction, that would need it.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources. Solr's own TLS termination (when enabled) is handled entirely by Jetty, not Netty.\n\nSince `SslClientHelloHandler` is never installed or invoked anywhere in Solr's dependency graph,\nthe vulnerable code is present on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 8.6.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-45536" }, "products": [ { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.29.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.47.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.50.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.68.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.82.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-transport-native-unix-common@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-45536 (CVSS 4.0, CWE-200 / CWE-772) is a file-descriptor leak in the native/JNI code\nbacking `netty-transport-native-unix-common`: `netty_unix_socket_recvFd` allocates only 24 bytes\nfor the ancillary-data control message, so when a peer sends an `SCM_RIGHTS` message carrying two\nfile descriptors over a Unix domain socket, the kernel installs both fds but Netty's code only\naccounts for one, leaking the other on every such message. Its CVSS vector is Attack Vector:\n**Local** \u2014 this requires a local peer with an existing Unix-domain-socket connection to the\naffected process, not a remote/network attacker. It affects Netty before 4.1.135.Final and\n4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\n`netty-transport-native-unix-common` \u2014 the modular jar this CVE concerns \u2014 has been part of Solr's\ndependency graph since **8.3.0** (SOLR-13665, `netty-transport-native-unix-common-4.2.6.Final.jar`\nin the current 9.10.x/10.0.x lines), the shared native support library underneath Netty's Epoll and\nKQueue transports, pulled in via **Apache ZooKeeper**'s client library and, since 9.2.0, also\ndirectly by `grpc-netty`. Older Solr releases (7.x through 8.2.x) already bundled this same native\nUnix-domain-socket code, in the older `netty-all` uber-jar at ancient 4.0.x Netty versions \u2014 the\nsame architectural reasoning below (Solr never opens a Unix domain socket via Netty) applies to\nthose releases just as it does here, independent of which jar or Netty version carries the code.\nSolr is **not affected**:\n\n* **Solr never opens a Unix domain socket via Netty.** `netty_unix_socket_recvFd` is only invoked\n when a `DomainSocketChannel`/`UnixChannel` is actually used. Solr's only Netty channel \u2014\n `grpc-netty`'s outbound OTLP exporter for the optional `opentelemetry` module \u2014 connects over\n TCP/IP to a configured collector address, never a local Unix socket. ZooKeeper's client socket\n defaults to plain NIO, and Solr never enables its Netty alternative by default \u2014 but even if an\n operator does (following ZooKeeper's own TLS instructions), that transport still addresses the\n ensemble over ordinary TCP/IP host:port connections, never a local Unix domain socket, so there's\n still no Unix-domain-socket connection anywhere in Solr's dependency graph to leak a file\n descriptor from.\n* **Even where the jar is present, there's no peer positioned to send `SCM_RIGHTS`.** Exploitation\n requires a local process already connected over a Unix domain socket to the target, which never\n exists here.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince Solr never establishes a Unix-domain-socket channel through Netty, this native code path is\npresent on the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 8.3.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-47244" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-47244 (CVSS 5.3, CWE-400) is a resource-exhaustion issue in `netty-codec-http2`:\n`DefaultHttp2Connection.DefaultEndpoint` initializes `maxActiveStreams`/`maxStreams` to\n`Integer.MAX_VALUE`, and `Http2Settings` doesn't enforce `SETTINGS_MAX_CONCURRENT_STREAMS` unless\nan application explicitly configures it. A peer can open hundreds of thousands of stream objects on\na single TCP connection, the same amplification pattern as the 2023 HTTP/2 \"Rapid Reset\" family\n(CVE-2023-44487) \u2014 this is a **server-side** concern, since it's the endpoint *accepting* streams\nwhose limit matters. It affects Netty before 4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in\n4.1.135.Final and 4.2.15.Final.\n\nSolr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http2-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\nSolr is **not affected**:\n\n* **Solr never runs an HTTP/2 server.** The unbounded-streams condition only matters for the local\n endpoint that accepts streams opened by a remote peer. Solr's only Netty/HTTP2 channel is\n `grpc-netty`'s outbound OTLP client \u2014 Solr is the one *opening* streams (its own trace-export\n RPCs), not accepting an unbounded number of them from arbitrary attackers.\n* **The remote peer is a single, operator-configured collector, not an open attack surface.** Even\n in the worst case of a malicious or compromised collector opening many streams back at the\n client, that's a single trusted, operator-chosen endpoint \u2014 not the \"hundreds of thousands of\n streams from an internet-facing listener\" amplification scenario this CVE targets.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince Solr never accepts inbound HTTP/2 connections through Netty, the vulnerable code is present\non the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-47691" }, "products": [ { "@id": "pkg:maven/org.apache.solr/solr-core" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_present", "impact_statement": "CVE-2026-47691 (CVSS up to 10.0, CWE-345 / CWE-346) is a DNS cache-poisoning issue in Netty's\nasynchronous DNS resolver (`io.netty:netty-resolver-dns`): it accepts any NS record from a DNS\nresponse's AUTHORITY section as long as its name is a suffix of the question name, without properly\nvalidating that the record is actually in that nameserver's bailiwick, then caches the associated A\nrecords directly. An attacker who controls an authoritative nameserver for any subdomain can use\nthis to poison the resolver's cache for parent domains. It affects Netty before 4.1.135.Final and\n4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\nThis CVE does not apply to Solr at all \u2014 `netty-resolver-dns` isn't in Solr's dependency graph in\nthe first place. Solr's transitive Netty footprint (via `grpc-netty`, the optional `opentelemetry`\nmodule's OTLP gRPC exporter) pulls in the generic `io.netty:netty-resolver` API module, but never\n`netty-resolver-dns`, the separate artifact that contains the actual DNS resolver implementation\nthis CVE lives in. Neither Solr nor any of its other dependencies (ZooKeeper, gRPC, etc.) uses\nNetty for DNS resolution \u2014 name lookups go through the JDK's standard `InetAddress`/`java.net`\nmachinery instead. Solr is **not affected**: the vulnerable component is not shipped, in any\nversion, on any Solr release line." }, { "vulnerability": { "name": "CVE-2026-48043" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-48043 (CVSS up to 7.5, CWE-400 / CWE-401 / CWE-772) is a resource-leak issue in\n`netty-codec-http2`'s `DelegatingDecompressorFrameListener`: it decompresses `gzip`/`deflate`/`zstd`\nHTTP/2 message bodies using a per-stream embedded channel, but when a flow-controller exception\noccurs, the pooled `ByteBuf`s involved aren't released \u2014 repeated triggering leaks pooled memory\nand can eventually crash the JVM with an OOM. `DelegatingDecompressorFrameListener` is an opt-in\nlistener applications install to get automatic content-encoding-based decompression for generic\nHTTP/2 traffic; it affects Netty before 4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in\n4.1.135.Final and 4.2.15.Final.\n\nSolr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http2-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\nSolr is **not affected**:\n\n* **`grpc-netty` never installs `DelegatingDecompressorFrameListener`.** gRPC has its own\n message-level compression framework, negotiated via `grpc-encoding` request/response metadata and\n handled by grpc's own `Codec`/`Compressor` classes \u2014 it doesn't route through Netty's generic\n HTTP/2 content-encoding auto-decompression listener at all.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources, so nothing in Solr itself installs this listener either.\n\nSince `DelegatingDecompressorFrameListener` is never installed in any pipeline Solr's dependencies\nconstruct, the vulnerable code is present on the classpath but not reachable in any real Solr\ndeployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-50010" }, "products": [ { "@id": "pkg:maven/io.netty/netty-handler@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.29.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.47.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.50.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.68.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.82.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "impact_statement": "CVE-2026-50010 (CVSS 7.5, CWE-347) is a TLS hostname-verification bypass in `netty-handler`:\n`SimpleTrustManagerFactory` wraps a user-supplied `X509TrustManager` in an adapter that extends\n`X509ExtendedTrustManager` (required by the JDK's `SSLEngine`) but discards the `SSLEngine`\nparameters during certificate validation. Because those parameters carry the endpoint identity\nJava uses for hostname checking, wrapping a *custom* trust manager this way silently disables\nhostname verification \u2014 even when `endpointIdentificationAlgorithm` is set to `HTTPS` (Netty\n4.2's own default) \u2014 leaving the connection open to a man-in-the-middle who presents any\nCA-trusted certificate, valid hostname or not. This wrapper only fires when an application supplies\nits **own** `TrustManager`/certificate to Netty's `SslContextBuilder`; Netty's normal path of\nloading the platform's default trust store never goes through it. It affects Netty before\n4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\nSolr has shipped `netty-handler` \u2014 the modular jar this CVE concerns \u2014 since **8.3.0** (SOLR-13665,\n`netty-handler-4.2.6.Final.jar` in the current 9.10.x/10.0.x lines), as a transitive dependency of\n**Apache ZooKeeper**'s client library (earlier Solr releases, 7.x through 8.2.x, already shipped\nthis same `SimpleTrustManagerFactory` class too, bundled in the older `netty-all` uber-jar). None of\nthat matters for this specific CVE, though: the vulnerable scenario only becomes *possible* starting\nin **9.2.0**, when the optional `opentelemetry` module (and its `grpc-netty` OTLP exporter) was\nintroduced \u2014 Solr versions before 9.2.0 don't have this module at all. CVE-2026-50010 is **not**\nconsidered exploitable in typical deployments of Apache Solr. Successful exploitation requires a\nspecific, non-default configuration together with a privileged network position:\n\n* The `opentelemetry` module is enabled **and** the operator has configured a custom trusted\n certificate for the OTLP collector connection (e.g. via `OTEL_EXPORTER_OTLP_CERTIFICATE`, used to\n trust a private/internal CA or self-signed collector certificate). That certificate-override path\n is exactly what causes the OTLP exporter's `NettyChannelBuilder` to build its `SslContext` via\n Netty's `SslContextBuilder.trustManager(...)`, the code path this bug affects.\n* A man-in-the-middle attacker able to intercept the connection to the configured OTLP endpoint\n presents a certificate issued by that same trusted CA, for any hostname.\n\nSolr's default configuration ships the `opentelemetry` module disabled, and even when enabled, OTLP\nexport defaults to the JVM's ordinary default trust store \u2014 which loads trust managers through the\nplatform `TrustManagerFactory`, not Netty's `SimpleTrustManagerFactory` wrapper, and is therefore\nunaffected. Only operators who have both enabled OTLP tracing *and* pointed it at a custom trusted\ncertificate are exposed, and even then only to an attacker already positioned to intercept that\nspecific outbound connection.\n\nOperators who do configure a custom OTLP trusted certificate should either restrict network access\nto the collector endpoint (e.g. a private network path with no attacker-reachable intercept point)\nuntil upgrading, or upgrade the bundled Netty once a Solr release ships 4.1.135.Final/4.2.15.Final \u2014\nalready present on the `branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but\nnot yet in any released Solr line.", "status_notes": "Affected Apache Solr versions: 8.3.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-50020" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-50020 (CVSS 5.3, CWE-444) is a request-smuggling issue in `netty-codec-http`'s\n`HttpObjectDecoder`: before parsing a request line, it skips leading control characters\n(0x00\u20130x1F and 0x7F) and whitespace, more permissive than RFC 9112, which only allows ignoring an\nempty leading CRLF. This over-tolerant framing can let a crafted request boundary be interpreted\ndifferently by Netty than by a front-end intermediary. It affects Netty before 4.1.135.Final and\n4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and 4.2.15.Final.\n\nSolr has shipped a vulnerable `netty-codec-http` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\n`HttpObjectDecoder` itself isn't new at that point \u2014 earlier Solr releases (7.x through 8.2.x)\nalready shipped this same class, bundled in the older `netty-all` uber-jar. This is a\n**decoder**-side issue \u2014 it only bites when Netty parses an inbound HTTP/1.x request. Solr is\n**not affected**:\n\n* **Solr's HTTP server is Jetty, not Netty.** Inbound requests to Solr's REST APIs never reach a\n Netty decoder; `SolrDispatchFilter` and Jetty's own `HttpParser` handle every attacker-facing\n request.\n* **The OTLP gRPC path never parses HTTP/1.x requests.** gRPC traffic is HTTP/2 framed, and Solr's\n outbound gRPC client only ever decodes a proxy's CONNECT *response* (if a proxy is configured at\n all, an optional non-default setup), never an inbound HTTP/1.x request.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince there is no attacker-reachable path where Solr (or its dependencies) ever decodes an\nattacker-supplied HTTP/1.x request through this Netty codec, the vulnerable code is present on the\nclasspath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "CVE-2026-50560" }, "products": [ { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.104.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.108.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.111.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.114.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.89.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.93.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.1.99.Final" }, { "@id": "pkg:maven/io.netty/netty-codec-http2@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-50560 (CVSS 5.3, CWE-770) is a resource-exhaustion issue in `netty-codec-http2`, in the\nsame \"HTTP/2 Rapid Reset\" family of attacks as the 2023 stream-reset issue (CVE-2023-44487) but\nwith a different trigger: a client that advertises `SETTINGS_MAX_HEADER_LIST_SIZE` can cause the\nserver to read a request, start proxying/processing it, attempt to generate a response, and then\nthrow an exception while writing the response headers \u2014 repeating this cheaply, many times, wastes\nserver-side resources with a different signature than a classic stream reset. This is a\n**server-side** concern: it targets the endpoint accepting and processing inbound requests. It\naffects Netty before 4.1.135.Final and 4.2.0.Final\u20134.2.14.Final; fixed in 4.1.135.Final and\n4.2.15.Final.\n\nSolr has shipped a vulnerable `netty-codec-http2` since 9.2.0 (4.1.x through 9.9.0, 4.2.x \u2014\n`netty-codec-http2-4.2.6.Final.jar` \u2014 from 9.10.0/10.0.0 onward), arriving as a transitive runtime\ndependency of `grpc-netty`, used only by the optional `opentelemetry` module's OTLP gRPC exporter.\nSolr is **not affected**:\n\n* **Solr never runs an HTTP/2 server.** This attack requires a server that reads and attempts to\n process many abusive client requests. Solr's only Netty/HTTP2 channel is `grpc-netty`'s outbound\n OTLP client \u2014 Solr is the one sending requests to a single, operator-configured collector, not\n accepting them from arbitrary attackers.\n* **Solr's own code never touches Netty.** There are no `io.netty` imports anywhere in Solr's Java\n sources.\n\nSince Solr never accepts inbound HTTP/2 connections through Netty, the vulnerable code is present\non the classpath but not reachable in any real Solr deployment.\n\nNo released Solr version ships the fix. The fixed Netty (4.2.15.Final) is already present on the\n`branch_9x` (\u2192 9.11.0) and `branch_10x` (\u2192 10.1.0) development branches, but hasn't reached a\nreleased line yet.", "status_notes": "Affected Apache Solr versions: 9.2.0-9.10.x,10.0.x." }, { "vulnerability": { "name": "GHSA-72hv-8253-57qq" }, "products": [ { "@id": "jackson-core-2.20.0.jar" } ], "status": "not_affected", "timestamp": "2026-07-18T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "GHSA-72hv-8253-57qq is a DoS vulnerability in the non-blocking (async) JSON parser API of jackson-core (NonBlockingByteArrayJsonParser), which bypasses the maxNumberLength constraint. Exploitation requires an application to use the async/non-blocking parser API (factory.createNonBlockingByteArrayParser()). Solr uses the standard synchronous Jackson parser to deserialize JSON from HTTP request bodies and internal data structures. Solr is built on Jetty with synchronous request handling, not a reactive framework. The async parser API is not used anywhere in Solr's codebase. The synchronous parser correctly enforces the maxNumberLength constraint and is not affected.\n\nGHSA-72hv-8253-57qq affects jackson-core releases before 2.18.6 and the 2.19.0 through 2.21.0 line\n(fixed in 2.18.6 and 2.21.1). Solr has bundled jackson-core (alongside `jackson-databind`, which it\nships in lockstep with) since Solr 4.7.0, and every release through 10.0.0 ships an affected version\n(2.3.1 through 2.18.0, then 2.20.0). The affected range is therefore 4.7.0 \u2013 10.0.0.", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." } ] }