Overview 7 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
7matches
0in Waratek scope0.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
2
28.6%
Not applicable
5
71.4%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
7
100.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
7
100.0%
split by
peak 3 / year
20143
Not applicable3
Medium3
not blocked3
No public exploit3
20150
20160
20170
20181
Not applicable1
Critical1
not blocked1
No public exploit1
20190
20202
Outside Waratek scope1
Not applicable1
Critical2
not blocked2
No public exploit2
20211
Outside Waratek scope1
Critical1
not blocked1
No public exploit1
20142015201620172018201920202021
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2020-14343 | Critical | 2021-02-09 | Outside Waratek scope | No public exploit | A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747. |
| CVE-2020-1747 | Critical | 2020-03-24 | Outside Waratek scope | No public exploit | A vulnerability was discovered in the PyYAML library in versions before 5.3.1, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. An attacker could use this flaw to execute arbitrary code on the system by abusing the python/object/new constructor. |
| CVE-2019-20477 | Critical | 2020-02-19 | Not applicable | No public exploit | PyYAML 5.1 through 5.1.2 has insufficient restrictions on the load and load_all functions because of a class deserialization issue, e.g., Popen is a class in the subprocess module. NOTE: this issue exists because of an incomplete fix for CVE-2017-18342. |
| CVE-2017-18342 | Critical | 2018-06-27 | Not applicable | No public exploit | In PyYAML before 5.1, the yaml.load() API could execute arbitrary code if used with untrusted data. The load() function has been deprecated in version 5.1 and the 'UnsafeLoader' has been introduced for backward compatibility with the function. |
| CVE-2014-9130 | Medium | 2014-12-08 | Not applicable | No public exploit | scanner.c in LibYAML 0.1.5 and 0.1.6, as used in the YAML-LibYAML (aka YAML-XS) module for Perl, allows context-dependent attackers to cause a denial of service (assertion failure and crash) via vectors involving line-wrapping. |
| CVE-2014-2525 | Medium | 2014-03-28 | Not applicable | No public exploit | Heap-based buffer overflow in the yaml_parser_scan_uri_escapes function in LibYAML before 0.1.6 allows context-dependent attackers to execute arbitrary code via a long sequence of percent-encoded characters in a URI in a YAML file. |
| CVE-2013-6393 | Medium | 2014-02-06 | Not applicable | No public exploit | The yaml_parser_scan_tag_uri function in scanner.c in LibYAML before 0.1.5 performs an incorrect cast, which allows remote attackers to cause a denial of service (application crash) and possibly execute arbitrary code via crafted tags in a YAML document, which triggers a heap-based buffer overflow. |