WaratekVRT Sign in
Reset
More filters (2)
Columns
Protection: None✕Vendor vmware✕
Overview 227 matches · 0 protected · 3 exploited · 1 CISA KEV · 9 public PoC · 1 EPSS ≥ 0.5
227matches 0protected0.0% 3exploited1.3% 1CISA KEV0.4% 9public PoC4.0% 1EPSS ≥ 0.50.4%
Protected by Waratek 0 0.0% Rule in development 0 0.0% Mitigation candidate 9 4.0% No exploit published 218 96.0%
Critical 25 11.0% High 89 39.2% Medium 100 44.1% Low 13 5.7% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 0 0.0% partly blocked 0 0.0% not blocked 227 100.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 3 1.3% Working exploit published 2 0.9% Proof of concept only 7 3.1% Forecast only 0 0.0% No public exploit 215 94.7%
split by peak 155 / year
No exploit published: 218Mitigation candidate: 9 Low: 13Medium: 100High: 89Critical: 25 not blocked: 227 No public exploit: 215Proof of concept only: 7Working exploit published: 2Exploited: 3
20102 No exploit published2 Medium2 not blocked2 No public exploit2 20111 No exploit published1 Medium1 not blocked1 No public exploit1 20123 Mitigation candidate1 No exploit published2 Medium3 not blocked3 Working exploit published1 No public exploit2 20130 20141 No exploit published1 Medium1 not blocked1 No public exploit1 20150 20160 20177 No exploit published7 Critical2 High5 not blocked7 No public exploit7 20189 No exploit published9 High5 Medium4 not blocked9 No public exploit9 20192 No exploit published2 High1 Medium1 not blocked2 No public exploit2 20204 Mitigation candidate1 No exploit published3 Critical1 Medium3 not blocked4 Exploited1 No public exploit3 20218 Mitigation candidate1 No exploit published7 High4 Medium4 not blocked8 Exploited1 No public exploit7 202214 Mitigation candidate4 No exploit published10 Critical5 High3 Medium5 Low1 not blocked14 Exploited1 Proof of concept only3 No public exploit10 202316 No exploit published16 Critical2 High6 Medium8 not blocked16 Proof of concept only1 No public exploit15 20245 No exploit published5 High3 Medium2 not blocked5 No public exploit5 20250 2026155 Mitigation candidate2 No exploit published153 Critical15 High62 Medium66 Low12 not blocked155 Working exploit published1 Proof of concept only3 No public exploit151
201020122014201620182020202220242026
227 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed. ‹ prev page 3 of 3 next ›
CVE Severity Published▾ Status Exploitation Description
CVE-2020-5413 Critical 2020-07-31 No exploit published No public exploit Spring Integration framework provides Kryo Codec implementations as an alternative for Java (de)serialization. When Kryo is configured with default options, all unregistered classes are resolved on demand. This leads to the "deserialization gadgets" exploit when provided data contains malicious code for execution during deserialization. In order to protect against this type of attack, Kryo can be configured to require a set of trusted classes for (de)serialization. Spring Integration should be proactive against blocking unknown "deserialization gadgets" when configuring Kryo in code.
CVE-2020-5408 Medium 2020-05-14 No exploit published No public exploit Spring Security versions 5.3.x prior to 5.3.2, 5.2.x prior to 5.2.4, 5.1.x prior to 5.1.10, 5.0.x prior to 5.0.16 and 4.2.x prior to 4.2.16 use a fixed null initialization vector with CBC Mode in the implementation of the queryable text encryptor. A malicious user with access to the data that has been encrypted using such an encryptor may be able to derive the unencrypted values using a dictionary attack.
CVE-2019-11272 High 2019-06-26 No exploit published No public exploit Spring Security, versions 4.2.x up to 4.2.12, and older unsupported versions support plain text passwords using PlaintextPasswordEncoder. If an application using an affected version of Spring Security is leveraging PlaintextPasswordEncoder and a user has a null encoded password, a malicious user (or attacker) can authenticate using a password of "null".
CVE-2019-3795 Medium 2019-04-09 No exploit published No public exploit Spring Security versions 4.2.x prior to 4.2.12, 5.0.x prior to 5.0.12, and 5.1.x prior to 5.1.5 contain an insecure randomness vulnerability when using SecureRandomFactoryBean#setSeed to configure a SecureRandom instance. In order to be impacted, an honest application must provide a seed and make the resulting random material available to an attacker for inspection.
CVE-2018-15801 High 2018-12-19 No exploit published No public exploit Spring Security versions 5.1.x prior to 5.1.2 contain an authorization bypass vulnerability during JWT issuer validation. In order to be impacted, the same private key for an honest issuer and a malicious user must be used when signing JWTs. In that case, a malicious user could fashion signed JWTs with the malicious issuer URL that may be granted for the honest issuer.
CVE-2018-11087 Medium 2018-09-14 No exploit published No public exploit Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. A malicious user that has the ability to intercept traffic would be able to view data in transit.
CVE-2018-11040 High 2018-06-25 No exploit published No public exploit Spring Framework, versions 5.0.x prior to 5.0.7 and 4.3.x prior to 4.3.18 and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers and MappingJackson2JsonView for browser requests. Both are not enabled by default in Spring Framework nor Spring Boot, however, when MappingJackson2JsonView is configured in an application, JSONP support is automatically ready to use through the "jsonp" and "callback" JSONP parameters, enabling cross-domain requests.
CVE-2018-11039 Medium 2018-06-25 No exploit published No public exploit Spring Framework (versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions) allow web applications to change the HTTP request method to any HTTP method (including TRACE) using the HiddenHttpMethodFilter in Spring MVC. If an application has a pre-existing XSS vulnerability, a malicious user (or attacker) can use this filter to escalate to an XST (Cross Site Tracing) attack.
CVE-2018-1258 High 2018-05-11 No exploit published No public exploit Spring Framework version 5.0.5 when used in combination with any versions of Spring Security contains an authorization bypass when using method security. An unauthorized malicious user can gain unauthorized access to methods that should be restricted.
CVE-2018-1257 Medium 2018-05-11 No exploit published No public exploit Spring Framework, versions 5.0.x prior to 5.0.6, versions 4.3.x prior to 4.3.17, and older unsupported versions allows applications to expose STOMP over WebSocket endpoints with a simple, in-memory STOMP broker through the spring-messaging module. A malicious user (or attacker) can craft a message to the broker that can lead to a regular expression, denial of service attack.
CVE-2018-1256 High 2018-05-07 No exploit published No public exploit Spring Cloud SSO Connector, version 2.1.2, contains a regression which disables issuer validation in resource servers that are not bound to the SSO service. In PCF deployments with multiple SSO service plans, a remote attacker can authenticate to unbound resource servers which use this version of the SSO Connector with tokens generated from another service plan.
CVE-2018-1274 High 2018-04-18 No exploit published No public exploit Spring Data Commons, versions 1.13 to 1.13.10, 2.0 to 2.0.5, and older unsupported versions, contain a property path parser vulnerability caused by unlimited resource allocation. An unauthenticated remote malicious user (or attacker) can issue requests against Spring Data REST endpoints or endpoints using property path parsing which can cause a denial of service (CPU and memory consumption).
CVE-2018-1199 Medium 2018-03-16 No exploit published No public exploit Spring Security (Spring Security 4.1.x before 4.1.5, 4.2.x before 4.2.4, and 5.0.x before 5.0.1; and Spring Framework 4.3.x before 4.3.14 and 5.0.x before 5.0.3) does not consider URL path parameters when processing security constraints. By adding a URL path parameter with special encodings, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. In this particular attack, different character encodings used in path parameters allows secured Spring MVC static resource URLs to be bypassed.
CVE-2017-4995 High 2017-11-27 No exploit published No public exploit An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets." Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security's Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) "deserialization gadget" that allows code execution present on the classpath. Jackson provides a blacklisting approach to protecting against this type of attack, but Spring Security should be proactive against blocking unknown "deserialization gadgets" when Spring Security enables default typing.
CVE-2015-5258 High 2017-08-22 No exploit published No public exploit Cross-site request forgery (CSRF) vulnerability in springframework-social before 1.1.3.
CVE-2016-5007 High 2017-05-25 No exploit published No public exploit Both Spring Security 3.2.x, 4.0.x, 4.1.0 and the Spring Framework 3.2.x, 4.0.x, 4.1.x, 4.2.x rely on URL pattern mappings for authorization and for mapping requests to controllers respectively. Differences in the strictness of the pattern matching mechanisms, for example with regards to space trimming in path segments, can lead Spring Security to not recognize certain paths as not protected that are in fact mapped to Spring MVC controllers that should be protected. The problem is compounded by the fact that the Spring Framework provides richer features with regards to pattern matching as well as by the fact that pattern matching in each Spring Security and the Spring Framework can easily be customized creating additional differences.
CVE-2015-5211 Critical 2017-05-25 No exploit published No public exploit Under some situations, the Spring Framework 4.2.0 to 4.2.1, 4.0.0 to 4.1.7, 3.2.0 to 3.2.14 and older unsupported versions is vulnerable to a Reflected File Download (RFD) attack. The attack involves a malicious user crafting a URL with a batch script extension that results in the response being downloaded rather than rendered and also includes some input reflected in the response.
CVE-2014-3527 Critical 2017-05-25 No exploit published No public exploit When using the CAS Proxy ticket authentication from Spring Security 3.1 to 3.2.4 a malicious CAS Service could trick another CAS Service into authenticating a proxy ticket that was not associated. This is due to the fact that the proxy ticket authentication uses the information from the HttpServletRequest which is populated based upon untrusted information within the HTTP request. This means if there are access control restrictions on which CAS services can authenticate to one another, those restrictions can be bypassed. If users are not using CAS Proxy tickets and not basing access control decisions based upon the CAS Service, then there is no impact to users.
CVE-2014-0097 High 2017-05-25 No exploit published No public exploit The ActiveDirectoryLdapAuthenticator in Spring Security 3.2.0 to 3.2.1 and 3.1.0 to 3.1.5 does not check the password length. If the directory allows anonymous binds then it may incorrectly authenticate a user who supplies an empty password.
CVE-2016-9879 High 2017-01-06 No exploit published No public exploit An issue was discovered in Pivotal Spring Security before 3.2.10, 4.1.x before 4.1.4, and 4.2.x before 4.2.1. Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification. Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. The unexpected presence of path parameters can cause a constraint to be bypassed. Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath(), and getPathInfo(). Users of other Servlet containers based on Apache Tomcat may or may not be affected depending on whether or not the handling of path parameters has been modified. Users of IBM WebSphere Application Server 8.5.x are known to be affected. Users of other containers that implement the Servlet specification may be affected.
CVE-2014-4241 Medium 2014-07-17 No exploit published No public exploit Unspecified vulnerability in the Oracle WebLogic Server component in Oracle Fusion Middleware 10.0.2.0 and 10.3.6.0 allows remote attackers to affect integrity via vectors related to WLS - Web Services.
CVE-2012-5055 Medium 2012-12-05 No exploit published No public exploit DaoAuthenticationProvider in VMware SpringSource Spring Security before 2.0.8, 3.0.x before 3.0.8, and 3.1.x before 3.1.3 does not check the password if the user is not found, which makes the response delay shorter and might allow remote attackers to enumerate valid usernames via a series of login requests.
CVE-2011-2732 Medium 2012-12-05 Mitigation candidate Working exploit published CRLF injection vulnerability in the logout functionality in VMware SpringSource Spring Security before 2.0.7 and 3.0.x before 3.0.6 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the spring-security-redirect parameter.
CVE-2011-2731 Medium 2012-12-05 No exploit published No public exploit Race condition in the RunAsManager mechanism in VMware SpringSource Spring Security before 2.0.7 and 3.0.x before 3.0.6 stores the Authentication object in the shared security context, which allows attackers to gain privileges via a crafted thread.
CVE-2011-0527 Medium 2011-08-15 No exploit published No public exploit VMware vFabric tc Server (aka SpringSource tc Server) 2.0.x before 2.0.6.RELEASE and 2.1.x before 2.1.2.RELEASE accepts obfuscated passwords during JMX authentication, which makes it easier for context-dependent attackers to obtain access by leveraging an ability to read stored passwords.
CVE-2010-3700 Medium 2010-10-29 No exploit published No public exploit VMware SpringSource Spring Security 2.x before 2.0.6 and 3.x before 3.0.4, and Acegi Security 1.0.0 through 1.0.7, as used in IBM WebSphere Application Server (WAS) 6.1 and 7.0, allows remote attackers to bypass security constraints via a path parameter.
CVE-2010-1454 Medium 2010-05-19 No exploit published No public exploit com.springsource.tcserver.serviceability.rmi.JmxSocketListener in VMware SpringSource tc Server Runtime 6.0.19 and 6.0.20 before 6.0.20.D, and 6.0.25.A before 6.0.25.A-SR01, does not properly enforce the requirement for an encrypted (aka s2enc) password, which allows remote attackers to obtain JMX interface access via a blank password.
‹ prev page 3 of 3 next ›