{ "@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-08-25T00: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" }, "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-2018-1324" }, "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-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" }, "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-2016-6293" }, "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-2016-7415" }, "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-2017-14952" }, "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-2017-17484" }, "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-2017-7867" }, "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-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" }, "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-1181" }, "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-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" }, "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-2018-1335" }, "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-2018-1338" }, "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-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" }, "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-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" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2017-17485" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2017-7525" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2018-5968" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2018-7489" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2019-12086" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2019-12384" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2018-12814" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2019-14379" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2019-14439" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2020-35490" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2020-35491" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2021-20190" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "CVE-2019-14540" }, "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "vulnerability": { "name": "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.\n\nAll 15 are pre-block-list \"individual gadget\" CVEs, fixed in jackson-databind \u2264 2.9.10.7 / \u2264 2.10.5.1 (the latest, CVE-2021-20190, in 2.10.5.1). Solr's **standalone** `jackson-databind` \u2014 the `jackson-databind-*.jar` this statement covers \u2014 was within that range from 4.7.0 through Solr **8.6.3**: 2.9.x up to 8.3.1, then 2.10.0 / 2.10.1 through 8.6.3 (all < 2.10.5.1). Solr 8.7.0 moved to jackson-databind 2.11.2 \u2014 past the fix \u2014 and 9.x / 10.x ship 2.13+ / 2.20, so from 8.7.0 onward the standalone copy is no longer flagged for these CVEs. (The separate old 2.x copy shaded inside `htrace-core4`, which spans the full 8.x line, is tracked in SOLR-17236 \u2014 see below.)\n\nSOLR-17236 tracks this same class of jackson-databind deserialization CVEs for the old 2.x copy shaded inside Hadoop's `htrace-core4` jar in the 8.x line; the same reasoning applies, and `htrace-core4` (with its bundled jackson-databind) was removed in Solr 9.x.", "status_notes": "Affected Apache Solr versions: 4.7.0-8.6.3." }, { "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" }, "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-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" }, "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-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" }, "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": "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": "not_affected", "timestamp": "2025-08-02T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "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\nSolr is **not affected**. The crafted-message DoS requires an attacker to feed protobuf input to a\nparser, and Solr exposes no such path:\n\n* **Solr's own code never uses protobuf.** There is no `com.google.protobuf` usage anywhere in the\n Solr codebase, and Solr's client-facing APIs speak javabin, JSON and XML \u2014 never protobuf. The SQL\n module is reached through `SQLHandler` (Calcite runs in-process, returning tuples); Solr exposes no\n Avatica/protobuf wire endpoint to clients.\n* **protobuf-java is only used to talk to trusted infrastructure.** It is pulled in transitively for\n communication with operator-controlled endpoints \u2014 the ZooKeeper ensemble, Hadoop RPC (HDFS /\n Kerberos), the Google Cloud Storage backup API, the OpenTelemetry OTLP collector, and the Kafka\n cross-DC pipeline. An external attacker cannot supply the deeply-nested message the DoS requires to\n any of those parsers.\n\nTracked upstream as SOLR-17833.\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**.", "status_notes": "Affected Apache Solr versions: 4.4.0-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-2020-13949" }, "products": [ { "@id": "libthrift-0.13.0.jar" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2020-13949 is a denial-of-service issue in Apache Thrift: a malicious RPC **client** can send\nspecially-crafted short messages that cause a Thrift **server** to allocate a large amount of memory,\npotentially exhausting it (affects `libthrift` 0.9.3 \u2013 0.13.0, fixed in 0.14.0). It is reachable only\nby an application that runs a Thrift server accepting messages from untrusted clients.\n\nSolr is **not affected**. `libthrift` is bundled only by the optional Jaeger distributed-tracing\nintegration, where Solr uses Thrift purely as a **client** to export spans to an operator-configured\nJaeger collector \u2014 it never runs a Thrift RPC server that accepts untrusted incoming messages. The\nvulnerable server-side allocation path is therefore never reached.\n\nSolr shipped an affected `libthrift` in the 8.x line \u2014 0.12.0 (8.2.0 \u2013 8.4.1) and 0.13.0 (8.5.0 \u2013\n8.11.0), both \u2264 0.13.0 \u2014 so the affected range is 8.2.0 \u2013 8.11.0. Solr **8.11.1** upgraded the 8.x\nline to `libthrift` 0.14.1 (past the 0.14.0 fix), and Solr 9.0.0 likewise ships 0.14.1 (later 0.15.0),\nso no 8.11.1+, 9.x, or 10.x release is affected. (The Solr 8.x line is end of life.) Note that\nSOLR-15507 \u2014 which proposed the upgrade and observed that Solr 8.9.0 still bundled `libthrift` 0.13.0 \u2014\nremains open with no fix version, but the upgrade was in fact delivered in 8.11.1 (verified against the\n`solr:8.11.0` and `solr:8.11.1` release images).", "status_notes": "Affected Apache Solr versions: 8.2.0-8.11.0." }, { "vulnerability": { "name": "CVE-2021-41182" }, "products": [ { "@id": "jquery-ui-1.12.1.js" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Three XSS issues in jQuery UI 1.12.1 (all fixed in 1.13.x):\n\n* **CVE-2021-41182** \u2014 XSS via the datepicker `altField` option.\n* **CVE-2021-41183** \u2014 XSS via the datepicker `*Text` options.\n* **CVE-2021-41184** \u2014 XSS via the `.position()` `of` option.\n\nSolr's Admin UI bundles a **custom subset** of jQuery UI (`server/solr-webapp/webapp/libs/jquery-ui.min.js`,\nv1.12.1) from Solr 7.5.0 through 10.0.0. Solr is **not affected**:\n\n* **The datepicker widget is not included.** Solr's build excludes datepicker entirely (it is absent\n from the shipped `jquery-ui.min.js`), so CVE-2021-41182 and CVE-2021-41183 \u2014 both datepicker-only \u2014\n have no code present to exploit.\n* **The position utility is included, but not reachable with attacker input.** CVE-2021-41184\n requires passing attacker-controlled markup to the `of` option of `.position()`. Solr's Admin UI\n invokes positioning (for tooltips/dialogs) only with its own static, trusted selectors, never with\n externally-supplied values. The Admin UI is also an operator-facing console, not an\n unauthenticated public surface.\n\n> Note: this is a **front-end JavaScript** dependency, not a Maven artifact. This entry documents\n> Solr's assessment for the record; unlike the Java-jar entries it does not emit a matchable Maven\n> purl, and Docker Scout does not flag the bundled minified JS. It corresponds to SOLR-16309, whose\n> reporter likewise characterized it as a compliance finding rather than an exploitable risk.", "status_notes": "Affected Apache Solr versions: 7.5.0-10.0.0." }, { "vulnerability": { "name": "CVE-2021-41183" }, "products": [ { "@id": "jquery-ui-1.12.1.js" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Three XSS issues in jQuery UI 1.12.1 (all fixed in 1.13.x):\n\n* **CVE-2021-41182** \u2014 XSS via the datepicker `altField` option.\n* **CVE-2021-41183** \u2014 XSS via the datepicker `*Text` options.\n* **CVE-2021-41184** \u2014 XSS via the `.position()` `of` option.\n\nSolr's Admin UI bundles a **custom subset** of jQuery UI (`server/solr-webapp/webapp/libs/jquery-ui.min.js`,\nv1.12.1) from Solr 7.5.0 through 10.0.0. Solr is **not affected**:\n\n* **The datepicker widget is not included.** Solr's build excludes datepicker entirely (it is absent\n from the shipped `jquery-ui.min.js`), so CVE-2021-41182 and CVE-2021-41183 \u2014 both datepicker-only \u2014\n have no code present to exploit.\n* **The position utility is included, but not reachable with attacker input.** CVE-2021-41184\n requires passing attacker-controlled markup to the `of` option of `.position()`. Solr's Admin UI\n invokes positioning (for tooltips/dialogs) only with its own static, trusted selectors, never with\n externally-supplied values. The Admin UI is also an operator-facing console, not an\n unauthenticated public surface.\n\n> Note: this is a **front-end JavaScript** dependency, not a Maven artifact. This entry documents\n> Solr's assessment for the record; unlike the Java-jar entries it does not emit a matchable Maven\n> purl, and Docker Scout does not flag the bundled minified JS. It corresponds to SOLR-16309, whose\n> reporter likewise characterized it as a compliance finding rather than an exploitable risk.", "status_notes": "Affected Apache Solr versions: 7.5.0-10.0.0." }, { "vulnerability": { "name": "CVE-2021-41184" }, "products": [ { "@id": "jquery-ui-1.12.1.js" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Three XSS issues in jQuery UI 1.12.1 (all fixed in 1.13.x):\n\n* **CVE-2021-41182** \u2014 XSS via the datepicker `altField` option.\n* **CVE-2021-41183** \u2014 XSS via the datepicker `*Text` options.\n* **CVE-2021-41184** \u2014 XSS via the `.position()` `of` option.\n\nSolr's Admin UI bundles a **custom subset** of jQuery UI (`server/solr-webapp/webapp/libs/jquery-ui.min.js`,\nv1.12.1) from Solr 7.5.0 through 10.0.0. Solr is **not affected**:\n\n* **The datepicker widget is not included.** Solr's build excludes datepicker entirely (it is absent\n from the shipped `jquery-ui.min.js`), so CVE-2021-41182 and CVE-2021-41183 \u2014 both datepicker-only \u2014\n have no code present to exploit.\n* **The position utility is included, but not reachable with attacker input.** CVE-2021-41184\n requires passing attacker-controlled markup to the `of` option of `.position()`. Solr's Admin UI\n invokes positioning (for tooltips/dialogs) only with its own static, trusted selectors, never with\n externally-supplied values. The Admin UI is also an operator-facing console, not an\n unauthenticated public surface.\n\n> Note: this is a **front-end JavaScript** dependency, not a Maven artifact. This entry documents\n> Solr's assessment for the record; unlike the Java-jar entries it does not emit a matchable Maven\n> purl, and Docker Scout does not flag the bundled minified JS. It corresponds to SOLR-16309, whose\n> reporter likewise characterized it as a compliance finding rather than an exploitable risk.", "status_notes": "Affected Apache Solr versions: 7.5.0-10.0.0." }, { "vulnerability": { "name": "CVE-2023-33201" }, "products": [ { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.54" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.60" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.64" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.65" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Four vulnerabilities in the Bouncy Castle crypto provider (`org.bouncycastle:bcprov-jdk15on`),\neach in a distinct crypto operation:\n\n* **CVE-2023-33201** \u2014 LDAP injection in the X.509 `CertStore` (fixed in 1.74); requires using Bouncy\n Castle's LDAP-backed `CertStore` for certificate lookups.\n* **CVE-2024-29857** \u2014 importing an EC certificate with crafted F2m parameters causes CPU exhaustion\n (fixed in 1.78); requires parsing/importing an attacker-supplied EC certificate.\n* **CVE-2024-30171** \u2014 RSA/TLS timing side-channel (\"Marvin\"; fixed in 1.78); requires using Bouncy\n Castle as the **TLS/JSSE provider** with an attacker able to time RSA handshake responses.\n* **CVE-2024-30172** \u2014 infinite loop verifying a crafted Ed25519 signature (fixed in 1.78); requires\n verifying an attacker-supplied Ed25519 signature.\n\nSolr is **not affected**. Bouncy Castle (`bcprov`/`bcpkix`/`bcmail`/`bcutil`) is bundled only by the\noptional **extraction (Solr Cell)** module, where Apache Tika / PDFBox use it to handle encrypted or\ndigitally-signed PDFs during document parsing. Solr does not use Bouncy Castle as a security provider\nin any of the ways these CVEs require:\n\n* Solr's TLS is served by the JVM's default JSSE provider, **not** Bouncy Castle, so the RSA timing\n side-channel (CVE-2024-30171) has no Solr-reachable surface.\n* Solr never configures an LDAP `CertStore` (CVE-2023-33201), never imports attacker-supplied EC\n certificates (CVE-2024-29857), and never verifies standalone Ed25519 signatures (CVE-2024-30172).\n* Tika's text/metadata **extraction** does not exercise TLS, LDAP certificate lookup, EC-certificate\n import, or Ed25519 signature verification, so even with Solr Cell enabled none of the vulnerable\n code paths are reached.\n\nSolr shipped an affected `bcprov-jdk15on` via Solr Cell from 7.3.0 (1.54) through 9.10.1 (1.70) \u2014 all\nbelow the fixed 1.74/1.78. Solr 10.0.0 upgraded the extraction stack to Tika 3.x, whose PDFBox no\nlonger bundles Bouncy Castle, so 10.x ships no `bcprov` at all. The affected range is therefore\n7.3.0 \u2013 9.10.1. (Solr 9.5\u20139.6 also briefly bundled a separate `bcprov-jdk18on` 1.77 for another\nmodule, fixed to 1.78.1 in 9.7; the same not-affected reasoning applies.)", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1." }, { "vulnerability": { "name": "CVE-2024-29857" }, "products": [ { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.54" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.60" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.64" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.65" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Four vulnerabilities in the Bouncy Castle crypto provider (`org.bouncycastle:bcprov-jdk15on`),\neach in a distinct crypto operation:\n\n* **CVE-2023-33201** \u2014 LDAP injection in the X.509 `CertStore` (fixed in 1.74); requires using Bouncy\n Castle's LDAP-backed `CertStore` for certificate lookups.\n* **CVE-2024-29857** \u2014 importing an EC certificate with crafted F2m parameters causes CPU exhaustion\n (fixed in 1.78); requires parsing/importing an attacker-supplied EC certificate.\n* **CVE-2024-30171** \u2014 RSA/TLS timing side-channel (\"Marvin\"; fixed in 1.78); requires using Bouncy\n Castle as the **TLS/JSSE provider** with an attacker able to time RSA handshake responses.\n* **CVE-2024-30172** \u2014 infinite loop verifying a crafted Ed25519 signature (fixed in 1.78); requires\n verifying an attacker-supplied Ed25519 signature.\n\nSolr is **not affected**. Bouncy Castle (`bcprov`/`bcpkix`/`bcmail`/`bcutil`) is bundled only by the\noptional **extraction (Solr Cell)** module, where Apache Tika / PDFBox use it to handle encrypted or\ndigitally-signed PDFs during document parsing. Solr does not use Bouncy Castle as a security provider\nin any of the ways these CVEs require:\n\n* Solr's TLS is served by the JVM's default JSSE provider, **not** Bouncy Castle, so the RSA timing\n side-channel (CVE-2024-30171) has no Solr-reachable surface.\n* Solr never configures an LDAP `CertStore` (CVE-2023-33201), never imports attacker-supplied EC\n certificates (CVE-2024-29857), and never verifies standalone Ed25519 signatures (CVE-2024-30172).\n* Tika's text/metadata **extraction** does not exercise TLS, LDAP certificate lookup, EC-certificate\n import, or Ed25519 signature verification, so even with Solr Cell enabled none of the vulnerable\n code paths are reached.\n\nSolr shipped an affected `bcprov-jdk15on` via Solr Cell from 7.3.0 (1.54) through 9.10.1 (1.70) \u2014 all\nbelow the fixed 1.74/1.78. Solr 10.0.0 upgraded the extraction stack to Tika 3.x, whose PDFBox no\nlonger bundles Bouncy Castle, so 10.x ships no `bcprov` at all. The affected range is therefore\n7.3.0 \u2013 9.10.1. (Solr 9.5\u20139.6 also briefly bundled a separate `bcprov-jdk18on` 1.77 for another\nmodule, fixed to 1.78.1 in 9.7; the same not-affected reasoning applies.)", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1." }, { "vulnerability": { "name": "CVE-2024-30171" }, "products": [ { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.54" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.60" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.64" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.65" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Four vulnerabilities in the Bouncy Castle crypto provider (`org.bouncycastle:bcprov-jdk15on`),\neach in a distinct crypto operation:\n\n* **CVE-2023-33201** \u2014 LDAP injection in the X.509 `CertStore` (fixed in 1.74); requires using Bouncy\n Castle's LDAP-backed `CertStore` for certificate lookups.\n* **CVE-2024-29857** \u2014 importing an EC certificate with crafted F2m parameters causes CPU exhaustion\n (fixed in 1.78); requires parsing/importing an attacker-supplied EC certificate.\n* **CVE-2024-30171** \u2014 RSA/TLS timing side-channel (\"Marvin\"; fixed in 1.78); requires using Bouncy\n Castle as the **TLS/JSSE provider** with an attacker able to time RSA handshake responses.\n* **CVE-2024-30172** \u2014 infinite loop verifying a crafted Ed25519 signature (fixed in 1.78); requires\n verifying an attacker-supplied Ed25519 signature.\n\nSolr is **not affected**. Bouncy Castle (`bcprov`/`bcpkix`/`bcmail`/`bcutil`) is bundled only by the\noptional **extraction (Solr Cell)** module, where Apache Tika / PDFBox use it to handle encrypted or\ndigitally-signed PDFs during document parsing. Solr does not use Bouncy Castle as a security provider\nin any of the ways these CVEs require:\n\n* Solr's TLS is served by the JVM's default JSSE provider, **not** Bouncy Castle, so the RSA timing\n side-channel (CVE-2024-30171) has no Solr-reachable surface.\n* Solr never configures an LDAP `CertStore` (CVE-2023-33201), never imports attacker-supplied EC\n certificates (CVE-2024-29857), and never verifies standalone Ed25519 signatures (CVE-2024-30172).\n* Tika's text/metadata **extraction** does not exercise TLS, LDAP certificate lookup, EC-certificate\n import, or Ed25519 signature verification, so even with Solr Cell enabled none of the vulnerable\n code paths are reached.\n\nSolr shipped an affected `bcprov-jdk15on` via Solr Cell from 7.3.0 (1.54) through 9.10.1 (1.70) \u2014 all\nbelow the fixed 1.74/1.78. Solr 10.0.0 upgraded the extraction stack to Tika 3.x, whose PDFBox no\nlonger bundles Bouncy Castle, so 10.x ships no `bcprov` at all. The affected range is therefore\n7.3.0 \u2013 9.10.1. (Solr 9.5\u20139.6 also briefly bundled a separate `bcprov-jdk18on` 1.77 for another\nmodule, fixed to 1.78.1 in 9.7; the same not-affected reasoning applies.)", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1." }, { "vulnerability": { "name": "CVE-2024-30172" }, "products": [ { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.54" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.60" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.64" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.65" }, { "@id": "pkg:maven/org.bouncycastle/bcprov-jdk15on@1.70" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Four vulnerabilities in the Bouncy Castle crypto provider (`org.bouncycastle:bcprov-jdk15on`),\neach in a distinct crypto operation:\n\n* **CVE-2023-33201** \u2014 LDAP injection in the X.509 `CertStore` (fixed in 1.74); requires using Bouncy\n Castle's LDAP-backed `CertStore` for certificate lookups.\n* **CVE-2024-29857** \u2014 importing an EC certificate with crafted F2m parameters causes CPU exhaustion\n (fixed in 1.78); requires parsing/importing an attacker-supplied EC certificate.\n* **CVE-2024-30171** \u2014 RSA/TLS timing side-channel (\"Marvin\"; fixed in 1.78); requires using Bouncy\n Castle as the **TLS/JSSE provider** with an attacker able to time RSA handshake responses.\n* **CVE-2024-30172** \u2014 infinite loop verifying a crafted Ed25519 signature (fixed in 1.78); requires\n verifying an attacker-supplied Ed25519 signature.\n\nSolr is **not affected**. Bouncy Castle (`bcprov`/`bcpkix`/`bcmail`/`bcutil`) is bundled only by the\noptional **extraction (Solr Cell)** module, where Apache Tika / PDFBox use it to handle encrypted or\ndigitally-signed PDFs during document parsing. Solr does not use Bouncy Castle as a security provider\nin any of the ways these CVEs require:\n\n* Solr's TLS is served by the JVM's default JSSE provider, **not** Bouncy Castle, so the RSA timing\n side-channel (CVE-2024-30171) has no Solr-reachable surface.\n* Solr never configures an LDAP `CertStore` (CVE-2023-33201), never imports attacker-supplied EC\n certificates (CVE-2024-29857), and never verifies standalone Ed25519 signatures (CVE-2024-30172).\n* Tika's text/metadata **extraction** does not exercise TLS, LDAP certificate lookup, EC-certificate\n import, or Ed25519 signature verification, so even with Solr Cell enabled none of the vulnerable\n code paths are reached.\n\nSolr shipped an affected `bcprov-jdk15on` via Solr Cell from 7.3.0 (1.54) through 9.10.1 (1.70) \u2014 all\nbelow the fixed 1.74/1.78. Solr 10.0.0 upgraded the extraction stack to Tika 3.x, whose PDFBox no\nlonger bundles Bouncy Castle, so 10.x ships no `bcprov` at all. The affected range is therefore\n7.3.0 \u2013 9.10.1. (Solr 9.5\u20139.6 also briefly bundled a separate `bcprov-jdk18on` 1.77 for another\nmodule, fixed to 1.78.1 in 9.7; the same not-affected reasoning applies.)", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1." }, { "vulnerability": { "name": "CVE-2023-52428" }, "products": [ { "@id": "nimbus-jose-jwt-9.31.jar" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2023-52428 (CVSS 8.7) is a denial-of-service issue in Nimbus JOSE + JWT: parsing a crafted JOSE\nobject (for example a PBES2-encrypted JWE with a huge `p2c` iteration count, or a large deeply-nested\nstructure) can consume excessive resources (fixed in 9.37.2). It is only reachable when an\napplication parses attacker-supplied JOSE/JWT input with Nimbus.\n\nSolr is **not affected**. Solr's own JWT authentication (the optional `jwt-auth` module,\n`JWTAuthPlugin`) parses tokens with **jose4j**, not Nimbus (see CVE-2025-53864). The Nimbus copy a\nscanner flags (`nimbus-jose-jwt@9.31`) is shaded inside `hadoop-client-runtime` in the optional\n`hdfs` module and is only used by Hadoop's own internal auth machinery \u2014 Solr never routes an\nuntrusted, externally-supplied JOSE object to it. The vulnerable parser is therefore not reached. The\naffected range spans the releases whose `hdfs` module bundles an affected shaded Nimbus \u2014 Solr\n9.0.0 \u2013 9.9.0 (`hadoop-client-runtime` 3.3.2 \u2013 3.4.0, shading Nimbus \u2264 9.31). Solr 9.10.0 upgraded to\nHadoop 3.4.1, whose `hadoop-client-runtime` shades the fixed Nimbus 9.37.2, and Solr 10.x ships no\n`hadoop-client-runtime`, so neither is affected.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2024-21742" }, "products": [ { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.7" }, { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.7.2" }, { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.8.1" }, { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.8.2" }, { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.8.3" }, { "@id": "pkg:maven/org.apache.james/apache-mime4j-core@0.8.4" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-21742 (CVSS 5.3) is a header-injection issue in Apache James MIME4J: when the library is\nused to **compose / write** MIME messages, improper input validation lets crafted field values inject\nunintended headers into the produced message. It affects `apache-mime4j` before 0.8.10 (fixed in\n0.8.10), and is only reachable through MIME4J's message-**building** API (MIME4J DOM composition).\n\nSolr is **not affected**. `apache-mime4j-core` is bundled only by the optional **extraction (Solr\nCell)** module, where Apache Tika uses MIME4J solely to **parse** documents (for example to extract\ntext from `.eml` / RFC-822 messages). Neither Solr nor Tika ever uses MIME4J to *compose* or write\nMIME messages, so the vulnerable message-building / header-injection code path is never invoked \u2014\nregardless of whether the (non-default, not-recommended-for-production) Solr Cell module is enabled.\n\nSolr has bundled an affected `apache-mime4j-core` via Solr Cell from Solr 3.6.0 (0.7) through 9.10.1\n(0.8.4) \u2014 all below the fixed 0.8.10. Solr 10.x ships no MIME4J. The affected range is therefore\n3.6.0 \u2013 9.10.1, but the composition code path this CVE requires is not exercised in any of them.\nOperators who run Solr Cell can additionally follow the project's guidance to perform document\nextraction in a separate Tika service, or replace `modules/extraction/lib/apache-mime4j-*.jar` with\n0.8.10 or later.", "status_notes": "Affected Apache Solr versions: 3.6.0-9.10.1." }, { "vulnerability": { "name": "CVE-2024-25638" }, "products": [ { "@id": "dnsjava-3.4.0.jar" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-25638 (CVSS 7.0) is a DNSSEC-validation bypass in dnsjava: a resolver relying on dnsjava to\nvalidate DNSSEC could be tricked into accepting spoofed records (affects dnsjava < 3.6.0). It matters\nonly for an application that uses dnsjava as its resolver and relies on its DNSSEC validation for a\nsecurity decision.\n\nSolr is **not affected**. dnsjava is not a Solr dependency in its own right \u2014 it is shaded inside\n`hadoop-client-runtime` (reported by scanners as `dnsjava@3.4.0`) in the optional `hdfs` module,\nwhere Hadoop may use it for name resolution. Solr uses the HDFS module only as a **client** that\nconnects to operator-configured HDFS NameNode/DataNode hosts, not attacker-controlled names, and it\ndoes not rely on dnsjava's DNSSEC validation to make any security decision. The vulnerable resolver\npath is therefore not reached. The affected range spans the releases whose `hdfs` module bundles an\naffected shaded dnsjava \u2014 Solr 9.0.0 \u2013 9.9.0 (`hadoop-client-runtime` 3.3.2 \u2013 3.4.0, shading dnsjava\n\u2264 3.4.0). Solr 9.10.0 upgraded to Hadoop 3.4.1, whose `hadoop-client-runtime` shades the fixed dnsjava\n3.6.1, and Solr 10.x ships no `hadoop-client-runtime`, so neither is affected.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2024-26308" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-compress@1.21" }, { "@id": "pkg:maven/org.apache.commons/commons-compress@1.22" }, { "@id": "pkg:maven/org.apache.commons/commons-compress@1.23.0" }, { "@id": "pkg:maven/org.apache.commons/commons-compress@1.24.0" }, { "@id": "pkg:maven/org.apache.commons/commons-compress@1.25.0" }, { "@id": "pkg:maven/org.apache.commons/commons-compress@1.26.1" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-26308 (CVSS 6.7) is a denial-of-service issue in Apache Commons Compress: unpacking a\nmalformed **Pack200** (`.pack`/`.pack.gz`) stream can allocate excessive memory and throw\n`OutOfMemoryError` (affects 1.21 through 1.25.0, fixed in 1.26.0). It is reachable only when an\napplication uses Commons Compress to unpack an attacker-supplied Pack200 archive.\n\nSolr is **not affected**. Solr never unpacks Pack200 archives \u2014 Pack200 (a legacy JAR-compression\nformat) is not part of any Solr request path. The affected `commons-compress` a scanner flags\n(`commons-compress@1.24.0`) is the copy shaded into `hadoop-client-runtime` in the optional `hdfs`\nmodule; Solr's HDFS-client usage does not feed untrusted Pack200 input to it, and Solr's own use of\nCommons Compress elsewhere does not invoke the Pack200 unpacker. The vulnerable code path is therefore\nnot reached. The affected range spans the releases whose `hdfs` module bundles an affected shaded\ncommons-compress \u2014 Solr 9.0.0 \u2013 9.9.0 (`hadoop-client-runtime` 3.3.2 \u2013 3.4.0, shading commons-compress\n\u2264 1.24.0; the standalone copy in the `extraction` module was already \u2265 1.26.0 by 9.7.0). Solr 9.10.0\nupgraded to Hadoop 3.4.1, whose `hadoop-client-runtime` shades the fixed commons-compress 1.26.1, and\nSolr 10.x ships no `hadoop-client-runtime`, so neither is affected.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2024-29131" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.10.1" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.11.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.7" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.8.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.9.0" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-29131 and CVE-2024-29133 are denial-of-service issues (StackOverflowError) in Apache Commons\nConfiguration's list-delimiter handling \u2014 `AbstractListDelimiterHandler.flattenIterator(...)` and\n`ListDelimiterHandler.flatten(Object, int)` respectively \u2014 when a configuration contains a cyclic\nreference (both affect 2.0 through 2.10.0, fixed in 2.10.1).\n\nSolr is **not affected**. Solr uses `commons-configuration2` only through its optional Hadoop\nintegration \u2014 both the standalone copy in the `hadoop-auth` module and the copy shaded into\n`hadoop-client-runtime` (which a scanner reports as `commons-configuration2@2.8.0`) \u2014 to load\n**administrator-supplied** Hadoop configuration files, never untrusted external input. No Solr request\npath feeds attacker-controlled configuration to Commons Configuration, so the recursive list-delimiter\nparser cannot be driven by an adversary. This matches the existing assessment of the other Commons\nConfiguration CVEs (CVE-2022-33980, CVE-2026-45205). The affected range spans the releases whose\nHadoop modules carry an affected commons-configuration2 \u2014 Solr 9.0.0 \u2013 9.9.0 (`hadoop-client-runtime`\n3.3.2 \u2013 3.4.0 shades commons-configuration2 \u2264 2.8.0; the standalone `hadoop-auth` copy was already\n\u2265 2.10.1, at 2.11.0, by 9.7.0). Solr 9.10.0 upgraded to Hadoop 3.4.1, whose `hadoop-client-runtime`\nshades the fixed commons-configuration2 2.10.1, so 9.10.x onward is not affected.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2024-29133" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.10.1" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.11.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.7" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.8.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.9.0" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-29131 and CVE-2024-29133 are denial-of-service issues (StackOverflowError) in Apache Commons\nConfiguration's list-delimiter handling \u2014 `AbstractListDelimiterHandler.flattenIterator(...)` and\n`ListDelimiterHandler.flatten(Object, int)` respectively \u2014 when a configuration contains a cyclic\nreference (both affect 2.0 through 2.10.0, fixed in 2.10.1).\n\nSolr is **not affected**. Solr uses `commons-configuration2` only through its optional Hadoop\nintegration \u2014 both the standalone copy in the `hadoop-auth` module and the copy shaded into\n`hadoop-client-runtime` (which a scanner reports as `commons-configuration2@2.8.0`) \u2014 to load\n**administrator-supplied** Hadoop configuration files, never untrusted external input. No Solr request\npath feeds attacker-controlled configuration to Commons Configuration, so the recursive list-delimiter\nparser cannot be driven by an adversary. This matches the existing assessment of the other Commons\nConfiguration CVEs (CVE-2022-33980, CVE-2026-45205). The affected range spans the releases whose\nHadoop modules carry an affected commons-configuration2 \u2014 Solr 9.0.0 \u2013 9.9.0 (`hadoop-client-runtime`\n3.3.2 \u2013 3.4.0 shades commons-configuration2 \u2264 2.8.0; the standalone `hadoop-auth` copy was already\n\u2265 2.10.1, at 2.11.0, by 9.7.0). Solr 9.10.0 upgraded to Hadoop 3.4.1, whose `hadoop-client-runtime`\nshades the fixed commons-configuration2 2.10.1, so 9.10.x onward is not affected.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.9.0." }, { "vulnerability": { "name": "CVE-2025-31672" }, "products": [ { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.10-beta2" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.10.1" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.11" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.15-beta1" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.17" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.17-beta1" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.8" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.8-beta4" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@3.9" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@4.0.0" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@4.1.1" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@4.1.2" }, { "@id": "pkg:maven/org.apache.poi/poi-ooxml@5.2.2" } ], "status": "not_affected", "timestamp": "2025-09-07T00:00:00Z", "impact_statement": "CVE-2025-31672 (CVSS 6.9) is an improper-input-validation issue in Apache POI's OOXML parser: parsing\na crafted OOXML file (`.xlsx`, `.docx`, etc.) can cause `poi-ooxml` to read unexpected data or consume\nexcessive resources. It affects all `poi-ooxml` releases before 5.4.0 (fixed in 5.4.0). Solr bundles\nan affected `poi-ooxml` via the optional **extraction (Solr Cell)** module \u2014 5.2.2 in the 9.x line,\nand older 3.x/4.x builds before that \u2014 from Solr 3.6.0 through 9.10.1. Solr 10.x ships no POI, and the\n9.x line upgraded to a fixed `poi-ooxml` (5.5.1) after 9.10.1, so the affected range is 3.6.0 \u2013 9.10.1.\n\nSolr is **not affected** in a supported configuration. Apache POI is used only by the extraction\n(Solr Cell) module, which parses rich documents (PDF, Office, etc.) via Apache Tika. Solr Cell is not\nenabled by default and is **not recommended for production**: the project's guidance is to run Tika as\na separate service and index the extracted text, rather than have Solr parse untrusted documents\nin-process. A deployment that follows that guidance never feeds an attacker-controlled OOXML file to\nthe bundled POI, so the vulnerable parser is not reached.\n\nOperators who nonetheless enable Solr Cell and parse untrusted documents should either move document\nextraction out of Solr (the recommended architecture) or replace the bundled\n`modules/extraction/lib/poi-ooxml-*.jar` with `poi-ooxml` 5.4.0 or later. Tracked as SOLR-17903.", "status_notes": "Affected Apache Solr versions: 3.6.0-9.10.1." }, { "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's 9.x line pulls in\ntransitively via `lucene-analysis-opennlp` (Lucene 9.12.3). The issue is fixed in OpenNLP 2.5.9 (and\n3.0.0-M3), and backported to the 1.9.x line as `opennlp-tools-1.9.5`; all of these parse dictionaries\nwith secure XML 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\nSolr has bundled OpenNLP (via `lucene-analysis-opennlp`) since Solr 7.3.0. Every release from 7.3.0\nthrough the 9.10.x line ships an affected `opennlp-tools` (1.8.3 through 1.9.4), and Solr 10.0.0 ships\nthe affected 2.5.6. Solr **9.11** upgrades to the patched `opennlp-tools` 1.9.5 (the 1.9.x backport)\nand Solr **10.1** upgrades to 2.5.9, so both are fixed. The affected (exploitable) range is therefore\n**7.3.0 \u2013 9.10.1 and 10.0.0**.\n\nNote: advisory databases record the fix only as OpenNLP 2.5.9, so a dependency scanner may still flag\nthe backported `opennlp-tools` 1.9.5 that Solr 9.11 ships \u2014 a false positive, since 1.9.5 contains the\nbackported fix.", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1,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's 9.x line pulls in\ntransitively via `lucene-analysis-opennlp` (Lucene 9.12.3). The issue is fixed upstream in OpenNLP\n2.5.9 (and 3.0.0-M3), and backported to the 1.9.x line as `opennlp-tools-1.9.5`; the fix 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\nAs defense in depth, Solr 9.11 also validates OpenNLP models at the application layer before they\nreach `ExtensionLoader`. 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\nSolr has bundled OpenNLP (via `lucene-analysis-opennlp`) since Solr 7.3.0. Every release from 7.3.0\nthrough the 9.10.x line ships an affected `opennlp-tools` (1.8.3 through 1.9.4), and Solr 10.0.0 ships\nthe affected 2.5.6. Solr **9.11** is fixed \u2014 it upgrades to the patched `opennlp-tools` 1.9.5 (the\n1.9.x backport) and adds the application-layer allowlist described above \u2014 and Solr **10.1** upgrades\nto 2.5.9. The affected (exploitable) range is therefore **7.3.0 \u2013 9.10.1 and 10.0.0**.\n\nNote: advisory databases record the fix only as OpenNLP 2.5.9, so a dependency scanner may still flag\nthe backported `opennlp-tools` 1.9.5 that Solr 9.11 ships \u2014 a false positive, since 1.9.5 (plus Solr's\nown allowlist) closes this issue.", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1,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), which validate the count against an upper bound (default 10,000,000, configurable via the\n`OPENNLP_MAX_ENTRIES` system property) before allocating, and backported to the 1.9.x line as\n`opennlp-tools-1.9.5`.\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\nSolr has bundled OpenNLP (via `lucene-analysis-opennlp`) since Solr 7.3.0. Every release from 7.3.0\nthrough the 9.10.x line ships an affected `opennlp-tools` (1.8.3 through 1.9.4), and Solr 10.0.0 ships\nthe affected 2.5.6. Solr **9.11** upgrades to the patched `opennlp-tools` 1.9.5 (the 1.9.x backport)\nand Solr **10.1** upgrades to 2.5.9, so both are fixed. The affected (exploitable) range is therefore\n**7.3.0 \u2013 9.10.1 and 10.0.0**.\n\nNote: advisory databases record the fix only as OpenNLP 2.5.9, so a dependency scanner may still flag\nthe backported `opennlp-tools` 1.9.5 that Solr 9.11 ships \u2014 a false positive, since 1.9.5 contains the\nbackported fix.", "status_notes": "Affected Apache Solr versions: 7.3.0-9.10.1,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 9.10.1 plus 10.0.0.\n\nThe fix has landed on all active development branches: Solr 9.11 (`branch_9x`), 10.1 (`branch_10x`),\nand `main` upgrade the bundled copy to commons-beanutils 1.11.0, and Hadoop 3.4.3 (shipped in 9.11)\nadditionally dropped the shaded commons-beanutils it previously carried inside `hadoop-client-runtime`.\nSo 9.11 and 10.1 are not affected, and the range is capped at 9.10.1 / 10.0.0 rather than an open\n`3.6.0 \u2013 10.0.0` that would otherwise sweep in the fixed 9.11 release.", "status_notes": "Affected Apache Solr versions: 3.6.0-9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-33870" }, "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-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." }, { "vulnerability": { "name": "CVE-2024-47561" }, "products": [ { "@id": "avro-1.9.2.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-47561 (critical) is an arbitrary-code-execution issue in the Apache Avro Java SDK: parsing\nan attacker-controlled Avro **schema** can instantiate arbitrary classes (affects avro < 1.11.4).\nCVE-2023-39410 is a memory-exhaustion / DoS issue when **deserializing untrusted Avro data** (affects\navro < 1.11.3). Both require the application to feed attacker-controlled Avro input to the SDK.\n\nSolr is **not affected**:\n\n* **Solr does not use Apache Avro.** There is no `org.apache.avro` usage anywhere in the Solr\n codebase, and Solr ships no standalone `avro-*.jar`. Avro appears only as an embedded/transitive\n artifact of the optional Hadoop integration (the `hdfs` / `hadoop-auth` modules, which are not part\n of a default install).\n* **The vulnerable entry points are never reached.** Solr never parses an externally-supplied Avro\n schema and never deserializes untrusted Avro data \u2014 the only code that pulls Avro in is Hadoop's\n own internal machinery, driven by administrator-supplied configuration, not by untrusted request\n input.\n\nThe affected range covers Solr 9.0.0 \u2013 9.10.1, where the optional Hadoop modules transitively carry a\nvulnerable Avro (1.7.7 in `hadoop-client-runtime` 3.3.2 \u2013 3.3.6, then 1.9.2 in 3.4.0 \u2013 3.4.1); Solr's\nown code path never invokes it. A scanner surfaces this as `avro@1.9.2` because Avro is shaded inside\n`hadoop-client-runtime` in the `hdfs` module (the form reported by SOLR-17900). Unlike the other\nHadoop-shaded CVEs from SOLR-17900, Avro stayed vulnerable all the way through 9.10.1: Solr 9.11\n(branch_9x) is the first fixed release, having upgraded to Hadoop 3.4.3, whose `hadoop-client-runtime`\nshades Avro 1.11.4 (past both the 1.11.3 and 1.11.4 fixes). Solr 10.x ships no `hadoop-client-runtime`.\nEither way it is the same non-reachable Hadoop transitive.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.10.1." }, { "vulnerability": { "name": "CVE-2023-39410" }, "products": [ { "@id": "avro-1.9.2.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2024-47561 (critical) is an arbitrary-code-execution issue in the Apache Avro Java SDK: parsing\nan attacker-controlled Avro **schema** can instantiate arbitrary classes (affects avro < 1.11.4).\nCVE-2023-39410 is a memory-exhaustion / DoS issue when **deserializing untrusted Avro data** (affects\navro < 1.11.3). Both require the application to feed attacker-controlled Avro input to the SDK.\n\nSolr is **not affected**:\n\n* **Solr does not use Apache Avro.** There is no `org.apache.avro` usage anywhere in the Solr\n codebase, and Solr ships no standalone `avro-*.jar`. Avro appears only as an embedded/transitive\n artifact of the optional Hadoop integration (the `hdfs` / `hadoop-auth` modules, which are not part\n of a default install).\n* **The vulnerable entry points are never reached.** Solr never parses an externally-supplied Avro\n schema and never deserializes untrusted Avro data \u2014 the only code that pulls Avro in is Hadoop's\n own internal machinery, driven by administrator-supplied configuration, not by untrusted request\n input.\n\nThe affected range covers Solr 9.0.0 \u2013 9.10.1, where the optional Hadoop modules transitively carry a\nvulnerable Avro (1.7.7 in `hadoop-client-runtime` 3.3.2 \u2013 3.3.6, then 1.9.2 in 3.4.0 \u2013 3.4.1); Solr's\nown code path never invokes it. A scanner surfaces this as `avro@1.9.2` because Avro is shaded inside\n`hadoop-client-runtime` in the `hdfs` module (the form reported by SOLR-17900). Unlike the other\nHadoop-shaded CVEs from SOLR-17900, Avro stayed vulnerable all the way through 9.10.1: Solr 9.11\n(branch_9x) is the first fixed release, having upgraded to Hadoop 3.4.3, whose `hadoop-client-runtime`\nshades Avro 1.11.4 (past both the 1.11.3 and 1.11.4 fixes). Solr 10.x ships no `hadoop-client-runtime`.\nEither way it is the same non-reachable Hadoop transitive.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.10.1." }, { "vulnerability": { "name": "CVE-2025-49128" }, "products": [ { "@id": "jackson-core-2.12.7.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2025-49128 can disclose adjacent buffer memory through the source snippet that jackson-core\nincludes in `JsonLocation` (e.g. surfaced in parse-error messages). It affects jackson-core < 2.13.0.\n\nSolr is **not affected**. Solr's own jackson-core is 2.18.0 in current 9.x and 2.22.0 in 9.11 \u2014 both\nwell past the 2.13.0 fix. The `2.12.7` copy a scanner flags is Hadoop's shaded jackson-core,\nreachable only via the optional Hadoop modules, which parse administrator-supplied configuration\nrather than untrusted external JSON, and whose parse errors are not returned to remote clients.", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." }, { "vulnerability": { "name": "GHSA-r7wm-3cxj-wff9" }, "products": [ { "@id": "jackson-core-2.12.7.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "GHSA-r7wm-3cxj-wff9 is a `maxNumberLength` bypass in jackson-core's **async / non-blocking** parser\n(an incomplete fix for GHSA-72hv-8253-57qq; affects < 2.18.8 and 2.19.0\u20132.21.3). CVE-2025-52999 is a\n`StackOverflowError` when parsing **very deeply nested** input (affects < 2.15.0).\n\nSolr is **not affected**:\n\n* **The async parser is never used.** Solr deserializes JSON with the standard *synchronous* Jackson\n parser; it never calls the non-blocking `NonBlockingByteArrayParser` API, so the async-only\n `maxNumberLength` bypass (GHSA-r7wm) is unreachable \u2014 as already assessed for GHSA-72hv-8253-57qq.\n* **Solr's own jackson-core is patched.** The bundled jackson-core is 2.18.0 in current 9.x and\n 2.22.0 in 9.11 \u2014 both fixed for the deep-nesting StackOverflow (fixed in 2.15.0). The `2.12.7`\n copy a scanner flags is Hadoop's **shaded** jackson, reachable only through the optional Hadoop\n modules, which parse administrator-supplied configuration rather than untrusted external JSON.", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-52999" }, "products": [ { "@id": "jackson-core-2.12.7.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "GHSA-r7wm-3cxj-wff9 is a `maxNumberLength` bypass in jackson-core's **async / non-blocking** parser\n(an incomplete fix for GHSA-72hv-8253-57qq; affects < 2.18.8 and 2.19.0\u20132.21.3). CVE-2025-52999 is a\n`StackOverflowError` when parsing **very deeply nested** input (affects < 2.15.0).\n\nSolr is **not affected**:\n\n* **The async parser is never used.** Solr deserializes JSON with the standard *synchronous* Jackson\n parser; it never calls the non-blocking `NonBlockingByteArrayParser` API, so the async-only\n `maxNumberLength` bypass (GHSA-r7wm) is unreachable \u2014 as already assessed for GHSA-72hv-8253-57qq.\n* **Solr's own jackson-core is patched.** The bundled jackson-core is 2.18.0 in current 9.x and\n 2.22.0 in 9.11 \u2014 both fixed for the deep-nesting StackOverflow (fixed in 2.15.0). The `2.12.7`\n copy a scanner flags is Hadoop's **shaded** jackson, reachable only through the optional Hadoop\n modules, which parse administrator-supplied configuration rather than untrusted external JSON.", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-53864" }, "products": [ { "@id": "nimbus-jose-jwt-9.37.2.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2025-53864 is an uncontrolled-recursion denial-of-service in the Nimbus JOSE + JWT library when\nparsing a maliciously crafted, deeply-nested JOSE object (affects 9.37.x < 9.37.4 and 10.0.x < 10.0.2).\n\nSolr is **not affected**. Solr's JWT authentication (the optional `jwt-auth` module, `JWTAuthPlugin`)\nparses and validates tokens exclusively with **jose4j** (`org.jose4j.*` \u2014 the plugin imports jose4j\nand does not reference `com.nimbusds` at all). Nimbus JOSE + JWT is not on Solr's JWT-processing code\npath; it appears only as a transitive/declared reference and is never invoked to parse an incoming\ntoken, so the vulnerable recursive parser cannot be reached by an attacker-supplied JWT.", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-10050" }, "products": [ { "@id": "jetty-security-10.0.26.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-10050 is a lossy-encoding flaw in Eclipse Jetty's **Digest authentication** implementation\n(in `jetty-security`), which can weaken Digest credential handling. It affects the Jetty branches\nSolr ships (10.0.x through 10.0.30, and 12.0.x through 12.0.35; fixed in 10.0.31 / 12.0.36 / 12.1.10).\n\nSolr is **not affected**. Solr bundles `jetty-security` as part of the Jetty server stack, but it\ndoes not use Jetty's declarative security: it never installs a Jetty `SecurityHandler` /\n`ConstraintSecurityHandler` and never configures a Jetty `Authenticator` (Digest or otherwise). Solr\nauthenticates requests in its own servlet filter (`SolrDispatchFilter` / the `AuthenticationPlugin`\nframework \u2014 Basic, JWT, Kerberos, PKI, etc.), so Jetty's Digest-authentication code path \u2014 the code\nthis CVE affects \u2014 is never invoked. The affected range spans the releases whose bundled Jetty is in\nan affected branch (Solr 7.3.0 \u2013 10.0.0).", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-10051" }, "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-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-10051 is an information-exposure bug in Jetty's `HttpConnection`: the `_trailers` field is\nnot reset between requests on an HTTP/1.1 keep-alive connection, so trailer fields from one request\ncan be observed via `getTrailers()` on a later request on the same connection. It has security impact\nonly for applications that **read HTTP trailers** (`request.getTrailers()`) and use them for logic or\nsecurity decisions.\n\nSolr is **not affected**. Solr does not read HTTP request trailers anywhere \u2014 there is no\n`getTrailers()` / trailer-field usage in the Solr codebase \u2014 so stale trailer state on a pooled\nconnection is never observed by Solr and cannot influence request handling or authorization. The\naffected range spans the releases whose bundled Jetty is in an affected branch (Solr 7.3.0 \u2013 10.0.0).", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-43869" }, "products": [ { "@id": "libthrift-0.15.0.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "impact_statement": "CVE-2026-43869 is a TLS hostname-verification weakness in Apache Thrift's\n`TSSLTransportFactory` (affects libthrift \u2264 0.22.0, fixed in 0.23.0): a client using Thrift's TLS\ntransport may not properly verify the server certificate's hostname, enabling a man-in-the-middle on\nthat connection.\n\nSolr is **not affected** in any default or recommended configuration. `libthrift` is bundled only by\nthe optional, opt-in **`jaegertracer-configurator`** module (Jaeger distributed-tracing exporter) \u2014\nit is not part of a default Solr install, and Solr does not use Thrift's TLS transport anywhere else.\nEven when Jaeger tracing is enabled, Solr exports spans to an **operator-configured** Jaeger backend\n(a trusted, first-party collector), not to an untrusted remote host, so there is no untrusted TLS\npeer for the missing hostname check to expose. The issue is only relevant to an operator who both\nenables Jaeger tracing and deliberately points it at an untrusted TLS endpoint.", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-45205" }, "products": [ { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.10.1" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.11.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.12.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.7" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.8.0" }, { "@id": "pkg:maven/org.apache.commons/commons-configuration2@2.9.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-45205 is a `StackOverflowError` (DoS) when Apache Commons Configuration parses YAML input\ncontaining reference cycles (affects 2.2 \u2013 2.14.x, fixed in 2.15.0).\n\nSolr is **not affected**. Solr uses `commons-configuration2` only transitively, via the optional\nHadoop integration (Kerberos / HDFS support), to load **administrator-supplied** Hadoop configuration\nfiles \u2014 not untrusted, externally-supplied YAML. No Solr request path feeds attacker-controlled YAML\nto Commons Configuration, so the cyclic-YAML parser cannot be driven by an adversary. (This matches\nthe existing assessment of the other Commons Configuration CVEs in Solr.)", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-46718" }, "products": [ { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.27.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.32.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.33.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.34.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.35.0" }, { "@id": "pkg:maven/org.apache.calcite/calcite-core@1.37.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-46718 lets a **user-controlled Calcite model** load arbitrary classes, leading to code\nexecution (affects calcite-core 1.5.0 \u2013 1.41.x, fixed in 1.42.0). Exploitation requires the\napplication to let an attacker supply the Calcite *model* (the JSON schema/model definition that can\nname factory classes).\n\nSolr is **not affected**. Calcite is used only by the optional `sql` module (Parallel SQL, the `/sql`\nhandler). Solr constructs the Calcite schema/model **server-side** from the target collection; users\nsubmit only a SQL statement, never a Calcite model or schema-factory definition. There is no request\npath through which an attacker can supply a Calcite model, so the arbitrary-class-loading vector is\nnever reached.", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-50193" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.2.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.3" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4.2" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-50193 is a denial-of-service issue in jackson-databind: calling `toString()` on a\ndeeply-nested `JsonNode` recurses until it throws a `StackOverflowError`. It affects jackson-databind\nbefore 2.14.0 (fixed in 2.14.0), and is reachable only when an application builds a `JsonNode` tree\nfrom attacker-controlled JSON and then calls `toString()` on it.\n\nSolr is **not affected**. Solr does not call `toString()` on an untrusted, attacker-nested `JsonNode`\nas part of any request path.\n\nSolr's own standalone `jackson-databind` is below 2.14.0 only in 9.0.0 \u2013 9.1.1 (2.13.2.2 / 2.13.3 /\n2.13.4.2); from 9.2.0 onward it ships 2.14.2 or later (up to 2.20.0 in 10.0.0), all past the fix, so\nthose releases are not affected. Note the old `2.12.7.1` copy shaded inside `hadoop-client-runtime`\n(optional `hdfs` module) is also below 2.14.0 and is present across the wider 9.x line, but that\nshaded purl is a separate scanner/generator concern tracked with the other Hadoop-shaded dependencies\n(SOLR-17900); this statement covers Solr's standalone jackson-databind.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.1.1." }, { "vulnerability": { "name": "CVE-2026-54512" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.10.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.10.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.11.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.2.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.3" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.14.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.16.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.20.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.3.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.5.4" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.5" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.8" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.9.3" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-54512 and CVE-2026-54513 are bypasses of jackson-databind's `PolymorphicTypeValidator` \u2014 via\ngeneric type parameters (54512) and via an array-subtype allowlist gap in\n`allowIfSubType` (54513) \u2014 that can let unexpected classes be instantiated during polymorphic\ndeserialization (affects 2.10.0\u20132.18.7 and 2.19.0\u20132.21.3).\n\nSolr is **not affected**. Both issues are only exploitable when an application enables **polymorphic\ndeserialization** \u2014 default typing (`activateDefaultTyping`), `@JsonTypeInfo`, or a\n`BasicPolymorphicTypeValidator` allowlist \u2014 and then deserializes attacker-controlled JSON through it.\nSolr does none of this: it maps request JSON to fixed, known target types and never enables default\ntyping or polymorphic deserialization of untrusted input, so the `PolymorphicTypeValidator` code path\nthese CVEs target is never exercised. (The `2.12.7.1` copy a scanner flags is Hadoop's shaded\njackson-databind; Solr's own is 2.18.0 in current 9.x and 2.22.0 in 9.11.)", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-54513" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.10.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.10.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.11.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.2.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.3" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.14.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.16.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.20.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.3.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.5.4" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.5" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.6" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.8" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.9.9.3" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-54512 and CVE-2026-54513 are bypasses of jackson-databind's `PolymorphicTypeValidator` \u2014 via\ngeneric type parameters (54512) and via an array-subtype allowlist gap in\n`allowIfSubType` (54513) \u2014 that can let unexpected classes be instantiated during polymorphic\ndeserialization (affects 2.10.0\u20132.18.7 and 2.19.0\u20132.21.3).\n\nSolr is **not affected**. Both issues are only exploitable when an application enables **polymorphic\ndeserialization** \u2014 default typing (`activateDefaultTyping`), `@JsonTypeInfo`, or a\n`BasicPolymorphicTypeValidator` allowlist \u2014 and then deserializes attacker-controlled JSON through it.\nSolr does none of this: it maps request JSON to fixed, known target types and never enables default\ntyping or polymorphic deserialization of untrusted input, so the `PolymorphicTypeValidator` code path\nthese CVEs target is never exercised. (The `2.12.7.1` copy a scanner flags is Hadoop's shaded\njackson-databind; Solr's own is 2.18.0 in current 9.x and 2.22.0 in 9.11.)", "status_notes": "Affected Apache Solr versions: 4.7.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-54514" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.2.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.3" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.14.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.16.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.20.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-54514 is a server-side request forgery (SSRF) issue in jackson-databind:\n`JDKFromStringDeserializer` builds an `InetSocketAddress` with `new InetSocketAddress(host, port)`,\nwhich performs eager DNS name resolution. Deserializing attacker-controlled JSON into an\n`InetSocketAddress` therefore triggers a DNS lookup of an attacker-chosen name. It affects\njackson-databind 2.0.0 \u2013 2.18.7 and 2.19.0 \u2013 2.21.3 (fixed in 2.18.8 / 2.21.4).\n\nSolr is **not affected**. Solr deserializes request JSON into fixed, known types and never binds\nuntrusted input to a `java.net.InetSocketAddress` (or a field that would trigger this deserializer),\nso the eager-resolution path is never driven by attacker-controlled data.\n\nSolr shipped an in-range `jackson-databind` from 9.0.0 through 9.10.1 (2.13.2.2 \u2192 2.18.0, all\n< 2.18.8) and in 10.0.0 (2.20.0, within 2.19.0 \u2013 2.21.3). Solr 9.11 upgrades to 2.22.0 (past the\n2.21.4 fix) and is not affected. The old `2.12.7.1` copy shaded inside `hadoop-client-runtime` (in the\noptional `hdfs` module across the 9.x line) is likewise below the fix, but its shaded purl is a\nseparate scanner/generator concern tracked with the other Hadoop-shaded dependencies (SOLR-17900);\neither way Solr does not route untrusted JSON into `InetSocketAddress` deserialization.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-54515" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.2.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.3" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.13.4.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.14.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.16.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.20.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "impact_statement": "CVE-2026-54515 is a deserialization-filter bypass in jackson-databind: when case-insensitive property\nmatching (`MapperFeature.ACCEPT_CASE_INSENSITIVE_PROPERTIES`) is enabled together with per-property\n`@JsonIgnoreProperties`, a property meant to be ignored can still be set from untrusted JSON using a\ndifferent-case name (a mass-assignment-style write). It affects jackson-databind 2.8.0 \u2013 2.18.8,\n2.19.0 \u2013 2.21.4, and 2.22.0 (fixed in 2.18.9 / 2.21.5 / 2.22.1).\n\nSolr is **not affected**. Exploiting this requires an application to rely on case-insensitive matching\nplus per-property `@JsonIgnoreProperties` to restrict which fields untrusted input may set. Solr does\nneither: it maps request JSON to fixed, known types and does not use `@JsonIgnoreProperties`-based\nfiltering (nor case-insensitive property mapping) as a security boundary on untrusted input, so there\nis nothing for the bypass to defeat.\n\nSolr shipped an in-range `jackson-databind` from 9.0.0 through 9.10.1 (2.13.2.2 \u2192 2.18.0) and in\n10.0.0 (2.20.0). Solr 9.11 ships 2.22.0, which is also affected (fixed in 2.22.1) \u2014 it should be added\nto this range once released. The old `2.12.7.1` copy shaded inside `hadoop-client-runtime` (optional\n`hdfs` module) is also in range, but its shaded purl is a separate scanner/generator concern tracked\nwith the other Hadoop-shaded dependencies (SOLR-17900).", "status_notes": "Affected Apache Solr versions: 9.0.0-9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-56740" }, "products": [ { "@id": "jline-remote-telnet-3.9.0.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_present", "impact_statement": "CVE-2026-56740 and CVE-2026-56741 are unauthenticated remote denial-of-service issues in **JLine's\nTelnet server** \u2014 unbounded NEW-ENVIRON variables (56740) and unbounded NAWS terminal-geometry values\n(56741) in the `jline-remote-telnet` Telnet daemon (affects < 3.30.14, and the 4.0.x / 4.1.x lines).\n\nSolr is **not affected**:\n\n* **The vulnerable component is not shipped or run.** Solr ships no `jline-remote-telnet` jar; the\n `3.9.0` coordinate a scanner reports comes only from a dependency reference embedded in the bundled\n `zookeeper-3.9.5` jar's metadata. Solr never starts a JLine Telnet server (`Telnetd`).\n* JLine is used, at most, for the local interactive `bin/solr` CLI terminal \u2014 a `LineReader` on the\n operator's own console, not a network-listening Telnet daemon \u2014 so nothing accepts remote Telnet\n connections that the vulnerable NAWS/NEW-ENVIRON parsing could act on.", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-56741" }, "products": [ { "@id": "jline-remote-telnet-3.9.0.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_present", "impact_statement": "CVE-2026-56740 and CVE-2026-56741 are unauthenticated remote denial-of-service issues in **JLine's\nTelnet server** \u2014 unbounded NEW-ENVIRON variables (56740) and unbounded NAWS terminal-geometry values\n(56741) in the `jline-remote-telnet` Telnet daemon (affects < 3.30.14, and the 4.0.x / 4.1.x lines).\n\nSolr is **not affected**:\n\n* **The vulnerable component is not shipped or run.** Solr ships no `jline-remote-telnet` jar; the\n `3.9.0` coordinate a scanner reports comes only from a dependency reference embedded in the bundled\n `zookeeper-3.9.5` jar's metadata. Solr never starts a JLine Telnet server (`Telnetd`).\n* JLine is used, at most, for the local interactive `bin/solr` CLI terminal \u2014 a `LineReader` on the\n operator's own console, not a network-listening Telnet daemon \u2014 so nothing accepts remote Telnet\n connections that the vulnerable NAWS/NEW-ENVIRON parsing could act on.", "status_notes": "Affected Apache Solr versions: 9.0.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-56745" }, "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" }, { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues are resource-exhaustion / DoS bugs in server- and decoder-side code paths\n(all affect Netty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-56745, CVE-2026-55833, CVE-2026-55831 \u2014 the **SPDY** codec (`SpdyHttpDecoder` and SPDY\n header/settings handling) in `netty-codec-http`.\n* CVE-2026-56819 \u2014 server-side **HTTP/2 decompression** ByteBuf reference leak in `netty-codec-http2`.\n* CVE-2026-59901 \u2014 infinite loop in the **Bzip2** decoder in `netty-codec-compression`.\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty acts strictly as a **client**. Solr's HTTP server is Jetty, not\nNetty: Solr never runs a Netty HTTP/HTTP2/SPDY server, never enables the SPDY codec, and never feeds\nattacker-controlled compressed (bzip2) streams through Netty. The vulnerable server/decoder code\npaths are therefore unreachable \u2014 the same reasoning as CVE-2026-33870 / CVE-2026-33871.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-55833" }, "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" }, { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues are resource-exhaustion / DoS bugs in server- and decoder-side code paths\n(all affect Netty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-56745, CVE-2026-55833, CVE-2026-55831 \u2014 the **SPDY** codec (`SpdyHttpDecoder` and SPDY\n header/settings handling) in `netty-codec-http`.\n* CVE-2026-56819 \u2014 server-side **HTTP/2 decompression** ByteBuf reference leak in `netty-codec-http2`.\n* CVE-2026-59901 \u2014 infinite loop in the **Bzip2** decoder in `netty-codec-compression`.\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty acts strictly as a **client**. Solr's HTTP server is Jetty, not\nNetty: Solr never runs a Netty HTTP/HTTP2/SPDY server, never enables the SPDY codec, and never feeds\nattacker-controlled compressed (bzip2) streams through Netty. The vulnerable server/decoder code\npaths are therefore unreachable \u2014 the same reasoning as CVE-2026-33870 / CVE-2026-33871.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-55831" }, "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" }, { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues are resource-exhaustion / DoS bugs in server- and decoder-side code paths\n(all affect Netty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-56745, CVE-2026-55833, CVE-2026-55831 \u2014 the **SPDY** codec (`SpdyHttpDecoder` and SPDY\n header/settings handling) in `netty-codec-http`.\n* CVE-2026-56819 \u2014 server-side **HTTP/2 decompression** ByteBuf reference leak in `netty-codec-http2`.\n* CVE-2026-59901 \u2014 infinite loop in the **Bzip2** decoder in `netty-codec-compression`.\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty acts strictly as a **client**. Solr's HTTP server is Jetty, not\nNetty: Solr never runs a Netty HTTP/HTTP2/SPDY server, never enables the SPDY codec, and never feeds\nattacker-controlled compressed (bzip2) streams through Netty. The vulnerable server/decoder code\npaths are therefore unreachable \u2014 the same reasoning as CVE-2026-33870 / CVE-2026-33871.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-56819" }, "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" }, { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues are resource-exhaustion / DoS bugs in server- and decoder-side code paths\n(all affect Netty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-56745, CVE-2026-55833, CVE-2026-55831 \u2014 the **SPDY** codec (`SpdyHttpDecoder` and SPDY\n header/settings handling) in `netty-codec-http`.\n* CVE-2026-56819 \u2014 server-side **HTTP/2 decompression** ByteBuf reference leak in `netty-codec-http2`.\n* CVE-2026-59901 \u2014 infinite loop in the **Bzip2** decoder in `netty-codec-compression`.\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty acts strictly as a **client**. Solr's HTTP server is Jetty, not\nNetty: Solr never runs a Netty HTTP/HTTP2/SPDY server, never enables the SPDY codec, and never feeds\nattacker-controlled compressed (bzip2) streams through Netty. The vulnerable server/decoder code\npaths are therefore unreachable \u2014 the same reasoning as CVE-2026-33870 / CVE-2026-33871.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59901" }, "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" }, { "@id": "pkg:maven/io.netty/netty-codec-compression@4.2.6.Final" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues are resource-exhaustion / DoS bugs in server- and decoder-side code paths\n(all affect Netty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-56745, CVE-2026-55833, CVE-2026-55831 \u2014 the **SPDY** codec (`SpdyHttpDecoder` and SPDY\n header/settings handling) in `netty-codec-http`.\n* CVE-2026-56819 \u2014 server-side **HTTP/2 decompression** ByteBuf reference leak in `netty-codec-http2`.\n* CVE-2026-59901 \u2014 infinite loop in the **Bzip2** decoder in `netty-codec-compression`.\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty acts strictly as a **client**. Solr's HTTP server is Jetty, not\nNetty: Solr never runs a Netty HTTP/HTTP2/SPDY server, never enables the SPDY codec, and never feeds\nattacker-controlled compressed (bzip2) streams through Netty. The vulnerable server/decoder code\npaths are therefore unreachable \u2014 the same reasoning as CVE-2026-33870 / CVE-2026-33871.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59888" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.16.1" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.17.2" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" }, { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.20.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "impact_statement": "CVE-2026-59888 is a deserialization-filter bypass in jackson-databind: `@JsonIgnore` on a Record\nproperty can be bypassed when a `PropertyNamingStrategy` is in effect, because\n`POJOPropertiesCollector._removeUnwantedIgnorals()` records the ignored component under its original\nimplicit name before `_renameUsing()` applies the naming strategy \u2014 so the renamed property is no\nlonger recognised as ignored and can be set from untrusted JSON. It affects jackson-databind\n2.15.0 \u2013 2.18.7 and 2.19.0 \u2013 2.21.3 (fixed in 2.18.8 / 2.21.4).\n\nSolr is **not affected**. Exploiting this requires an application to deserialize untrusted JSON into\nJava Records that use `@JsonIgnore` together with a `PropertyNamingStrategy` to keep a field\nunwritable. Solr does not rely on that mechanism to filter untrusted input, so the bypass has nothing\nto defeat.\n\nSolr shipped an in-range `jackson-databind` from 9.3.0 through 9.10.1 (2.15.2 \u2192 2.18.0) and in 10.0.0\n(2.20.0). Earlier 9.x (\u2264 9.2.x, jackson-databind \u2264 2.14.2) and Solr 9.11 (2.22.0) are past/below the\naffected ranges and are not affected.", "status_notes": "Affected Apache Solr versions: 9.3.0-9.10.1, 10.0.0." }, { "vulnerability": { "name": "CVE-2026-59889" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "impact_statement": "CVE-2026-59889 is a deserialization-filter bypass in jackson-databind: a `@JsonView` restriction can\nbe bypassed for the properties of a `@JsonUnwrapped` container, letting untrusted JSON set fields that\nthe active view was meant to exclude. It affects jackson-databind 2.18.0 \u2013 2.18.8, 2.21.0 \u2013 2.21.4,\nand 2.22.0 (fixed in 2.18.9 / 2.21.5 / 2.22.1).\n\nSolr is **not affected**. Exploiting this requires an application to use `@JsonView`-based\ndeserialization filtering over `@JsonUnwrapped` container properties to restrict which fields\nuntrusted input may set. Solr applies no `@JsonView` filtering to request deserialization, so there\nis nothing for the bypass to defeat.\n\nSolr's own standalone `jackson-databind` is in an affected range only in 9.8.0 \u2013 9.10.1 (2.18.0).\nSolr 10.0.0 ships 2.20.0, which is outside the affected ranges and is not affected. Solr 9.11 ships\n2.22.0, which *is* affected (fixed in 2.22.1) and should be added to this range once released.", "status_notes": "Affected Apache Solr versions: 9.8.0-9.10.1." }, { "vulnerability": { "name": "CVE-2026-59899" }, "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-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues live in server-side HTTP handling or the outbound request encoder (all affect\nNetty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-59899 \u2014 unbounded per-connection queue growth in `HttpContentEncoder` via HTTP/1.1\n pipelining (server response encoding).\n* CVE-2026-56746 \u2014 CORS short-circuit failure / security-control bypass (server CORS handler).\n* CVE-2026-59898 \u2014 WebSocket V07/V08 handshaker missing Connection/Upgrade validation (server).\n* CVE-2026-59921 \u2014 CRLF injection via multipart filename in the outbound `HttpPostRequestEncoder`.\n* CVE-2026-59900 \u2014 Host-header de-duplication gap in HTTP/2\u2192HTTP/1.x translation (server/proxy).\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty is used strictly as a **client**. Solr's HTTP server is Jetty:\nSolr never runs a Netty HTTP server, CORS handler, WebSocket server, or HTTP/2\u21921 proxy, and never\nuses Netty's multipart request encoder, so none of these code paths are reachable.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-56746" }, "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-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues live in server-side HTTP handling or the outbound request encoder (all affect\nNetty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-59899 \u2014 unbounded per-connection queue growth in `HttpContentEncoder` via HTTP/1.1\n pipelining (server response encoding).\n* CVE-2026-56746 \u2014 CORS short-circuit failure / security-control bypass (server CORS handler).\n* CVE-2026-59898 \u2014 WebSocket V07/V08 handshaker missing Connection/Upgrade validation (server).\n* CVE-2026-59921 \u2014 CRLF injection via multipart filename in the outbound `HttpPostRequestEncoder`.\n* CVE-2026-59900 \u2014 Host-header de-duplication gap in HTTP/2\u2192HTTP/1.x translation (server/proxy).\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty is used strictly as a **client**. Solr's HTTP server is Jetty:\nSolr never runs a Netty HTTP server, CORS handler, WebSocket server, or HTTP/2\u21921 proxy, and never\nuses Netty's multipart request encoder, so none of these code paths are reachable.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59898" }, "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-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues live in server-side HTTP handling or the outbound request encoder (all affect\nNetty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-59899 \u2014 unbounded per-connection queue growth in `HttpContentEncoder` via HTTP/1.1\n pipelining (server response encoding).\n* CVE-2026-56746 \u2014 CORS short-circuit failure / security-control bypass (server CORS handler).\n* CVE-2026-59898 \u2014 WebSocket V07/V08 handshaker missing Connection/Upgrade validation (server).\n* CVE-2026-59921 \u2014 CRLF injection via multipart filename in the outbound `HttpPostRequestEncoder`.\n* CVE-2026-59900 \u2014 Host-header de-duplication gap in HTTP/2\u2192HTTP/1.x translation (server/proxy).\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty is used strictly as a **client**. Solr's HTTP server is Jetty:\nSolr never runs a Netty HTTP server, CORS handler, WebSocket server, or HTTP/2\u21921 proxy, and never\nuses Netty's multipart request encoder, so none of these code paths are reachable.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59921" }, "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-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues live in server-side HTTP handling or the outbound request encoder (all affect\nNetty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-59899 \u2014 unbounded per-connection queue growth in `HttpContentEncoder` via HTTP/1.1\n pipelining (server response encoding).\n* CVE-2026-56746 \u2014 CORS short-circuit failure / security-control bypass (server CORS handler).\n* CVE-2026-59898 \u2014 WebSocket V07/V08 handshaker missing Connection/Upgrade validation (server).\n* CVE-2026-59921 \u2014 CRLF injection via multipart filename in the outbound `HttpPostRequestEncoder`.\n* CVE-2026-59900 \u2014 Host-header de-duplication gap in HTTP/2\u2192HTTP/1.x translation (server/proxy).\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty is used strictly as a **client**. Solr's HTTP server is Jetty:\nSolr never runs a Netty HTTP server, CORS handler, WebSocket server, or HTTP/2\u21921 proxy, and never\nuses Netty's multipart request encoder, so none of these code paths are reachable.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59900" }, "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-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "These five Netty issues live in server-side HTTP handling or the outbound request encoder (all affect\nNetty < 4.1.136 and 4.2.0\u20134.2.15, fixed in 4.1.136 / 4.2.16):\n\n* CVE-2026-59899 \u2014 unbounded per-connection queue growth in `HttpContentEncoder` via HTTP/1.1\n pipelining (server response encoding).\n* CVE-2026-56746 \u2014 CORS short-circuit failure / security-control bypass (server CORS handler).\n* CVE-2026-59898 \u2014 WebSocket V07/V08 handshaker missing Connection/Upgrade validation (server).\n* CVE-2026-59921 \u2014 CRLF injection via multipart filename in the outbound `HttpPostRequestEncoder`.\n* CVE-2026-59900 \u2014 Host-header de-duplication gap in HTTP/2\u2192HTTP/1.x translation (server/proxy).\n\nSolr is **not affected**. Solr bundles Netty only via the optional OpenTelemetry (OTLP) exporter and\nthe ZooKeeper client, where Netty is used strictly as a **client**. Solr's HTTP server is Jetty:\nSolr never runs a Netty HTTP server, CORS handler, WebSocket server, or HTTP/2\u21921 proxy, and never\nuses Netty's multipart request encoder, so none of these code paths are reachable.", "status_notes": "Affected Apache Solr versions: 9.2.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-59949" }, "products": [ { "@id": "pkg:maven/org.lz4/lz4-java@1.8.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-59949 (CVSS 6.5) is an out-of-bounds read in the `lz4-java` codec: the JNI-based XXHash\nimplementations insufficiently validate their byte-array arguments, so a caller that passes an\ninvalid array reference or an out-of-range `off`/`len` to the native XXHash methods can crash the JVM.\nIt affects `lz4-java` \u2264 1.11.0 (fixed in 1.11.1). Exploitation requires an application to pass\nattacker-influenced array/offset/length values into those XXHash APIs.\n\nSolr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where it is\nused by the embedded Apache Kafka client for LZ4 compression / checksums of cross-datacenter\nreplication messages. Kafka calls the XXHash APIs with its own internally-managed, validated buffers\nand offsets \u2014 it does not forward attacker-controlled `off`/`len` values into the native methods \u2014 and\nthe replication stream flows through an operator-controlled Kafka pipeline, not untrusted external\ninput. The `cross-dc` module is not part of a default Solr installation, and no Solr request path\nreaches the vulnerable XXHash argument handling.\n\nSolr shipped an affected `org.lz4:lz4-java` 1.8.0 from 9.8.0 (when the `cross-dc` module first bundled\nit) through 10.0.0. Unlike CVE-2025-12183 / CVE-2025-66566 (covered separately and fixed by the\n`branch_9x` / `branch_10x` / `main` migration to the fork `at.yawk.lz4:lz4-java` 1.10.1), **this issue\nis not yet fixed on any branch**: 1.11.1 is required, and all three development branches are on 1.10.1,\nso the upcoming 9.11 and 10.1 releases will still bundle an affected version. The affected Solr range\nwill need to extend to those releases once they ship.", "status_notes": "Affected Apache Solr versions: 9.8.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-6790" }, "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-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-6790 is an input-validation gap in Jetty's HTTP/2 (and HTTP/3) request processing: Jetty\ndoes not require the `:authority` pseudo-header to match the `Host` header, so a single request can\ncarry two conflicting host interpretations. It affects the Jetty branches Solr ships (9.4.x, 10.0.x\nthrough 10.0.26, 12.0.x through 12.0.34). It has security impact only for applications that **make\nsecurity-sensitive decisions based on the request host** \u2014 host-based access control, virtual-host\nisolation, multi-tenant routing, or host-derived redirect URLs.\n\nSolr is **not affected**. Solr does none of those things: it does not perform host-based access\ncontrol or virtual-host/multi-tenant isolation, its authentication and authorization\n(`SolrDispatchFilter` / the `AuthenticationPlugin` framework) never key on the `Host`/`:authority`\nvalue, and it does not build security-sensitive redirects from the request host. With no\nhost-dependent security decision, the host-confusion has no exploitable consequence in Solr.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-8384" }, "products": [ { "@id": "jetty-util-10.0.26.jar" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-8384 is a path-canonicalization flaw in Jetty's `URIUtil.canonicalPath()`: a semicolon\npath-parameter marker before dot-dot segments (e.g. `/public;/../admin/secret`) is not normalized,\nso a path-prefix authorization check can be bypassed. It is exploitable by applications that use\nJetty's `SecurityHandler.PathMapped`, or that make an authorization decision on a canonicalized path\nat a **different layer** than the one that ultimately dispatches the request (the classic\ncanonicalization *desync*).\n\nSolr is **not affected**:\n\n* **No desync between authorization and dispatch.** `HttpSolrCall` computes the request path once\n (`ServletUtils.getPathAfterContext()`), and uses that single value for *both* request routing\n (`getPath()`) and authorization (`getAuthCtx()` builds its `AuthorizationContext` resource from the\n same `getPath()`). `RuleBasedAuthorizationPlugin` therefore evaluates exactly the path that Solr\n dispatches \u2014 there is no window in which authorization sees one path while a different path is\n served, which is the precondition this CVE requires.\n* **Path parameters are already stripped.** Solr derives the path from `getServletPath()` +\n `getPathInfo()`, which per the Servlet specification have path parameters (the `;\u2026` segments this\n bug abuses) removed by the container before Solr ever sees the path.\n* Solr uses neither Jetty's `SecurityHandler.PathMapped` nor `URIUtil.canonicalPath()` directly.\n\nSo even on an affected Jetty, the mis-canonicalization cannot produce an authorization bypass in\nSolr, because Solr's authorization and dispatch are driven by the same, single path value.", "status_notes": "Affected Apache Solr versions: 7.3.0-10.0.0." }, { "vulnerability": { "name": "GHSA-mhm7-754m-9p8w" }, "products": [ { "@id": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.18.0" } ], "status": "not_affected", "timestamp": "2026-07-31T00:00:00Z", "impact_statement": "GHSA-mhm7-754m-9p8w is a deserialization-filter bypass in jackson-databind: a `@JsonView` restriction\ncan be bypassed for creator properties that use `@JsonTypeInfo(include = As.EXTERNAL_PROPERTY)`\npolymorphic typing, letting untrusted JSON populate fields the active view was meant to exclude. It\naffects jackson-databind 2.18.0 \u2013 2.18.8 and 2.21.0 \u2013 2.21.4 (fixed in 2.18.9 / 2.21.5); the\nexternal-type-id creator path was fixed on the 3.x line and not backported to the 2.19/2.20 lines,\nwhich are not affected.\n\nSolr is **not affected**. Exploiting this requires an application to combine `@JsonView` filtering\nwith `@JsonTypeInfo` external-property polymorphic typing on untrusted input. Solr applies neither\n`@JsonView` filtering nor polymorphic type handling to request deserialization (see also the\nlong-standing polymorphic-typing analysis in the jackson-databind gadget statement), so the bypass has\nnothing to defeat.\n\nSolr's own standalone `jackson-databind` is in an affected range only in 9.8.0 \u2013 9.10.1 (2.18.0).\nSolr 10.0.0 (2.20.0) and Solr 9.11 (2.22.0) are outside the affected ranges and are not affected.", "status_notes": "Affected Apache Solr versions: 9.8.0-9.10.1." }, { "vulnerability": { "name": "CVE-2022-40152" }, "products": [ { "@id": "pkg:maven/com.fasterxml.woodstox/woodstox-core@6.2.8" } ], "status": "affected", "timestamp": "2026-08-11T00:00:00Z", "action_statement": "CVE-2022-40152 (CVSS 6.5) is a denial-of-service issue in the Woodstox XML parser\n(`com.fasterxml.woodstox:woodstox-core`): when DTD support is enabled, a client can supply XML whose\n`DOCTYPE` internal subset contains a deeply-nested element content model, causing the parser to\nrecurse until it throws a `StackOverflowError`. It affects `woodstox-core` before 5.4.0 and 6.0.0 \u2013\n6.3.x, and is fixed in 5.4.0 and 6.4.0.\n\nSolr **9.0.0 and 9.1.0 are affected.** Those two releases shipped `woodstox-core` 6.2.8 (< 6.4.0), and\nSolr's XML update handler (`XMLLoader`, serving the untrusted `/update` request path) configures its\nStAX input factory via `EmptyEntityResolver.configureXMLInputFactory`. That configuration neutralizes\nexternal entities \u2014 so Solr is *not* exposed to XXE \u2014 but it does **not** disable DTD processing, so\nthe parser still reads the internal DTD subset. A client that POSTs crafted XML with a deeply-nested\nDTD to `/update` can therefore reach the vulnerable code and trigger the stack-overflow DoS. Because\nthe vulnerable path is reachable with attacker-controlled input, these releases are marked\n`exploitable` rather than `not_affected`.\n\n**Remediation: upgrade to Apache Solr 9.1.1 or later.** Solr 9.1.1 upgraded to `woodstox-core` 6.4.0\n(past the fix), and every later release ships a fixed version (6.5.0 in 9.2.0, 7.0.0 in current 9.x,\n7.1.1 in 10.0.0), so no release from 9.1.1 onward is affected. Solr 8.x and earlier are out of scope\nfor this CVE: they used the unrelated `org.codehaus.woodstox:woodstox-core-asl` artifact, not\n`com.fasterxml.woodstox:woodstox-core` (the migration in SOLR-10702 introduced the affected artifact\nat 9.0.0). Solr 9.0.0 and 9.1.0 are both end of life.", "status_notes": "Affected Apache Solr versions: 9.0.0-9.1.0." }, { "vulnerability": { "name": "CVE-2025-12183" }, "products": [ { "@id": "pkg:maven/org.lz4/lz4-java@1.8.0" } ], "status": "not_affected", "timestamp": "2026-08-13T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Two issues in the `lz4-java` codec:\n\n* **CVE-2025-12183** \u2014 several lz4-java compression/decompression implementations do not guard against\n out-of-bounds memory access (fixed in `lz4-java` 1.8.1).\n* **CVE-2025-66566** \u2014 decompressor implementations insufficiently clear their buffers, allowing a\n caller to read leftover contents of a previously used buffer (fixed in `lz4-java` 1.10.1).\n\nBoth require an application to drive lz4-java's (de)compression APIs with attacker-influenced\ninput/buffers.\n\nSolr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where it is\nused by the embedded Apache Kafka client for LZ4 compression of cross-datacenter replication messages.\nKafka manages its own internal, validated buffers and does not forward attacker-controlled data into\nthe vulnerable code paths, and the replication stream flows through an operator-controlled Kafka\npipeline rather than untrusted external input. The `cross-dc` module is not part of a default Solr\ninstallation, and no Solr request path reaches these lz4-java routines.\n\nSolr shipped an affected `org.lz4:lz4-java` 1.8.0 from 9.8.0 (when the `cross-dc` module first bundled\nit) through 10.0.0; releases 9.7.0 and earlier, and the 8.x line, ship no `lz4-java`. The fix is\nalready on all active development branches: `branch_9x`, `branch_10x`, and `main` migrated to the\nmaintained community fork `at.yawk.lz4:lz4-java` 1.10.1, which is past both fixes (1.8.1 and 1.10.1),\nso the next releases (9.11, 10.1) will not be affected. Note this upgrade did not require Apache Kafka\nto update first \u2014 Kafka still declares the old `org.lz4:lz4-java`, and Solr replaced that transitive\ndependency with the fork directly.", "status_notes": "Affected Apache Solr versions: 9.8.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-66566" }, "products": [ { "@id": "pkg:maven/org.lz4/lz4-java@1.8.0" } ], "status": "not_affected", "timestamp": "2026-08-13T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "Two issues in the `lz4-java` codec:\n\n* **CVE-2025-12183** \u2014 several lz4-java compression/decompression implementations do not guard against\n out-of-bounds memory access (fixed in `lz4-java` 1.8.1).\n* **CVE-2025-66566** \u2014 decompressor implementations insufficiently clear their buffers, allowing a\n caller to read leftover contents of a previously used buffer (fixed in `lz4-java` 1.10.1).\n\nBoth require an application to drive lz4-java's (de)compression APIs with attacker-influenced\ninput/buffers.\n\nSolr is **not affected**. `lz4-java` is bundled only by the optional `cross-dc` module, where it is\nused by the embedded Apache Kafka client for LZ4 compression of cross-datacenter replication messages.\nKafka manages its own internal, validated buffers and does not forward attacker-controlled data into\nthe vulnerable code paths, and the replication stream flows through an operator-controlled Kafka\npipeline rather than untrusted external input. The `cross-dc` module is not part of a default Solr\ninstallation, and no Solr request path reaches these lz4-java routines.\n\nSolr shipped an affected `org.lz4:lz4-java` 1.8.0 from 9.8.0 (when the `cross-dc` module first bundled\nit) through 10.0.0; releases 9.7.0 and earlier, and the 8.x line, ship no `lz4-java`. The fix is\nalready on all active development branches: `branch_9x`, `branch_10x`, and `main` migrated to the\nmaintained community fork `at.yawk.lz4:lz4-java` 1.10.1, which is past both fixes (1.8.1 and 1.10.1),\nso the next releases (9.11, 10.1) will not be affected. Note this upgrade did not require Apache Kafka\nto update first \u2014 Kafka still declares the old `org.lz4:lz4-java`, and Solr replaced that transitive\ndependency with the fork directly.", "status_notes": "Affected Apache Solr versions: 9.8.0-10.0.0." }, { "vulnerability": { "name": "CVE-2025-24970" }, "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.93.Final" }, { "@id": "pkg:maven/io.netty/netty-handler@4.1.99.Final" } ], "status": "not_affected", "timestamp": "2026-08-23T00:00:00Z", "impact_statement": "CVE-2025-24970 is a flaw in Netty's `SslHandler`: when the native (OpenSSL/BoringSSL, via\n`netty-tcnative`) TLS engine is in use, a specially crafted packet received during TLS\nprocessing is not properly validated, which can trigger a native crash (JVM segfault) rather\nthan a clean exception. It affects Netty `netty-handler` versions 4.1.91.Final through\n4.1.117.Final; fixed in 4.1.118.Final. The 4.2.x release line is not in the affected range at\nall \u2014 4.2.0.Final was cut after the fix had already landed upstream.\n\nSolr shipped an affected `netty-handler` from 9.3.0 (4.1.93.Final) through 9.9.0\n(4.1.114.Final), arriving as a transitive runtime dependency of `io.grpc:grpc-netty`, used only\nby the optional **opentelemetry** module's OTLP gRPC trace exporter. Solr 9.10.0 onward already\nships Netty 4.2.6.Final or later \u2014 outside the affected range \u2014 so no currently released Solr\nversion bundles a vulnerable `netty-handler`. Solr is **not affected** even on the older,\nalready-released 9.3.0\u20139.9.0 line:\n\n* **The opentelemetry module is optional and disabled by default.** It must be explicitly\n enabled (e.g. via `-Dsolr.modules=opentelemetry`) before `grpc-netty`, and therefore\n `netty-handler`, is even loaded.\n* **Netty is used only as an outbound gRPC client dialing the operator's own configured OTLP\n collector**, not as a listener accepting arbitrary inbound connections. `SslHandler`'s\n crafted-packet validation only matters for TLS data arriving from the remote peer on that\n connection \u2014 here, the operator-designated collector endpoint, not an attacker-facing socket.\n* **Solr's own request-handling surface is Jetty, not Netty.** Every attacker-facing API call\n Solr accepts is parsed and served by Jetty; `io.netty` code is never invoked to process\n inbound requests to Solr itself.\n* Exploitation would additionally require the operator to have pointed OTLP export at a\n compromised or malicious collector (or accepted an on-path attacker on that egress route) \u2014\n a threat model outside standard use of this optional telemetry feature.\n\nNo released Solr version ships a fix for this specific line, because none currently needs one:\n9.10.0+ already carries a post-fix Netty. The `branch_9x` (\u2192 9.11.0) and `main`/`branch_10x`\n(\u2192 10.x) development branches have since moved further still, to Netty 4.2.15.Final and\n4.2.17.Final respectively \u2014 picked up incidentally through routine dependency updates rather\nthan a targeted SOLR-17826 fix commit. SOLR-17826 remains open upstream and should be closed\nout to reflect that no supported or in-development Solr line is exposed.", "status_notes": "Affected Apache Solr versions: 9.3.0-9.9.0." }, { "vulnerability": { "name": "CVE-2026-48779" }, "products": [ { "@id": "ws-8.18.0.tgz" } ], "status": "not_affected", "timestamp": "2026-08-25T00:00:00Z", "justification": "vulnerable_code_not_present", "impact_statement": "CVE-2026-48779 is a memory-exhaustion denial-of-service issue in the Node.js `ws` WebSocket library:\na peer that sends a high volume of exceptionally small message fragments can force the receiving side\nto allocate and retain structural wrappers far larger than the documented message-size limit,\neventually exhausting memory. It affects `ws` 8.0.0 through 8.20.x; fixed in 8.21.0 (with backports\nto the 5.x/6.x/7.x lines for older major versions).\n\nSolr is **not affected**. `ws` is pinned in `kotlin-js-store/wasm/yarn.lock`, an auto-generated\nlockfile for the Kotlin/Wasm build toolchain that compiles the new Compose-based Admin UI\n(`solr/ui`). It is a transitive dependency of that toolchain's Node.js-based dev-server/test-runner\ntooling, not of Solr's own code. `ws` depends on Node.js's native TCP socket APIs, which don't exist\nin a browser sandbox -- it is therefore not possible for it to be bundled into the actual\nbrowser-executable Wasm/JS output that ships to end users and runs in their browser. This isn't a\ncase of unreachable-but-present code; the vulnerable component is never part of the shipped product\nartifact at all, only of the build/test pipeline that produces it.\n\n`ws` has been present in `solr/ui`'s build tooling since it was first introduced (shipped in the\n10.0.0 release at `ws@8.18.0`/`ws@8.18.3`, both within the affected range). `branch_9x` doesn't have\nthis module at all. Since this dependency never reaches a shipped artifact, no application-level fix\nis required; bumping it is worth doing as routine build-tooling hygiene regardless, since a compromised\nor misbehaving local/CI dev-server dependency is still worth avoiding even without direct product\nexposure.", "status_notes": "Affected Apache Solr versions: 10.0.0." }, { "vulnerability": { "name": "CVE-2026-54399" }, "products": [ { "@id": "httpcore5-5.3.5.jar" } ], "status": "not_affected", "timestamp": "2026-08-25T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-54399 is an uncontrolled-resource-consumption issue in Apache HttpComponents Core's HTTP/1.1\nmessage parser: a remote peer can send messages with an excessive number of headers or excessive\nheader length, exhausting memory and causing a denial of service. It affects `httpcore5` 5.4.2 and\nearlier (and 5.5-beta1 and earlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5` is bundled transitively by\n`org.apache.calcite.avatica:avatica-core`, which uses it to support Avatica's *optional remote-JDBC*\nHTTP transport -- see the companion VEX entry for CVE-2026-64607 (`httpclient5`) for the full\nreachability analysis, which applies identically here: Solr's `/sql` handler never uses Avatica's\nremote HTTP transport, only the local embedded `CalciteConnection`, so `httpcore5`'s HTTP/1.1 message\nparser is never invoked to process any inbound message, trusted or otherwise. The dependency is\n`permitUnusedDeclared` in Solr's own build and shipped only via the optional `solr:modules:sql`\nmodule.\n\nSolr has shipped an affected `httpcore5` since at least 9.1.0 (through 10.0.0, and continuing on\n`branch_10x`/`main` at 5.3.5). `branch_9x` has since moved to 5.4.3, exactly the fix version --\npicked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the\ncode path is unreachable regardless, no fix is required on `branch_10x`/`main` either.", "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-54428" }, "products": [ { "@id": "httpcore5-h2-5.3.4.jar" } ], "status": "not_affected", "timestamp": "2026-08-25T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-54428 is an allocation-without-limits issue in Apache HttpComponents Core's HTTP/2 HPACK\ndecoder: before an HTTP/2 peer's `SETTINGS` frame is acknowledged, the configured header list size\nlimit isn't yet applied, so a remote peer can send oversized compressed header blocks and exhaust\nmemory, causing a denial of service. It affects `httpcore5-h2` 5.4.2 and earlier (and 5.5-beta1 and\nearlier); fixed in 5.4.3.\n\nSolr is **not affected**. `httpcore5-h2` is bundled transitively by\n`org.apache.calcite.avatica:avatica-core`, which uses it to support Avatica's *optional remote-JDBC*\nHTTP/2 transport -- see the companion VEX entry for CVE-2026-64607 (`httpclient5`) for the full\nreachability analysis, which applies identically here: Solr's `/sql` handler never uses Avatica's\nremote HTTP transport, only the local embedded `CalciteConnection`, so the HPACK decoder this CVE\nconcerns -- which only runs when HttpComponents is actually acting as an HTTP/2 endpoint -- is never\ninvoked. The dependency is `permitUnusedDeclared` in Solr's own build and shipped only via the\noptional `solr:modules:sql` module.\n\nSolr has shipped an affected `httpcore5-h2` since at least 9.1.0 (through 10.0.0, and continuing on\n`branch_10x`/`main` at 5.3.4). `branch_9x` has since moved to 5.4.3, exactly the fix version --\npicked up incidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the\ncode path is unreachable regardless, no fix is required on `branch_10x`/`main` either.", "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0." }, { "vulnerability": { "name": "CVE-2026-64607" }, "products": [ { "@id": "httpclient5-5.5.jar" } ], "status": "not_affected", "timestamp": "2026-08-25T00:00:00Z", "justification": "vulnerable_code_not_in_execute_path", "impact_statement": "CVE-2026-64607 (medium severity) is a connection-leak bug in Apache HttpComponents Client's classic\n(blocking) I/O model: if a response has an invalid or unsupported `Content-Encoding` header, the\nclient fails to release the underlying connection back to the connection manager, eventually\nexhausting the pool and causing a denial of service. It does not affect HttpClient's async I/O model.\nIt affects `httpclient5` from 5.0-alpha1 through 5.6.2; fixed in 5.6.3.\n\nSolr is **not affected**. `httpclient5` (along with `httpcore5` and `httpcore5-h2`, covered in\nseparate VEX entries for their own CVEs) is bundled transitively by `org.apache.calcite.avatica:avatica-core`,\nwhich uses it to support Avatica's *optional remote-JDBC* transport -- connecting to a remote Avatica\nserver over HTTP. Solr's own `/sql` handler (`CalciteSolrDriver`) only ever opens a local, in-process\n`org.apache.calcite.jdbc.CalciteConnection`; there is no `org.apache.hc.client5`/`org.apache.hc.core5`\nusage anywhere in `solr/modules/sql`'s source, and Solr never acts as an Avatica HTTP client or server.\nThe dependency has in fact been marked `permitUnusedDeclared` in Solr's own build since at least the\n10.0.0 release, confirming the build's own dependency-analysis tooling already recognized it as\npresent-but-unused. It's also shipped only via the optional `solr:modules:sql` module -- every other\nplace it appears (`solrj-streaming`, `solr-ref-guide`, `webapp`) is test-scope only, not shipped.\n\nSolr has shipped an affected `httpclient5` since at least 9.1.0 (through 10.0.0, and continuing on\n`branch_10x`/`main` at 5.5). `branch_9x` has since moved to 5.6.4, past the fix -- picked up\nincidentally via routine dependency maintenance, not a targeted fix for this CVE. Since the code path\nis unreachable regardless, no fix is required on `branch_10x`/`main` either.", "status_notes": "Affected Apache Solr versions: 9.1.0-10.0.0." } ] }