Overview 2 matches · 1 in Waratek scope · 0 protected · 1 exploited · 1 CISA KEV · 1 EPSS ≥ 0.5
Protected by Waratek
1
50.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
1
50.0%
Not applicable
0
0.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
1
50.0%
not blocked
1
50.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
50.0%
Working exploit published
0
0.0%
Proof of concept only
1
50.0%
Forecast only
0
0.0%
No public exploit
0
0.0%
split by
peak 1 / month
Oct 17Nov 17Dec 17Jan 18Feb 18
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2018-1305 | Medium | 2018-02-23 | Outside Waratek scope | Proof of concept only | Security constraints defined by annotations of Servlets in Apache Tomcat 9.0.0.M1 to 9.0.4, 8.5.0 to 8.5.27, 8.0.0.RC1 to 8.0.49 and 7.0.0 to 7.0.84 were only applied once a Servlet had been loaded. Because security constraints defined in this way apply to the URL pattern and any URLs below that point, it was possible - depending on the order Servlets were loaded - for some security constraints not to be applied. This could have exposed resources to users who were not authorised to access them. |
| CVE-2017-12617 | High | 2017-10-04 | Protected by Waratek | Exploited | When running Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81 with HTTP PUTs enabled (e.g. via setting the readonly initialisation parameter of the Default servlet to false) it was possible to upload a JSP file to the server via a specially crafted request. This JSP could then be requested and any code it contained would be executed by the server. |