This is an automated email from the ASF dual-hosted git repository.
github-bot pushed a commit to branch asf-staging
in repository https://gitbox.apache.org/repos/asf/solr-site.git
The following commit(s) were added to refs/heads/asf-staging by this push:
new fd76daa34 Commit build products
fd76daa34 is described below
commit fd76daa34e323dd7b1d3c5046e92d43ca039bde5
Author: Build Pelican (action) <[email protected]>
AuthorDate: Fri Jun 21 07:29:46 2024 +0000
Commit build products
---
output/security.html | 354 +++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 354 insertions(+)
diff --git a/output/security.html b/output/security.html
index 16fc069d3..94f223598 100644
--- a/output/security.html
+++ b/output/security.html
@@ -656,6 +656,360 @@ Github user <code>s00py</code></p>
<th>state</th>
<th>detail</th>
</tr>
+ <!-- BEGIN STATIC TABLE SOLR-17339 -->
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2022-33980";>CVE-2022-33980</a>
</td>
+ <td>
+ < 9.1
+ </td>
+ <td>
+ commons-configuration2-2.7.jar </td>
+ <td>not affected</td>
+ <td>Solr uses commons-configuration2 for "hadoop-auth" only (for
Kerberos). It is only used for loading Hadoop configuration files that would
only ever be provided by trusted administrators, not externally
(untrusted).</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2022-42889";>CVE-2022-42889</a>
</td>
+ <td>
+ < 9.1
+ </td>
+ <td>
+ commons-text-1.9.jar </td>
+ <td>not affected</td>
+ <td>Solr uses commons-text directly
(StringEscapeUtils.escapeEcmaScript) in LoadAdminUiServlet that is not
vulnerable. Solr also has a "hadoop-auth" module that uses Apache Hadoop which
uses commons-text through commons-configuration2. For Solr, the concern is
limited to loading Hadoop configuration files that would only ever be provided
by trusted administrators, not externally (untrusted).</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2022-25168";>CVE-2022-25168</a>
</td>
+ <td>
+ < 9.1
+ </td>
+ <td>
+ hadoop-common-3.2.2.jar </td>
+ <td>not affected</td>
+ <td>The vulnerable code won't be used by Solr because Solr only is
only using HDFS as a client.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-44832";>CVE-2021-44832</a>
</td>
+ <td>
+ 7.4-8.11.1
+ </td>
+ <td>
+ log4j-core-2.14.1.jar, log4j-core-2.16.0.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-45105";>CVE-2021-45105</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-45046";>CVE-2021-45046</a>
</td>
+ <td>
+ 7.4-8.11.1
+ </td>
+ <td>
+ log4j-core-2.14.1.jar, log4j-core-2.16.0.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2020-13955";>CVE-2020-13955</a>
</td>
+ <td>
+ 8.1.0- today
+ </td>
+ <td>
+ avatica-core-1.13.0.jar, calcite-core-1.18.0.jar
</td>
+ <td>not affected</td>
+ <td>Solr's SQL adapter does not use the vulnerable class "HttpUtils".
Calcite only used it to talk to Druid or Splunk.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-10237";>CVE-2018-10237</a>
</td>
+ <td>
+ 5.4.0-today
+ </td>
+ <td>
+ carrot2-guava-18.0.jar </td>
+ <td>not affected</td>
+ <td>Only used with the Carrot2 clustering engine.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2014-0114";>CVE-2014-0114</a>
</td>
+ <td>
+ 4.9.0-7.5.0
+ </td>
+ <td>
+ commons-beanutils-1.8.3.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2019-10086";>CVE-2019-10086</a>
</td>
+ <td>
+ 8.0.0-8.3.0
+ </td>
+ <td>
+ commons-beanutils-1.9.3.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2012-2098";>CVE-2012-2098</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1324";>CVE-2018-1324</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-11771";>CVE-2018-11771</a>
</td>
+ <td>
+ 4.6.0-today
+ </td>
+ <td>
+ commons-compress (only as part of Ant 1.8.2) </td>
+ <td>not affected</td>
+ <td>Only used in test framework and at build time.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1000632";>CVE-2018-1000632</a>
</td>
+ <td>
+ 4.6.0-today
+ </td>
+ <td>
+ dom4j-1.6.1.jar </td>
+ <td>not affected</td>
+ <td>Only used in Solr tests.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-10237";>CVE-2018-10237</a>
</td>
+ <td>
+ 4.6.0-today
+ </td>
+ <td>
+ guava-*.jar </td>
+ <td>not affected</td>
+ <td>Only used in tests.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-15718";>CVE-2017-15718</a>
</td>
+ <td>
+ 6.6.1-7.6.0
+ </td>
+ <td>
+ hadoop-auth-2.7.4.jar, hadoop-hdfs-2.7.4.jar (all
Hadoop) </td>
+ <td>not affected</td>
+ <td>Does not impact Solr because Solr uses Hadoop as a client
library.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-14952";>CVE-2017-14952</a>
</td>
+ <td>
+ 6.0.0-7.5.0
+ </td>
+ <td>
+ icu4j-56.1.jar, icu4j-59.1.jar </td>
+ <td>not affected</td>
+ <td>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</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-15095";>CVE-2017-15095</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-17485";>CVE-2017-17485</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-7525";>CVE-2017-7525</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-5968";>CVE-2018-5968</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-7489";>CVE-2018-7489</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2019-12086";>CVE-2019-12086</a>, <a
href="https://nvd [...]
+ <td>
+ 4.7.0-today
+ </td>
+ <td>
+ jackson-databind-*.jar </td>
+ <td>not affected</td>
+ <td>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 <a
href="https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062";>https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-y
[...]
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2019-10241";>CVE-2019-10241</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2019-10247";>CVE-2019-10247</a>
</td>
+ <td>
+ 7.7.0-8.2
+ </td>
+ <td>
+ jetty-9.4.14 </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2020-27218";>CVE-2020-27218</a>
</td>
+ <td>
+ 7.3.0-8.8.0
+ </td>
+ <td>
+ jetty-9.4.0 to 9.4.34 </td>
+ <td>not affected</td>
+ <td>Only exploitable through use of Jetty's GzipHandler, which is only
implemented in Embedded Solr Server.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2020-27223";>CVE-2020-27223</a>
</td>
+ <td>
+ 7.3.0-present
+ </td>
+ <td>
+ jetty-9.4.6 to 9.4.36 </td>
+ <td>not affected</td>
+ <td>Only exploitable if Solr's webapp directory is deployed as a
symlink, which is not Solr's default.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2021-33813";>CVE-2021-33813</a>
</td>
+ <td>
+ to present
+ </td>
+ <td>
+ jdom-*.jar </td>
+ <td>not affected</td>
+ <td>JDOM is only used in Solr Cell, which should not be used in
production which makes the vulnerability unexploitable. It is a dependency of
Apache Tika, which has analyzed the issue and determined the vulnerability is
limited to two libraries not commonly used in search applications, see
TIKA-3488 for details. Since Tika should be used outside of Solr, use a version
of Tika which updates the affected libraries if concerned about exposure to
this issue.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1000056";>CVE-2018-1000056</a>
</td>
+ <td>
+ 4.6.0-7.6.0
+ </td>
+ <td>
+ junit-4.10.jar </td>
+ <td>not affected</td>
+ <td>JUnit only used in tests; CVE only refers to a Jenkins plugin not
used by Solr.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2014-7940";>CVE-2014-7940</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2016-6293";>CVE-2016-6293</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2016-7415";>CVE-2016-7415</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-14952";>CVE-2017-14952</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-17484";>CVE-2017-17484</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-7867";>CVE-2017-7867</a>, <a
href="https://nvd.n [...]
+ <td>
+ 7.3.1
+ </td>
+ <td>
+ lucene-analyzers-icu-7.3.1.jar </td>
+ <td>not affected</td>
+ <td>All of these issues apply to the C++ release of ICU and not ICU4J,
which is what Lucene uses.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2019-16869";>CVE-2019-16869</a>
</td>
+ <td>
+ 8.2-8.3
+ </td>
+ <td>
+ netty-all-4.1.29.Final.jar </td>
+ <td>not affected</td>
+ <td>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).</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-14868";>CVE-2017-14868</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2017-14949";>CVE-2017-14949</a>
</td>
+ <td>
+ 5.2.0-today
+ </td>
+ <td>
+ org.restlet-2.3.0.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2015-5237";>CVE-2015-5237</a>
</td>
+ <td>
+ 6.5.0-today
+ </td>
+ <td>
+ protobuf-java-3.1.0.jar </td>
+ <td>not affected</td>
+ <td>Dependency for Hadoop and Calcite. ??</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1471";>CVE-2018-1471</a>
</td>
+ <td>
+ 5.4.0-7.7.2, 8.0-8.3
+ </td>
+ <td>
+ simple-xml-2.7.1.jar </td>
+ <td>not affected</td>
+ <td>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).</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-8088";>CVE-2018-8088</a>
</td>
+ <td>
+ 4.x-today
+ </td>
+ <td>
+ slf4j-api-1.7.24.jar, jcl-over-slf4j-1.7.24.jar,
jul-to-slf4j-1.7.24.jar </td>
+ <td>not affected</td>
+ <td>The reported CVE impacts org.slf4j.ext.EventData, which is not
used in Solr.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1335";>CVE-2018-1335</a>
</td>
+ <td>
+ 7.3.1-7.5.0
+ </td>
+ <td>
+ tika-core.1.17.jar </td>
+ <td>not affected</td>
+ <td>Solr does not run tika-server, so this is not a problem.</td>
+ </tr>
+ <tr>
+ <td>
+ <a href="https://nvd.nist.gov/vuln/detail/CVE-";>CVE-</a> </td>
+ <td>
+ 7.3.1-today
+ </td>
+ <td>
+ tika-core.*.jar </td>
+ <td>not affected</td>
+ <td>All Tika issues that could be Solr vulnerabilities would only be
exploitable if untrusted files are indexed with SolrCell. This is not
recommended in production systems, so Solr does not consider these valid CVEs
for Solr.</td>
+ </tr>
+ <tr>
+ <td>
+ <a href="https://nvd.nist.gov/vuln/detail/CVE-";>CVE-</a> </td>
+ <td>
+ 6.6.2-today
+ </td>
+ <td>
+ velocity-tools-2.0.jar </td>
+ <td>not affected</td>
+ <td>Solr does not ship a Struts jar. This is a transitive POM listing
and not included with Solr (see comment in SOLR-2849).</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2016-6809";>CVE-2016-6809</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1335";>CVE-2018-1335</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1338";>CVE-2018-1338</a>, <a
href="https://nvd.nist.gov/vuln/detail/CVE-2018-1339";>CVE-2018-1339</a>
</td>
+ <td>
+ 5.5.5, 6.2.0-today
+ </td>
+ <td>
+ vorbis-java-tika-0.8.jar </td>
+ <td>not affected</td>
+ <td>See <a
href="https://github.com/Gagravarr/VorbisJava/issues/30";>https://github.com/Gagravarr/VorbisJava/issues/30</a>;
reported CVEs are not related to OggVorbis at all.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2012-0881";>CVE-2012-0881</a>
</td>
+ <td>
+ ~2.9-today
+ </td>
+ <td>
+ xercesImpl-2.9.1.jar </td>
+ <td>not affected</td>
+ <td>Only used in Lucene Benchmarks and Solr tests.</td>
+ </tr>
+ <tr>
+ <td>
+ <a
href="https://nvd.nist.gov/vuln/detail/CVE-2023-51074";>CVE-2023-51074</a>,
GHSA-pfh2-hfmq-phg5 </td>
+ <td>
+ all
+ </td>
+ <td>
+ json-path-2.8.0.jar </td>
+ <td>not affected</td>
+ <td>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.</td>
+ </tr>
+ <!-- END STATIC TABLE SOLR-17339 -->
</table>
</div>
</div>
