Overview 14 matches · 1 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
14matches
1in Waratek scope7.1%
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
1
7.1%
Outside Waratek scope
0
0.0%
Not applicable
13
92.9%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
14
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
2
14.3%
Forecast only
0
0.0%
No public exploit
12
85.7%
split by
peak 9 / year
20203
Not applicable3
Medium3
not blocked3
No public exploit3
20211
Not applicable1
Medium1
not blocked1
No public exploit1
20220
20230
20241
Not applicable1
Medium1
not blocked1
No public exploit1
20250
20269
No exploit published1
Not applicable8
Medium9
not blocked9
Proof of concept only2
No public exploit7
2020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-123611 | Medium | 2026-11-08 | Not applicable | No public exploit | rustls before 0.23.46 contains a key exchange downgrade vulnerability that allows network attackers to poison the per-server-name key-exchange group record via an unauthenticated ServerHello. Attackers can answer one connection with a ServerHello selecting X25519, causing later ClientHellos to send only classical shares and lose post-quantum confidentiality. |
| CVE-2026-20578 | Medium | 2026-11-02 | Not applicable | No public exploit | In Modem, there is a possible information disclosure due to side channel information disclosure. This could lead to remote denial of service, if a UE has connected to a rogue base station controlled by the attacker, with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01879164; Issue ID: MSV-9846. |
| CVE-2026-110310 | Medium | 2026-10-14 | Not applicable | No public exploit | A remote user who can read encrypted objects in the S3 bucket can force a padding downgrade by altering the padding scheme recorded in an object's metadata to legacy PKCS#1 v1.5. Since this padding scheme is susceptible to the well-known Bleichenbacher attack, the user can use a PKCS#1 v1.5 padding oracle to recover the RSA-wrapped envelope key and decrypt the object. To remediate this issue, we recommend that users upgrade to version 3.2.2 or 4.0.3. The 1.x and 2.x lines will not be patched, users of those lines need to migrate to 3.2.2 or 4.0.3. |
| CVE-2026-109952 | Medium | 2026-10-13 | Not applicable | Proof of concept only | The FreeRDP client 3.0.0 before 3.32.0 does not check a server-selected PROTOCOL_RDSTLS or PROTOCOL_HYBRID_EX against its enabled protocol set in nego_process_negotiation_response(), allowing a security protocol downgrade. A malicious server or man-in-the-middle can select RDSTLS to override /sec:nla pinning, complete authentication with an all-zero cookie, and receive the user's cleartext password in the Client Info PDU. |
| CVE-2026-59293 | Medium | 2026-08-27 | No exploit published | No public exploit | Unless the application explicitly raises smbMinVersion, the jCIFS client will negotiate down to SMB1/CIFS, which lacks mandatory signing/encryption and is vulnerable to NTLM relay and content-tampering MITM. Spring Integration 7.1.0 Spring Integration 7.0.0 - 7.0.5 Spring Integration 6.5.0 - 6.5.10 Spring Integration 6.4.0 - 6.4.12 |
| CVE-2026-48747 | Medium | 2026-07-14 | Not applicable | No public exploit | Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Prior to 7.4.13 and 8.0.13, MailomatRequestParser::validateSignature() parsed X-MOM-Webhook-Signature as algo=signature and passed the request-selected algorithm to hash_hmac(), allowing a signature algorithm downgrade instead of enforcing Mailomat's documented SHA-256 webhook signature. This issue is fixed in versions 7.4.13 and 8.0.13. |
| CVE-2026-1677 | Medium | 2026-05-11 | Not applicable | Proof of concept only | Zephyr sockets created with `IPPROTO_TLS_1_3` can still negotiate a TLS 1.2 connection when both TLS versions are enabled in Kconfig, because the socket-level protocol selection is not propagated to mbedTLS (e.g. via `mbedtls_ssl_conf_min_tls_version`). The ClientHello advertises both versions and the peer can establish TLS 1.2, so applications that assumed `IPPROTO_TLS_1_3` enforces TLS 1.3 may silently use TLS 1.2 and remain exposed to TLS 1.2-specific weaknesses. As a workaround, the `TLS_CIPHERSUITE_LIST` socket option can be restricted to TLS 1.3-only cipher suites. |
| CVE-2026-6550 | Medium | 2026-04-20 | Not applicable | No public exploit | Cryptographic algorithm downgrade in the caching layer of Amazon AWS Encryption SDK for Python before version 3.3.1 and before version 4.0.5 might allow an authenticated local threat actor to bypass key commitment policy enforcement via a shared key cache, resulting in ciphertext that can be decrypted to multiple different plaintexts. To remediate this issue, users should upgrade to version 3.3.1, 4.0.5 or above. |
| CVE-2026-2673 | Medium | 2026-03-13 | Not applicable | No public exploit | Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected preferred key exchange group when its key exchange group configuration includes the default by using the 'DEFAULT' keyword. Impact summary: A less preferred key exchange may be used even when a more preferred group is supported by both client and server, if the group was not included among the client's initial predicated keyshares. This will sometimes be the case with the new hybrid post-quantum groups, if the client chooses to defer their use until specifically requested by the server. If an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to interpolate the built-in default group list into its own configuration, perhaps adding or removing specific elements, then an implementation defect causes the 'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups were treated as a single sufficiently secure 'tuple', with the server not sending a Hello Retry Request (HRR) even when a group in a more preferred tuple was mutually supported. As a result, the client and server might fail to negotiate a mutually supported post-quantum key agreement group, such as 'X25519MLKEM768', if the client's configuration results in only 'classical' groups (such as 'X25519' being the only ones in the client's initial keyshare prediction). OpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS 1.3 key agreement group on TLS servers. The old syntax had a single 'flat' list of groups, and treated all the supported groups as sufficiently secure. If any of the keyshares predicted by the client were supported by the server the most preferred among these was selected, even if other groups supported by the client, but not included in the list of predicted keyshares would have been more preferred, if included. The new syntax partitions the groups into distinct 'tuples' of roughly equivalent security. Within each tuple the most preferred group included among the client's predicted keyshares is chosen, but if the client supports a group from a more preferred tuple, but did not predict any corresponding keyshares, the server will ask the client to retry the ClientHello (by issuing a Hello Retry Request or HRR) with the most preferred mutually supported group. The above works as expected when the server's configuration uses the built-in default group list, or explicitly defines its own list by directly defining the various desired groups and group 'tuples'. No OpenSSL FIPS modules are affected by this issue, the code in question lies outside the FIPS boundary. OpenSSL 3.6 and 3.5 are vulnerable to this issue. OpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released. OpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released. OpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue. |
| CVE-2024-20069 | Medium | 2024-06-03 | Not applicable | No public exploit | In modem, there is a possible selection of less-secure algorithm during the VoWiFi IKE due to a missing DH downgrade check. This could lead to remote information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. Patch ID: MOLY01286330; Issue ID: MSV-1430. |
| CVE-2021-36326 | Medium | 2021-11-30 | Not applicable | No public exploit | Dell EMC Streaming Data Platform, versions prior to 1.3 contain an SSL Strip Vulnerability in the User Interface (UI). A remote unauthenticated attacker could potentially exploit this vulnerability, leading to a downgrade in the communications between the client and server into an unencrypted format. |
| CVE-2020-16200 | Medium | 2020-09-18 | Not applicable | No public exploit | Philips Clinical Collaboration Platform, Versions 12.2.1 and prior, does not properly control the allocation and maintenance of a limited resource, thereby enabling an attacker to influence the amount of resources consumed, eventually leading to the exhaustion of available resources. |
| CVE-2020-10135 | Medium | 2020-05-19 | Not applicable | No public exploit | Legacy pairing and secure-connections pairing authentication in Bluetooth BR/EDR Core Specification v5.2 and earlier may allow an unauthenticated user to complete authentication without pairing credentials via adjacent access. An unauthenticated, adjacent attacker could impersonate a Bluetooth BR/EDR master or slave to pair with a previously paired remote device to successfully complete the authentication procedure without knowing the link key. |
| CVE-2019-16791 | Medium | 2020-01-22 | Not applicable | No public exploit | In postfix-mta-sts-resolver before 0.5.1, All users can receive incorrect response from daemon under rare conditions, rendering downgrade of effective STS policy. |