WaratekVRT Sign in
Reset
More filters (1)
Columns
Product spring-core✕
Overview 4 matches · 0 exploited · 0 CISA KEV · 2 public PoC · 0 EPSS ≥ 0.5
4matches 0exploited0.0% 0CISA KEV0.0% 2public PoC50.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 4 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 0 0.0% High 0 0.0% Medium 4 100.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 4 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%
split by peak 2 / year
20112012201320142015201620172018
4 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2018-1271 Medium 2018-04-06 Protected by Waratek Working exploit published Spring Framework, versions 5.0 prior to 5.0.5 and versions 4.3 prior to 4.3.15 and older unsupported versions, allow applications to configure Spring MVC to serve static resources (e.g. CSS, JS, images). When static resources are served from a file system on Windows (as opposed to the classpath, or the ServletContext), a malicious user can send a request using a specially crafted URL that can lead a directory traversal attack.
CVE-2015-0201 Medium 2015-03-10 Protected by Waratek No public exploit The Java SockJS client in Pivotal Spring Framework 4.1.x before 4.1.5 generates predictable session ids, which allows remote attackers to send messages to other sessions via unspecified vectors.
CVE-2014-3578 Medium 2015-02-19 Protected by Waratek No public exploit Directory traversal vulnerability in Pivotal Spring Framework 3.x before 3.2.9 and 4.0 before 4.0.5 allows remote attackers to read arbitrary files via a crafted URL.
CVE-2011-2894 Medium 2011-10-04 Protected by Waratek Proof of concept only Spring Framework 3.0.0 through 3.0.5, Spring Security 3.0.0 through 3.0.5 and 2.0.0 through 2.0.6, and possibly other versions deserialize objects from untrusted sources, which allows remote attackers to bypass intended security restrictions and execute untrusted code by (1) serializing a java.lang.Proxy instance and using InvocationHandler, or (2) accessing internal AOP interfaces, as demonstrated using deserialization of a DefaultListableBeanFactory instance to execute arbitrary commands via the java.lang.Runtime class.