CVE Security Report Legacy - SICS Desktop App
The report contains data retrieved from the National Vulnerability Database: https://nvd.nist.gov, NPM Public Advisories: https://www.npmjs.com/advisories, and the RetireJS community.
| Name | Description | CWE | CVSS v2.0 Severity | CVSS v3.0 Severity | Dependency | Products |
|---|---|---|---|---|---|---|
| CVE-2025-48976 | Allocation of resources for multipart headers with insufficient limits enabled a DoS vulnerability in Apache Commons FileUpload. This issue affects Apache Commons FileUpload: from 1.0 before 1.6; from 2.0.0-M1 before 2.0.0-M4. Users are recommended to upgrade to versions 1.6 or 2.0.0-M4, which fix the issue. | CWE-770 | HIGH | commons-fileupload-1.5.jar | ||
| CVE-2025-5222 | A stack buffer overflow was found in Internationl components for unicode (ICU ). While running the genrb binary, the 'subtag' struct overflowed at the SRBRoot::addTag function. This issue may lead to memory corruption and local arbitrary code execution. | CWE-120 | HIGH | icu4j-76.1.jar | ||
| CVE-2025-24970 | Netty, an asynchronous, event-driven network application framework, has a vulnerability starting in version 4.1.91.Final and prior to version 4.1.118.Final. When a special crafted packet is received via SslHandler it doesn't correctly handle validation of such a packet in all cases which can lead to a native crash. Version 4.1.118.Final contains a patch. As workaround its possible to either disable the usage of the native SSLEngine or change the code manually. | CWE-20 | HIGH | netty-transport-4.1.117.Final.jar | ||
| CVE-2025-58057 | Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In netty-codec-compression versions 4.1.124.Final and below, and netty-codec versions 4.2.4.Final and below, when supplied with specially crafted input, BrotliDecoder and certain other decompression decoders will allocate a large number of reachable byte buffers, which can lead to denial of service. BrotliDecoder.decompress has no limit in how often it calls pull, decompressing data 64K bytes at a time. The buffers are saved in the output list, and remain reachable until OOM is hit. This is fixed in versions 4.1.125.Final of netty-codec and 4.2.5.Final of netty-codec-compression. | CWE-409 | HIGH | netty-transport-4.1.117.Final.jar | ||
| CVE-2025-25193 | Netty, an asynchronous, event-driven network application framework, has a vulnerability in versions up to and including 4.1.118.Final. An unsafe reading of environment file could potentially cause a denial of service in Netty. When loaded on an Windows application, Netty attempts to load a file that does not exist. If an attacker creates such a large file, the Netty application crash. A similar issue was previously reported as CVE-2024-47535. This issue was fixed, but the fix was incomplete in that null-bytes were not counted against the input limit. Commit d1fbda62d3a47835d3fb35db8bd42ecc205a5386 contains an updated fix. | CWE-400 | MEDIUM | netty-transport-4.1.117.Final.jar | ||
| CVE-2025-58056 | Netty is an asynchronous event-driven network application framework for development of maintainable high performance protocol servers and clients. In versions 4.1.124.Final, and 4.2.0.Alpha3 through 4.2.4.Final, Netty incorrectly accepts standalone newline characters (LF) as a chunk-size line terminator, regardless of a preceding carriage return (CR), instead of requiring CRLF per HTTP/1.1 standards. When combined with reverse proxies that parse LF differently (treating it as part of the chunk extension), attackers can craft requests that the proxy sees as one request but Netty processes as two, enabling request smuggling attacks. This is fixed in versions 4.1.125.Final and 4.2.5.Final. | CWE-444 | HIGH | netty-transport-4.1.117.Final.jar | ||
| CVE-2025-49146 | pgjdbc is an open source postgresql JDBC Driver. From 42.7.4 and until 42.7.7, when the PostgreSQL JDBC driver is configured with channel binding set to required (default value is prefer), the driver would incorrectly allow connections to proceed with authentication methods that do not support channel binding (such as password, MD5, GSS, or SSPI authentication). This could allow a man-in-the-middle attacker to intercept connections that users believed were protected by channel binding requirements. This vulnerability is fixed in 42.7.7. | CWE-287 | HIGH | postgresql-42.7.5.jar | ||
| CVE-2024-45216 | Improper Authentication vulnerability in Apache Solr. Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass. A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path. This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing. This issue affects Apache Solr: from 5.3.0 before 8.11.4, from 9.0.0 before 9.7.0. Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue. | CWE-863 | CRITICAL | solr-api-9.4.1.jar | ||
| CVE-2024-45217 | Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the 'trusted' metadata. ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to 'trusted' ConfigSets that may not have been created with an Authenticated request. 'trusted' ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized. This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization. Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise. | CWE-1188 | HIGH | solr-api-9.4.1.jar | ||
| CVE-2025-24814 | Core creation allows users to replace 'trusted' configset files with arbitrary configuration Solr instances that (1) use the 'FileSystemConfigSetService' component (the default in 'standalone' or 'user-managed' mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual 'trusted' configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as 'trusted' and can use '<lib>' tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin. This issue affects all Apache Solr versions up through Solr 9.7. Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from 'FileSystemConfigSetService'). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of '<lib>' tags by default. | CWE-250 | MEDIUM | solr-api-9.4.1.jar | ||
| CVE-2024-52012 | Relative Path Traversal vulnerability in Apache Solr. Solr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the 'configset upload' API. Commonly known as a 'zipslip', maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem. This issue affects Apache Solr: from 6.6 through 9.7.0. Users are recommended to upgrade to version 9.8.0, which fixes the issue. Users unable to upgrade may also safely prevent the issue by using Solr's 'Rule-Based Authentication Plugin' to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users. | CWE-23 | MEDIUM | solr-api-9.4.1.jar | ||
| CVE-2024-45216 | Improper Authentication vulnerability in Apache Solr. Solr instances using the PKIAuthenticationPlugin, which is enabled by default when Solr Authentication is used, are vulnerable to Authentication bypass. A fake ending at the end of any Solr API URL path, will allow requests to skip Authentication while maintaining the API contract with the original URL Path. This fake ending looks like an unprotected API path, however it is stripped off internally after authentication but before API routing. This issue affects Apache Solr: from 5.3.0 before 8.11.4, from 9.0.0 before 9.7.0. Users are recommended to upgrade to version 9.7.0, or 8.11.4, which fix the issue. | CWE-863 | CRITICAL | solr-solrj-zookeeper-9.4.1.jar | ||
| CVE-2024-45217 | Insecure Default Initialization of Resource vulnerability in Apache Solr. New ConfigSets that are created via a Restore command, which copy a configSet from the backup and give it a new name, are created without setting the 'trusted' metadata. ConfigSets that do not contain the flag are trusted implicitly if the metadata is missing, therefore this leads to 'trusted' ConfigSets that may not have been created with an Authenticated request. 'trusted' ConfigSets are able to load custom code into classloaders, therefore the flag is supposed to only be set when the request that uploads the ConfigSet is Authenticated & Authorized. This issue affects Apache Solr: from 6.6.0 before 8.11.4, from 9.0.0 before 9.7.0. This issue does not affect Solr instances that are secured via Authentication/Authorization. Users are primarily recommended to use Authentication and Authorization when running Solr. However, upgrading to version 9.7.0, or 8.11.4 will mitigate this issue otherwise. | CWE-1188 | HIGH | solr-solrj-zookeeper-9.4.1.jar | ||
| CVE-2025-24814 | Core creation allows users to replace 'trusted' configset files with arbitrary configuration Solr instances that (1) use the 'FileSystemConfigSetService' component (the default in 'standalone' or 'user-managed' mode), and (2) are running without authentication and authorization are vulnerable to a sort of privilege escalation wherein individual 'trusted' configset files can be ignored in favor of potentially-untrusted replacements available elsewhere on the filesystem. These replacement config files are treated as 'trusted' and can use '<lib>' tags to add to Solr's classpath, which an attacker might use to load malicious code as a searchComponent or other plugin. This issue affects all Apache Solr versions up through Solr 9.7. Users can protect against the vulnerability by enabling authentication and authorization on their Solr clusters or switching to SolrCloud (and away from 'FileSystemConfigSetService'). Users are also recommended to upgrade to Solr 9.8.0, which mitigates this issue by disabling use of '<lib>' tags by default. | CWE-250 | MEDIUM | solr-solrj-zookeeper-9.4.1.jar | ||
| CVE-2024-52012 | Relative Path Traversal vulnerability in Apache Solr. Solr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the 'configset upload' API. Commonly known as a 'zipslip', maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem. This issue affects Apache Solr: from 6.6 through 9.7.0. Users are recommended to upgrade to version 9.8.0, which fixes the issue. Users unable to upgrade may also safely prevent the issue by using Solr's 'Rule-Based Authentication Plugin' to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users. | CWE-23 | MEDIUM | solr-solrj-zookeeper-9.4.1.jar |
This report was generated 09.09.2025, 17:12:43 UTC, using dependency-check version: 12.1.1.