Export limit exceeded: 395318 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (9 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-89147 | 1 Net-snmp | 1 Net-snmp | 2026-09-15 | 7.5 High |
| Net-SNMP through 5.9.5.2 contains a denial of service vulnerability in the SMUX module where smux_accept() performs an unauthenticated blocking read without timeout on newly accepted connections. An unauthenticated remote client can connect to the SMUX listener and send no data, causing the single-threaded snmpd main loop to block indefinitely and suspend all SNMP processing. | ||||
| CVE-2026-81520 | 1 Mongodb | 1 Bi Connector | 2026-08-31 | 7.5 High |
| A network-reachable client that has not yet authenticated can hold a MongoDB Connector for BI authentication session open indefinitely by beginning a SASL-based login exchange and then declining to complete it. Because the negotiation loop had no overall time bound and the read from the client had no deadline, each such session retains a worker, a client connection slot, and its associated backend database connections until the process is restarted. Repeated use of this behavior can consume the configured connection capacity and prevent legitimate users from establishing new sessions. | ||||
| CVE-2026-46104 | 1 Linux | 1 Linux Kernel | 2026-05-29 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: selinux: use sk blob accessor in socket permission helpers SELinux socket state lives in the composite LSM socket blob. sock_has_perm() and nlmsg_sock_has_extended_perms() currently dereference sk->sk_security directly, which assumes the SELinux socket blob is at offset zero. In stacked configurations that assumption does not hold. If another LSM allocates socket blob storage before SELinux, these helpers may read the wrong blob and feed invalid SID and class values into AVC checks. Use selinux_sock() instead of accessing sk->sk_security directly. | ||||
| CVE-2024-8061 | 2 Aimhubio, Aimstack | 2 Aim, Aim | 2025-10-15 | N/A |
| In version 3.23.0 of aimhubio/aim, certain methods that request data from external servers do not have set timeouts, causing the server to wait indefinitely for a response. This can lead to a denial of service, as the tracking server does not respond to other requests while waiting. The issue arises in the client used by the `aim` tracking server to communicate with external resources, specifically in the `_run_read_instructions` method and similar calls without timeouts. | ||||
| CVE-2025-4656 | 1 Hashicorp | 1 Vault | 2025-08-13 | 3.1 Low |
| Vault Community and Vault Enterprise rekey and recovery key operations can lead to a denial of service due to uncontrolled cancellation by a Vault operator. This vulnerability (CVE-2025-4656) has been remediated in Vault Community Edition 1.20.0 and Vault Enterprise 1.20.0, 1.19.6, 1.18.11, 1.17.17, and 1.16.22. | ||||
| CVE-2024-12777 | 2 Aimhubio, Aimstack | 2 Aim, Aim | 2025-07-18 | N/A |
| A vulnerability in aimhubio/aim version 3.25.0 allows for a denial of service through the misuse of the sshfs-client. The tracking server, which is single-threaded, can be made unresponsive by requesting it to connect to an unresponsive socket via sshfs. The lack of an additional timeout setting in the sshfs-client causes the server to hang for a significant amount of time, preventing it from responding to other requests. | ||||
| CVE-2024-8062 | 1 H2o | 1 H2o | 2025-03-26 | 7.5 High |
| A vulnerability in the typeahead endpoint of h2oai/h2o-3 version 3.46.0 allows for a denial of service. The endpoint performs a `HEAD` request to verify the existence of a specified resource without setting a timeout. An attacker can exploit this by sending multiple requests to an attacker-controlled server that hangs, causing the application to block and become unresponsive to other requests. | ||||
| CVE-2022-2493 | 1 Open-emr | 1 Openemr | 2024-11-21 | 8.1 High |
| Data Access from Outside Expected Data Manager Component in GitHub repository openemr/openemr prior to 7.0.0. | ||||
| CVE-2020-14483 | 1 Tridium | 2 Niagara, Niagara Enterprise Security | 2024-11-21 | 4.3 Medium |
| A timeout during a TLS handshake can result in the connection failing to terminate. This can result in a Niagara thread hanging and requires a manual restart of Niagara (Versions 4.6.96.28, 4.7.109.20, 4.7.110.32, 4.8.0.110) and Niagara Enterprise Security (Versions 2.4.31, 2.4.45, 4.8.0.35) to correct. | ||||
Page 1 of 1.