WaratekVRT Sign in

High Vmware CVEs

105 CVEs, 2 exploited, 16 protected by Waratek

Reset
More filters (1)
Columns
Vendor vmware✕
Overview 105 matches · 16 protected · 2 exploited · 1 CISA KEV · 4 public PoC · 1 EPSS ≥ 0.5
105matches 16protected15.2% 2exploited1.9% 1CISA KEV1.0% 4public PoC3.8% 1EPSS ≥ 0.51.0%
Protected by Waratek 16 15.2% Rule in development 0 0.0% Mitigation candidate 2 1.9% No exploit published 87 82.9%
Critical 0 0.0% High 105 100.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 16 15.2% partly blocked 0 0.0% not blocked 89 84.8% not established 0 0.0% unrecorded 0 0.0%
Exploited 2 1.9% Working exploit published 1 1.0% Proof of concept only 3 2.9% Forecast only 0 0.0% No public exploit 99 94.3%
split by peak 69 / year
No exploit published: 87Mitigation candidate: 2Protected by Waratek: 16 High: 105 not blocked: 89blocked by ARMR today: 16 No public exploit: 99Proof of concept only: 3Working exploit published: 1Exploited: 2
20161 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 20176 Protected by Waratek1 No exploit published5 High6 blocked by ARMR today1 not blocked5 No public exploit6 20187 Protected by Waratek2 No exploit published5 High7 blocked by ARMR today2 not blocked5 No public exploit7 20191 No exploit published1 High1 not blocked1 No public exploit1 20201 Protected by Waratek1 High1 blocked by ARMR today1 Exploited1 20216 Protected by Waratek2 Mitigation candidate1 No exploit published3 High6 blocked by ARMR today2 not blocked4 Exploited1 No public exploit5 20223 No exploit published3 High3 not blocked3 No public exploit3 20237 Protected by Waratek1 No exploit published6 High7 blocked by ARMR today1 not blocked6 Proof of concept only2 No public exploit5 20244 Protected by Waratek1 No exploit published3 High4 blocked by ARMR today1 not blocked3 No public exploit4 20250 202669 Protected by Waratek7 Mitigation candidate1 No exploit published61 High69 blocked by ARMR today7 not blocked62 Working exploit published1 Proof of concept only1 No public exploit67
20162017201820192020202120222023202420252026
105 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed. ‹ prev page 2 of 2 next ›
CVE Severity Published▾ Status Exploitation Description
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-2014-0225 High 2017-05-25 Protected by Waratek No public exploit When processing user provided XML documents, the Spring Framework 4.0.0 to 4.0.4, 3.0.0 to 3.2.8, and possibly earlier unsupported versions did not disable by default the resolution of URI references in a DTD declaration. This enabled an XXE attack.
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-2016-9878 High 2016-12-29 Protected by Waratek No public exploit An issue was discovered in Pivotal Spring Framework before 3.2.18, 4.2.x before 4.2.9, and 4.3.x before 4.3.5. Paths provided to the ResourceServlet were not properly sanitized and as a result exposed to directory traversal attacks.
‹ prev page 2 of 2 next ›