Overview 8 matches · 1 in Waratek scope · 1 protected · 0 exploited · 0 CISA KEV · 2 public PoC · 4 EPSS ≥ 0.5
8matches
1in Waratek scope12.5%
1protected12.5%
0exploited0.0%
0CISA KEV0.0%
2public PoC25.0%
4EPSS ≥ 0.550.0%
Protected by Waratek
1
12.5%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
6
75.0%
Not applicable
1
12.5%
Withdrawn CVE
0
0.0%
blocked by ARMR today
1
12.5%
partly blocked
0
0.0%
not blocked
7
87.5%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 2 / quarter
Q1 191
Outside Waratek scope1
Critical1
not blocked1
No public exploit1
Q2 190
Q3 192
Outside Waratek scope2
Critical2
not blocked2
No public exploit2
Q4 190
Q1 200
Q2 200
Q3 200
Q4 200
Q1 212
Protected by Waratek1
Outside Waratek scope1
Critical2
blocked by ARMR today1
not blocked1
Working exploit published1
Forecast only1
Q2 210
Q3 212
Outside Waratek scope1
Not applicable1
Critical2
not blocked2
Forecast only1
No public exploit1
Q4 210
Q1 220
Q2 221
Outside Waratek scope1
Critical1
not blocked1
Proof of concept only1
Q2 19Q4 19Q2 20Q4 20Q2 21Q4 21Q2 22
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2022-1292 | Critical | 2022-05-03 | Outside Waratek scope | Proof of concept only | The c_rehash script does not properly sanitise shell metacharacters to prevent command injection. This script is distributed by some operating systems in a manner where it is automatically executed. On such operating systems, an attacker could execute arbitrary commands with the privileges of the script. Use of the c_rehash script is considered obsolete and should be replaced by the OpenSSL rehash command line tool. Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2). Fixed in OpenSSL 1.1.1o (Affected 1.1.1-1.1.1n). Fixed in OpenSSL 1.0.2ze (Affected 1.0.2-1.0.2zd). |
| CVE-2021-22945 | Critical | 2021-09-23 | Not applicable | No public exploit | When sending data to an MQTT server, libcurl <= 7.73.0 and 7.78.0 could in some circumstances erroneously keep a pointer to an already freed memory area and both use that again in a subsequent call to send data and also free it *again*. |
| CVE-2021-3711 | Critical | 2021-08-24 | Outside Waratek scope | Forecast only | In order to decrypt SM2 encrypted data an application is expected to call the API function EVP_PKEY_decrypt(). Typically an application will call this function twice. The first time, on entry, the "out" parameter can be NULL and, on exit, the "outlen" parameter is populated with the buffer size required to hold the decrypted plaintext. The application can then allocate a sufficiently sized buffer and call EVP_PKEY_decrypt() again, but this time passing a non-NULL value for the "out" parameter. A bug in the implementation of the SM2 decryption code means that the calculation of the buffer size required to hold the plaintext returned by the first call to EVP_PKEY_decrypt() can be smaller than the actual size required by the second call. This can lead to a buffer overflow when EVP_PKEY_decrypt() is called by the application a second time with a buffer that is too small. A malicious attacker who is able present SM2 content for decryption to an application could cause attacker chosen data to overflow the buffer by up to a maximum of 62 bytes altering the contents of other data held after the buffer, possibly changing application behaviour or causing the application to crash. The location of the buffer is application dependent but is typically heap allocated. Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). |
| CVE-2021-21351 | Critical | 2021-03-23 | Outside Waratek scope | Working exploit published | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2021-21344 | Critical | 2021-03-23 | Protected by Waratek | Forecast only | XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16. |
| CVE-2019-5482 | Critical | 2019-09-16 | Outside Waratek scope | No public exploit | Heap buffer overflow in the TFTP protocol handler in cURL 7.19.4 to 7.65.3. |
| CVE-2019-5481 | Critical | 2019-09-16 | Outside Waratek scope | No public exploit | Double-free vulnerability in the FTP-kerberos code in cURL 7.52.0 to 7.65.3. |
| CVE-2019-3822 | Critical | 2019-02-06 | Outside Waratek scope | No public exploit | libcurl versions from 7.36.0 to before 7.64.0 are vulnerable to a stack-based buffer overflow. The function creating an outgoing NTLM type-3 header (`lib/vauth/ntlm.c:Curl_auth_create_ntlm_type3_message()`), generates the request HTTP header contents based on previously received data. The check that exists to prevent the local buffer from getting overflowed is implemented wrongly (using unsigned math) and as such it does not prevent the overflow from happening. This output data can grow larger than the local buffer if very large 'nt response' data is extracted from a previous NTLMv2 header provided by the malicious or broken HTTP server. Such a 'large value' needs to be around 1000 bytes or more. The actual payload data copied to the target buffer comes from the NTLMv2 type-2 response header. |