WaratekVRT Sign in
Reset
More filters (3)
Columns
Protection: Full✕Published from 2017-07-01✕Vendor org.apache.xmlgraphics✕
Overview 3 matches · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
3matches 0exploited0.0% 0CISA KEV0.0% 0public PoC0.0% 0EPSS ≥ 0.50.0%
Protected by Waratek 3 100.0% Rule in development 0 0.0% Mitigation candidate 0 0.0% No exploit published 0 0.0%
Critical 1 33.3% High 2 66.7% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 3 100.0% partly blocked 0 0.0% not blocked 0 0.0% not established 0 0.0% unrecorded 0 0.0%
Exploited 0 0.0% Working exploit published 0 0.0% Proof of concept only 0 0.0% Forecast only 0 0.0% No public exploit 3 100.0%
split by peak 1 / year
Protected by Waratek: 3 High: 2Critical: 1 blocked by ARMR today: 3 No public exploit: 3
20181 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1 20190 20201 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1 20210 20220 20230 20241 Protected by Waratek1 High1 blocked by ARMR today1 No public exploit1
2018201920202021202220232024
3 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-2024-28168 High 2024-10-09 Protected by Waratek No public exploit Improper Restriction of XML External Entity Reference ('XXE') vulnerability in Apache XML Graphics FOP. This issue affects Apache XML Graphics FOP: 2.9. Users are recommended to upgrade to version 2.10, which fixes the issue.
CVE-2019-17566 High 2020-11-12 Protected by Waratek No public exploit Apache Batik is vulnerable to server-side request forgery, caused by improper input validation by the "xlink:href" attributes. By using a specially-crafted argument, an attacker could exploit this vulnerability to cause the underlying server to make arbitrary GET requests.
CVE-2018-8013 Critical 2018-05-24 Protected by Waratek No public exploit In Apache Batik 1.x before 1.10, when deserializing subclass of `AbstractDocument`, the class takes a string from the inputStream as the class name which then use it to call the no-arg constructor of the class. Fix was to check the class type before calling newInstance in deserialization.