CveMateVulnerability intelligence

Netapp Oncommand System Manager vulnerabilities

27 vulnerabilities

Known vulnerabilities in Netapp Oncommand System Manager, newest first, with CVSS severity, EPSS, KEV listings, ransomware use and the affected versions.

CVE-2018-12538eclipsejetty+138y ago22-06-2018 19:00

In Eclipse Jetty versions 9.4.0 through 9.4.8, when using the optional Jetty provided FileSessionDataStore for persistent storage of HttpSession details, it is possible for a malicious user to access/hijack other HttpSessions and even delete unmatched HttpSessions present in the FileSystem's storage for the FileSessionDataStore.CVE-2013-3322netapponcommand_system_manager6y ago31-01-2020 13:40

NetApp OnCommand System Manager 2.1 and earlier allows remote attackers to inject arbitrary commands in the Halt/Reboot interface.CVE-2013-3320netapponcommand_system_manager6y ago29-01-2020 21:34

Cross-site Scripting (XSS) vulnerability in NetApp OnCommand System Manager before 2.2 allows remote attackers to inject arbitrary web script or HTML via the 'full-name' and 'comment' fields.CVE-2013-3321netapponcommand_system_manager6y ago29-01-2020 21:40

NetApp OnCommand System Manager 2.1 and earlier allows remote attackers to include arbitrary files through specially crafted requests to the "diagnostic" page using the SnapMirror log path parameter.CVE-2016-5047netapponcommand_system_manager10y ago01-09-2016 10:00

NetApp OnCommand System Manager 8.3.x before 8.3.2P5 allows remote authenticated users to cause a denial of service via unspecified vectors.CVE-2016-5045netapponcommand_system_manager9y ago03-07-2017 16:00

NetApp OnCommand System Manager before 9.0 allows remote attackers to obtain sensitive credentials via vectors related to cluster peering setup.CVE-2016-3063netapponcommand_system_manager9y ago07-02-2017 17:00

Multiple functions in NetApp OnCommand System Manager before 8.3.2 do not properly escape special characters, which allows remote authenticated users to execute arbitrary API calls via unspecified vectors.CVE-2020-13935apachetomcat+256y ago14-07-2020 15:00

The payload length in a WebSocket frame was not correctly validated in Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M1 to 9.0.36, 8.5.0 to 8.5.56 and 7.0.27 to 7.0.104. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service.CVE-2020-13934apachetomcat+186y ago14-07-2020 14:59

An h2c direct connection to Apache Tomcat 10.0.0-M1 to 10.0.0-M6, 9.0.0.M5 to 9.0.36 and 8.5.1 to 8.5.56 did not release the HTTP/1.1 processor after the upgrade to HTTP/2. If a sufficient number of such requests were made, an OutOfMemoryException could occur leading to a denial of service.CVE-2020-1938apacheapache tomcat+61KEV6y ago24-02-2020 21:19

When using the Apache JServ Protocol (AJP), care must be taken when trusting incoming connections to Apache Tomcat. Tomcat treats AJP connections as having higher trust than, for example, a similar HTTP connection. If such connections are available to an attacker, they can be exploited in ways that may be surprising. In Apache Tomcat 9.0.0.M1 to 9.0.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99, Tomcat shipped with an AJP Connector enabled by default that listened on all configured IP addresses. It was expected (and recommended in the security guide) that this Connector would be disabled if not required. This vulnerability report identified a mechanism that allowed: - returning arbitrary files from anywhere in the web application - processing any file in the web application as a JSP Further, if the web application allowed file upload and stored those files within the web application (or the attacker was able to control the content of the web application by some other means) then this, along with the ability to process a file as a JSP, made remote code execution possible. It is important to note that mitigation is only required if an AJP port is accessible to untrusted users. Users wishing to take a defence-in-depth approach and block the vector that permits returning arbitrary files and execution as JSP may upgrade to Apache Tomcat 9.0.31, 8.5.51 or 7.0.100 or later. A number of changes were made to the default AJP Connector configuration in 9.0.31 to harden the default configuration. It is likely that users upgrading to 9.0.31, 8.5.51 or 7.0.100 or later will need to make small changes to their configurations.CVE-2020-1935apacheapache tomcat+366y ago24-02-2020 21:11

In Apache Tomcat 9.0.0.M1 to 9.0.30, 8.5.0 to 8.5.50 and 7.0.0 to 7.0.99 the HTTP header parsing code used an approach to end-of-line parsing that allowed some invalid HTTP headers to be parsed as valid. This led to a possibility of HTTP Request Smuggling if Tomcat was located behind a reverse proxy that incorrectly handled the invalid Transfer-Encoding header in a particular manner. Such a reverse proxy is considered unlikely.CVE-2020-11996apacheapache tomcat+426y ago26-06-2020 16:27

A specially crafted sequence of HTTP/2 requests sent to Apache Tomcat 10.0.0-M1 to 10.0.0-M5, 9.0.0.M1 to 9.0.35 and 8.5.0 to 8.5.55 could trigger high CPU usage for several seconds. If a sufficient number of such requests were made on concurrent HTTP/2 connections, the server could become unresponsive.CVE-2020-11023chainguardkeycloak-26.6+271KEV6y ago29-04-2020 00:00

In jQuery versions greater than or equal to 1.0.3 and before 3.5.0, passing HTML containing <option> elements from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.CVE-2020-11022chainguardkeycloak-26.6+1486y ago29-04-2020 00:00

In jQuery starting with 1.12.0 and before 3.5.0, passing HTML from untrusted sources - even after sanitizing it - to one of jQuery's DOM manipulation methods (i.e. .html(), .append(), and others) may execute untrusted code. This problem is patched in jQuery 3.5.0.CVE-2020-17527apache software foundationapache tomcat+285y ago03-12-2020 18:30

While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests.CVE-2020-7656ubuntujquery+116y ago19-05-2020 00:00

jquery prior to 1.9.0 allows Cross-site Scripting attacks via the load method. The load method fails to recognize and remove "<script>" HTML tags that contain a whitespace character, i.e: "</script >", which results in the enclosed script logic to be executed.CVE-2020-27218apachekafka+245y ago28-11-2020 00:00

In Eclipse Jetty version 9.4.0.RC0 to 9.4.34.v20201102, 10.0.0.alpha0 to 10.0.0.beta2, and 11.0.0.alpha0 to 11.0.0.beta2, if GZIP request body inflation is enabled and requests from different clients are multiplexed onto a single connection, and if an attacker can send a request with a body that is received entirely but not consumed by the application, then a subsequent request on the same connection will see that body prepended to its body. The attacker will not see any data but may inject data into the body of the subsequent request.CVE-2020-8587netapponcommand_system_manager5y ago08-02-2021 21:36

OnCommand System Manager 9.x versions prior to 9.3P20 and 9.4 prior to 9.4P3 are susceptible to a vulnerability that could allow HTTP clients to cache sensitive responses making them accessible to an attacker who has access to the system where the client runs.CVE-2017-7657chainguardhadoop-fips-3.3.6+248y ago26-06-2018 16:00

In Eclipse Jetty, versions 9.2.x and older, 9.3.x (all configurations), and 9.4.x (non-default configuration with RFC2616 compliance enabled), transfer-encoding chunks are handled poorly. The chunk length parsing was vulnerable to an integer overflow. Thus a large chunk size could be interpreted as a smaller chunk size and content sent as chunk body could be interpreted as a pipelined request. If Jetty was deployed behind an intermediary that imposed some authorization and that intermediary allowed arbitrarily large chunks to be passed on unchanged, then this flaw could be used to bypass the authorization imposed by the intermediary as the fake pipelined request would not be interpreted by the intermediary as a request.CVE-2017-7658chainguardhadoop-fips-3.3.6+268y ago26-06-2018 17:00

In Eclipse Jetty Server, versions 9.2.x and older, 9.3.x (all non HTTP/1.x configurations), and 9.4.x (all HTTP/1.x configurations), when presented with two content-lengths headers, Jetty ignored the second. When presented with a content-length and a chunked encoding header, the content-length was ignored (as per RFC 2616). If an intermediary decided on the shorter length, but still passed on the longer body, then body content could be interpreted by Jetty as a pipelined request. If the intermediary was imposing authorization, the fake pipelined request would bypass that authorization.