Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-109855 | 7.5 high | 0.00% | nodejs, undici | undici is an HTTP client library for Node.js. In versions 8.11.0 and 8.11.1, its experimental WebSocket client, which is enabled by default when HTTP/2 is allowed, mishandles a failed WebSocket handshake over HTTP/2: the request is already marked completed, so the abort becomes a no-op and the underlying HTTP/2 stream is left open with no error listener. When a malicious server then destroys the connection, the orphaned stream emits an unhandled error and the Node.js process exits. A remote, unauthenticated server can therefore crash any client that opens a WebSocket to it over HTTP/2, resulting in a denial of service. The issue is fixed in undici 8.11.2, and users should upgrade to 8.11.2 or later. As a workaround, set allowH2 to false to disable HTTP/2 for WebSocket connections, or avoid opening WebSocket connections to untrusted servers. | 19 Oct |
| CVE-2026-87018 | 7.5 high | 0.00% | nodejs, undici | undici is an HTTP client library for Node.js. In versions 4.2.1 through 6.29.0, 7.0.0 through 7.30.0, and 8.0.0 through 8.12.1, the client process crashes when a TLS 1.2 server renegotiates after the connection is established and presents a different, CA-trusted certificate whose hostname does not match the requested host. Node.js re-runs hostname verification on the renegotiated handshake and destroys the socket with a certificate-altname error, but undici's established-socket error handler asserted that this error code could never occur, so the peer-controlled error became an uncaught assertion that terminates the Node.js process, affecting both the HTTP/1.1 and HTTP/2 paths. A malicious or compromised HTTPS endpoint reached through undici or the global fetch() can crash the client with a single server-initiated renegotiation, taking down all in-flight requests and background work in the process, and exploitation needs no CA compromise because the attacker controls the endpoint and can present two ordinary valid certificates. Only TLS 1.2 is affected, since TLS 1.3 does not support renegotiation. The issue is fixed in undici 6.29.1, 7.30.1, and 8.12.2, and users should upgrade to one of those versions or later. As a workaround, restrict outbound connections to TLS 1.3 so renegotiation cannot occur, when the target endpoints support it. | 19 Oct |
| CVE-2026-52945 | 7.5 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: Revert "wireguard: device: enable threaded NAPI" This reverts commit 933466fc50a8e4eb167acbd0d8ec96a078462e9c which is commit db9ae3b6b43c79b1ba87eea849fd65efa05b4b2e upstream. We have had three independent production user reports in combination with Cilium utilizing WireGuard as encryption underneath that k8s Pod E/W traffic to certain peer nodes fully stalled. The situation appears as follows: - Occurs very rarely but at random times under heavy networking load. - Once the issue triggers the decryption side stops working completely for that WireGuard peer, other peers keep working fine. The stall happens also for newly initiated connections towards that particular WireGuard peer. - Only the decryption side is affected, never the encryption side. - Once it triggers, it never recovers and remains in this state, the CPU/mem on that node looks normal, no leak, busy loop or crash. - bpftrace on the affected system shows that wg_prev_queue_enqueue fails, thus the MAX_QUEUED_PACKETS (1024 skbs!) for the peer's rx_queue is reached. - Also, bpftrace shows that wg_packet_rx_poll for that peer is never called again after reaching this state for that peer. For other peers wg_packet_rx_poll does get called normally. - Commit db9ae3b ("wireguard: device: enable threaded NAPI") switched WireGuard to threaded NAPI by default. The default has not been changed for triggering the issue, neither did CPU hotplugging occur (i.e. 5bd8de2 ("wireguard: queueing: always return valid online CPU in wg_cpumask_choose_online()")). - The issue has been observed with stable kernels of v5.15 as well as v6.1. It was reported to us that v5.10 stable is working fine, and no report on v6.6 stable either (somewhat related discussion in [0] though). - In the WireGuard driver the only material difference between v5.10 stable and v5.15 stable is the switch to threaded NAPI by default. [0] https://lore.kernel.org/netdev/CA+wXwBTT74RErDGAnj98PqS=wvdh8eM1pi4q6tTdExtjnokKqA@mail.gmail.com/ Breakdown of the problem: 1) skbs arriving for decryption are enqueued to the peer->rx_queue in wg_packet_consume_data via wg_queue_enqueue_per_device_and_peer. 2) The latter only moves the skb into the MPSC peer queue if it does not surpass MAX_QUEUED_PACKETS (1024) which is kept track in an atomic counter via wg_prev_queue_enqueue. 3) In case enqueueing was successful, the skb is also queued up in the device queue, round-robin picks a next online CPU, and schedules the decryption worker. 4) The wg_packet_decrypt_worker, once scheduled, picks these up from the queue, decrypts the packets and once done calls into wg_queue_enqueue_per_peer_rx. 5) The latter updates the state to PACKET_STATE_CRYPTED on success and calls napi_schedule on the per peer->napi instance. 6) NAPI then polls via wg_packet_rx_poll. wg_prev_queue_peek checks on the peer->rx_queue. It will wg_prev_queue_dequeue if the queue->peeked skb was not cached yet, or just return the latter otherwise. (wg_prev_queue_drop_peeked later clears the cache.) 7) From an ordering perspective, the peer->rx_queue has skbs in order while the device queue with the per-CPU worker threads from a global ordering PoV can finish the decryption and signal the skb PACKET_STATE_CRYPTED out of order. 8) A situation can be observed that the first packet coming in will be stuck waiting for the decryption worker to be scheduled for a longer time when the system is under pressure. 9) While this is the case, the other CPUs in the meantime finish decryption and call into napi_schedule. 10) Now in wg_packet_rx_poll it picks up the first in-order skb from the peer->rx_queue and sees that its state is still PACKET_STATE_UNCRYPTED. The NAPI poll routine then exits e ---truncated--- | 19 Oct |
| CVE-2025-55070 | 7.5 high | 0.00% | mattermost, mattermost_server | Mattermost versions <11 fail to enforce multi-factor authentication on WebSocket connections which allows unauthenticated users to access sensitive information via WebSocket events | 19 Oct |
| CVE-2026-98290 | 7.5 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid socket lock inversion in listener cleanup rfcomm_sock_cleanup_listen() closes unaccepted child sockets through rfcomm_sock_close(), which takes the child socket lock before rfcomm_dlc_close() acquires rfcomm_mutex. The RFCOMM worker takes these locks in reverse order while handling connections and DLC state changes, so lockdep reports a possible deadlock. Close dequeued children without taking their socket lock. The accept queue owns a reference to each child, and bt_accept_dequeue() locks the child while unlinking it and clearing its parent pointer. Dropping the child lock makes it important to prevent a concurrent rfcomm_connect_ind() from enqueueing a new child after cleanup observes an empty queue. Set a listening socket to BT_CLOSED while its lock is still held, before dropping the lock and draining the queue. The state check in rfcomm_connect_ind() then rejects new children once cleanup starts. | 19 Oct |
| CVE-2025-25253 | 7.5 high | 0.00% | fortinet, fortiproxy, fortios | An Improper Validation of Certificate with Host Mismatch vulnerability [CWE-297] in FortiProxy version 7.6.1 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions and FortiOS version 7.6.2 and below, version 7.4.8 and below, 7.2 all versions, 7.0 all versions ZTNA proxy may allow an unauthenticated attacker in a man-in-the middle position to intercept and tamper with connections to the ZTNA proxy | 18 Oct |
| CVE-2025-59460 | 7.5 high | 0.00% | sick, tloc100-100_firmware | The system is deployed in its default state, with configuration settings that do not comply with the latest best practices for restricting access. This increases the risk of unauthorised connections. | 18 Oct |
| CVE-2026-74692 | 7.5 high | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: net/smc: fix TOCTOU race between smc_listen_out() and listener close smc_listen_out() reads lsmc->sk.sk_state without the listener lock, then acquires lock_sock_nested() only after the check passes. This opens a window where smc_close_active() can transition the listener to SMC_CLOSED, call smc_close_cleanup_listen() to drain the accept queue, and release the lock, all between the lockless read and the delayed lock acquisition: smc_listen_work (smc_hs_wq) smc_close_active() ------------------------------- ------------------------- release_sock(child) if (sk_state == SMC_LISTEN) TRUE lock_sock(listener) sk_state = SMC_CLOSED smc_close_cleanup_listen() release_sock(listener) flush_work(tcp_listen_work) lock_sock_nested(listener) smc_accept_enqueue(listener, child) /* child enqueued on dead listener */ smc_close_active() flushes only tcp_listen_work. Work items already dispatched onto smc_hs_wq for the CLC handshake continue running unguarded. smc_accept_enqueue() takes a sock_hold() on the child that is never released, so the child smc_sock, its clcsock, and the reference all leak. A remote peer that opens TCP connections while the server calls close() can exhaust kernel memory. Move lock_sock_nested() to before the sk_state check so that the test and the enqueue are atomic under the listener lock. | 16 Oct |
| CVE-2026-85975 | 7.5 high | 0.00% | no CPE yet | Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 may use cleartext transport for Amazon S3 connections by default. A network-positioned attacker could intercept data or credentials transmitted through an affected connection. | 15 Oct |
| CVE-2026-107577 | 7.5 high | 0.00% | no CPE yet | Inefficient algorithmic complexity and a non-terminating loop in the MIME processing of received messages in Progressive Robot hMailServer 6.0.0 through 6.3.5 allow a remote unauthenticated attacker to make the mail services unavailable by sending a message. Removing a MIME header parameter whose value is empty and directly followed by a semicolon (for example a Content-Disposition with 'filename=a.bat; filename=;') entered a loop that never terminates, holding a worker thread at full load until the server is restarted; this is reached when the attachment blocker renames a blocked attachment or a filename is set over the REST API. Separately, decoding a header field that holds many RFC 2047 encoded words of an encoding other than base64 or quoted-printable, removing a parameter with many RFC 2231 continuations, and deleting many header fields of one name each took time growing with the square of the message, on the small thread pools that serve IMAP, SMTP and POP3 connections, delivery and the REST API. | 8 Oct |
| CVE-2026-84783 | 7.5 high | 0.00% | openssl | Issue summary: The first concurrent use of the same X.509 certificate by several threads may cause its cached extension data to be freed while another thread is still using it. Impact summary: A remote, unauthenticated peer could crash a multi-threaded TLS client, or a multi-threaded TLS server that requests client certificates, if the first certificate chains built to the same trusted CA certificate are built by several connections at the same time. This is a use-after-free read, which is likely to crash the process, resulting in a Denial of Service. CWE: CWE-416: Use After Free Description: OpenSSL caches the decoded values of a certificate's X.509v3 extensions inside the X509 object the first time they are needed. In OpenSSL 4.0 this cache is built in two phases: the extension values are computed while holding a read lock on the certificate, and the results are then installed into the certificate under a write lock. Because a read lock does not exclude other readers, several threads can compute the cache for the same certificate at the same time. Each thread that subsequently acquires the write lock installs its own results and frees the values installed by the thread before it, even though that earlier thread has already marked the cache as complete and may have returned pointers into it to its caller. A caller still using those pointers then reads freed memory. Any certificate shared between threads is exposed the first time its extensions are decoded. In TLS the certificates at risk are the trusted CA certificates supplied for chain verification, by whatever means, since these are shared by every connection and their extensions are decoded and cached the first time a chain is built to them. Certificates sent by the peer are decoded separately for each connection and are not shared, so they are not affected. In a TLS client verifying server certificates, or a TLS server that requests and verifies client certificates, the use-after-free could only occur if the first chains built to the same trusted CA are built by several connections at the same time. FIPS impact: no The FIPS module is not affected as X.509 certificate handling is outside of the OpenSSL FIPS module boundary. OpenSSL 4.0 is vulnerable to this issue. OpenSSL 3.6, 3.5, 3.4, 3.0, 1.1.1 and 1.0.2 are not affected by this issue. OpenSSL 4.0 users should upgrade to OpenSSL 4.0.3. This issue was reported on 27 August 2026 by Tim Becker (Xint.io) and independently in a public report on 31 August 2026 by aydinmercan. The fix has been developed by Bob Beck. -- cut (non-publishing metadata for internal use) -- Reported by: Tim Becker (Xint.io), aydinmercan Fixed by: Bob Beck | 8 Oct |
| CVE-2026-39418 | 7.4 high | 0.00% | maxkb | MaxKB is an open-source AI assistant for enterprise. In versions 2.7.1 and below, sandbox network protection can be bypassed by using socket.sendto() with the MSG_FASTOPEN flag. This allows authenticated user with tool-editing permissions to reach internal services that are explicitly blocked by the sandbox's banned hosts configuration. MaxKB's sandbox uses LD_PRELOAD to hook the connect() function and block connections to banned IPs, but Linux's sendto() with the MSG_FASTOPEN flag can establish TCP connections directly through the kernel without ever calling connect(), completely bypassing the IP validation. Although sendto is listed in the syscall() wrapper, this is ineffective because glibc invokes the kernel syscall directly rather than routing through the hooked syscall() function. This issue has been fixed in version 2.8.0. | Mon 26 Oct |
| CVE-2026-47269 | 7.4 high | 0.00% | no CPE yet | pam_usb provides hardware authentication for Linux using ordinary removable media. Prior to 0.9.0, pam_usb's deny_remote feature checks utmpx ut_addr_v6 to detect whether an authentication request originates from a remote session. The outer guard was if (utent->ut_addr_v6[0] != 0), which only tests the first 32-bit word of the 128-bit address field. IPv4-mapped IPv6 addresses (::ffff:x.x.x.x) store the IPv4 address in ut_addr_v6[3] with ut_addr_v6[0] == 0. On systems where the SSH daemon listens on :: (IPv6 wildcard) with AddressFamily any -- common on Ubuntu and Debian -- incoming IPv4 connections are recorded in utmpx as IPv4-mapped IPv6 addresses. The outer check evaluates to false, the remote-detection block is skipped entirely, and the session is treated as local. deny_remote=true does not block the authentication. An attacker with physical access to a registered USB device can authenticate over SSH on an affected system as if they were sitting at a local terminal, bypassing the deny_remote restriction. This vulnerability is fixed in 0.9.0. | Mon 26 Oct |
| CVE-2026-7830 | 7.4 high | 0.00% | uvnc, ultravnc | UltraVNC through 1.8.2.2 uses inadequate cryptography in the MS-Logon II authentication scheme (rfbUltraVNC_MsLogonIIAuth). In rfb/dh.cpp the Diffie-Hellman key exchange is performed with parameters that fit in an unsigned 64-bit integer (DH_MAX_BITS controls the prime size). A 64-bit DH key can be broken by Pollard's rho algorithm in under one second on current hardware. Additionally, the private exponent is generated by the rng() function, which multiplies three libc rand() values seeded from time(NULL). With approximately 31 bits of internal state and a time-based seed, the private exponent is recoverable in under a minute by a passive observer. A network attacker who can observe the MS-Logon II handshake (via sniffing, recording, or man-in-the-middle) can derive the shared DH key and decrypt the encapsulated username and password, resulting in full credential disclosure. This affects legacy MS-Logon II connections; MS-Logon III (X25519 + AES-256-GCM) is unaffected. | Sun 25 Oct |
| CVE-2026-73495 | 7.4 high | 0.00% | no CPE yet | blaze is a Scala library for building asynchronous pipelines, with a focus on network IO. Prior to 0.23.18 and 1.0.0-M42, blaze-server can merge HTTP/1.1 chunked-body trailer fields into Request.headers. Because trailer fields are attacker-controlled, an unauthenticated remote client can inject arbitrary header names and values, including X-Forwarded-For and internal authorization headers, that a fronting proxy sanitized from the request-header section, bypassing header-based trust decisions in the application. Any http4s application using BlazeServerBuilder over HTTP/1.1 whose routes or middleware trust proxy-set headers, including X-Forwarded-For, X-Real-IP, and X-Forwarded-Host, is affected. If a fronting proxy strips or normalizes those headers but forwards chunked bodies with trailers intact, an attacker can spoof client IP for allow-lists, rate limits, or auditing, forge the https scheme, or inject internal authorization headers. A promoted Connection: close trailer is also honored, allowing attacker-controlled termination of pooled backend connections. This issue is fixed in versions 0.23.18 and 1.0.0-M42. | 24 Oct |
| CVE-2026-85974 | 7.4 high | 0.00% | no CPE yet | Progress MarkLogic Server 12.x releases before 12.1.0 and 11.x releases before 11.3.7 do not consistently validate TLS certificate hostnames for certain outbound connections. A network-positioned attacker could exploit this weakness to intercept or modify communications with an affected service. | 15 Oct |
| CVE-2026-107230 | 7.4 high | 0.00% | no CPE yet | The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity's data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14. | 8 Oct |
| CVE-2025-62371 | 7.4 high | 0.00% | amazon, opensearch_data_prepper | OpenSearch Data Prepper as an open source data collector for observability data. In versions prior to 2.12.2, the OpenSearch sink and source plugins in Data Prepper trust all SSL certificates by default when no certificate path is provided. Prior to this fix, the OpenSearch sink and source plugins would automatically use a trust all SSL strategy when connecting to OpenSearch clusters if no certificate path was explicitly configured. This behavior bypasses SSL certificate validation, potentially allowing attackers to intercept and modify data in transit through man-in-the-middle attacks. The vulnerability affects connections to OpenSearch when the cert parameter is not explicitly provided. This issue has been patched in version 2.12.2. As a workaround, users can add the cert parameter to their OpenSearch sink or source configuration with the path to the cluster's CA certificate. | 8 Oct |
| CVE-2026-35587 | 7.3 high | 0.00% | nicolargo, glances | Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.4, a Server-Side Request Forgery (SSRF) vulnerability exists in the Glances IP plugin due to improper validation of the public_api configuration parameter. The value of public_api is used directly in outbound HTTP requests without any scheme restriction or hostname/IP validation. An attacker who can modify the Glances configuration can force the application to send requests to arbitrary internal or external endpoints. Additionally, when public_username and public_password are set, Glances automatically includes these credentials in the Authorization: Basic header, resulting in credential leakage to attacker-controlled servers. This vulnerability can be exploited to access internal network services, retrieve sensitive data from cloud metadata endpoints, and/or exfiltrate credentials via outbound HTTP requests. The issue arises because public_api is passed directly to the HTTP client (urlopen_auth) without validation, allowing unrestricted outbound connections and unintended disclosure of sensitive information. Version 4.5.4 contains a patch. | Mon 26 Oct |
| CVE-2026-13201 | 7.3 high | 0.00% | kubevirt, redhat, openshift_virtualization | A flaw was found in KubeVirt's safepath package used by virt-handler. The OpenAtNoFollow function uses O_PATH|O_NOFOLLOW to obtain a file descriptor to a path leaf, but downstream operations resolve the path via /proc/self/fd/N using link-following syscalls. When the leaf is a symlink, the kernel dereferences it, defeating the intended no-follow protection. An attacker with access to a virt-launcher pod can exploit this to redirect virt-handler's IPC socket connections, including the notify socket used for VM domain lifecycle events. By hijacking this socket, the attacker can inject arbitrary domain events into virt-handler, causing it to take incorrect lifecycle actions, corrupt VM state in the Kubernetes API, or crash — resulting in sustained denial of VM management services for all virtual machines on the affected node. Additionally, the same symlink following flaw allows virt-handler to apply file ownership or permission changes to unintended host paths. | Sun 25 Oct |
| CVE-2025-54808 | 7.3 high | 0.00% | no CPE yet | Oxford Nanopore Technologies' MinKNOW software at or prior to version 24.11 stores authentication tokens in a file located in the system's temporary directory (/tmp) on the host machine. This directory is typically world-readable, allowing any local user or application to access the token. If the token is leaked (e.g., via malware infection or other local exploit), and remote access is enabled, it can be used to establish unauthorized remote connections to the sequencer. Remote access must be enabled for remote exploitation to succeed. This may occur either because the user has enabled remote access for legitimate operational reasons or because malware with elevated privileges (e.g., sudo access) enables it without user consent. This vulnerability can be chained with remote access capabilities to generate a developer token from a remote device. Developer tokens can be created with arbitrary expiration dates, enabling persistent access to the sequencer and bypassing standard authentication mechanisms. | 8 Oct |
| CVE-2026-115505 | 7.2 high | 0.00% | no CPE yet | libsmb2 before 6.3 contains integer overflow vulnerabilities in the DCE/RPC NDR decoder in lib/dcerpc.c that allow heap out-of-bounds reads and writes. A malicious SMB server or machine-in-the-middle on unsigned connections can send crafted NetrShareEnum replies with wrapping actual_count or max_count values when clients call smb2_share_enum_async(), corrupting heap memory. | 23 Oct |
| CVE-2026-107858 | 7.2 high | 0.00% | no CPE yet | Missing Origin Validation in WebSockets (CWE-1385) and Permissive Cross-domain Policy with Untrusted Domains (CWE-942) in the development web server (ADK Web) in Google Agent Development Kit (ADK) for Java (com.google.adk:google-adk-dev versions 0.1.0 before 1.13.0 and com.google.adk:google-adk-maven-plugin versions 0.3.0 before 1.13.0) allow a remote attacker to control a locally running agent and read its data via a malicious web page visited by a developer while the server is running. The /run_live WebSocket endpoint accepts connections from any origin by default (hardcoded via setAllowedOrigins("*") in versions 0.1.0 through 1.5.0, and defaulting to * via adk.web.cors.origins in versions 1.6.0 through 1.12.0), and since version 0.4.0 the REST API returns Access-Control-Allow-Origin: * by default. Because the server has no authentication and requests originate from the developer's browser (so binding to localhost does not prevent exploitation), a cross-origin page can send messages to the agent (triggering registered tools), stream agent responses, and list, read, create, or delete sessions and artifacts. In versions 1.6.0 through 1.12.0, users can mitigate the issue by setting the adk.web.cors.origins property to an explicit allowlist of trusted origins (such as http://localhost:8000). The vulnerability is fixed in version 1.13.0, which enforces a same-origin default for CORS and the /run_live WebSocket endpoint, and rejects DNS-rebinding requests over loopback. | 23 Oct |
| CVE-2026-108361 | 7.2 high | 0.00% | no CPE yet | Privasys Remote Attestation TLS Clients provides multi-language utilities for verifying attested TLS connections. Before 0.9.1, an attacker with local access could modify workload code, data, and configuration at any time after successful connection establishment. Once Evidence was successfully appraised and the connection was established, there was a window of vulnerability from the establishment of the connection to the termination of the connection where an attacker could modify the state of the workload and platform at runtime on the TLS endpoint acting as the Attester. This vulnerability was possible because Privasys/ra-tls-clients performed attestation only once in the lifetime of the connection (at connection establishment time), and the verifying peer continued to believe that the state was the same as in the initial Evidence throughout, whereas it could be stale at some point in time. This vulnerability is fixed in 0.9.1. | 16 Oct |
| CVE-2026-116252 | 7.1 high | — | pgadmin.org, pgadmin 4 | pgAdmin 4's materialized view refresh passed the target database's name to psql's --dbname argument unchanged. libpq treats a --dbname value containing "=" (or a postgresql:// URI) as a full connection string, whose keywords override the host, port and other settings pgAdmin had supplied. A database whose name is such a string, which any role with CREATEDB can create, therefore redirected the psql process pgAdmin starts for the refresh to a host and port of the creator's choosing, and the connecting user's saved server password was presented to that endpoint. It also let the pgAdmin host be made to open connections to arbitrary addresses. The same weakness was fixed for Backup, Restore, Maintenance and Import/Export Data in earlier releases (CVE-2026-86862); the materialized view refresh was the remaining caller. The fix routes the name through the same database_conninfo() helper, so libpq treats it strictly as a database name. This issue affects pgAdmin 4: before 9.19. | Fri 30 Oct |
| CVE-2026-118678 | 7.1 high | 0.00% | no CPE yet | n8n before 2.41.4 and 2.42.x before 2.42.1 contains a prototype pollution vulnerability that allows low-privileged users to alter built-in object behaviour by saving workflows with specially named connection keys. Attackers can add keys such as __proto__ to workflow connections, which the periodic history compaction task processes, causing logins and writes to fail with server errors. | Wed 28 Oct |
| CVE-2024-34268 | 7.1 high | 0.00% | no CPE yet | EQ-3 Eqiva CC-RT-BLE Bluetooth Smart Radiator Thermostat Firmware up to the latest version 1.46 was discovered to allow unsecured bluetooth connections. This vulnerability allows attackers to gain full access to the device without authentication. | Tue 27 Oct |
| CVE-2026-6066 | 7.1 high | 0.00% | connectwise, automate | ConnectWise has released a security update for ConnectWise Automate™ that addresses a behavior in the ConnectWise Automate Solution Center where certain client-to-server communications could occur without transport-layer encryption. This could allow network‑based interception of Solution Center traffic in Automate deployments. The issue has been resolved in Automate 2026.4 by enforcing secure communication for affected Solution Center connections. | Mon 26 Oct |
| CVE-2026-58213 | 7.1 high | 0.00% | linuxfoundation, nats-server | NATS Server is a high-performance server for NATS.io, the cloud and edge native messaging system. Prior to 2.14.1 and 2.12.9, an MQTT client could include protocol control characters in subscription filters that were later forwarded as NATS protocol data to route or leafnode connections, corrupting the forwarded protocol stream and allowing injection of unintended NATS protocol operations. This issue is fixed in versions 2.14.1 and 2.12.9. | Sun 25 Oct |
| CVE-2026-70462 | 7.1 high | 0.00% | no CPE yet | rsync 3.1.0 before 3.5.0 contains a signed integer overflow vulnerability in the I/O timeout implementation that allows attackers to permanently disable connection timeouts by injecting MSG_IO_TIMEOUT messages carrying non-positive (zero or negative) values. Attackers can craft malicious MSG_IO_TIMEOUT messages that cause the timeout variable to wrap to a non-positive value, preventing the timeout check from firing and enabling idle or stalled connections to hold daemon slots indefinitely, leading to resource exhaustion. | 24 Oct |
| CVE-2026-104948 | 7.1 high | 0.00% | no CPE yet | WarehousePG (WHPG) 6.27.1 through 6.27.6 and 7.2.1 through 7.6.0 are affected by a missing authorization vulnerability (CWE-862) in the built-in cluster expansion functions gp_expand_lock_catalog() and gp_expand_bump_version(). Any authenticated database role can run them, and neither checks privileges. A low-privileged user can call gp_expand_lock_catalog() inside an open transaction to block all catalog changes across the cluster for every user, superusers included, until that transaction ends, which in practice requires a superuser to terminate the session. Blocked changes include DDL, temporary table creation, GRANT and CREATE ROLE. The same user can call gp_expand_bump_version() repeatedly. Each call disconnects sessions that hold temporary tables, with a FATAL error on their next catalog change, and makes every other session rebuild its segment connections. | 22 Oct |
| CVE-2026-111917 | 7.1 high | 0.00% | no CPE yet | Vikunja 2.3.0 before 2.7.0 contains an improper session validation vulnerability that allows attackers to keep WebSocket access after revocation because handleAuth never checks the JWT sid claim against the sessions table. Attackers holding a stolen access token can open or maintain connections to /api/v2/ws after session deletion or TOTP enrollment, continuing to receive the victim's notification.created pushes, including comment, task and project content. | 19 Oct |
| CVE-2026-111383 | 7.1 high | 0.00% | no CPE yet | Nezha from 2.0.13 before 2.3.15 contains a resource exhaustion vulnerability that allows authenticated users to open unbounded concurrent connections to the /api/v1/ws/transfer WebSocket endpoint. Attackers can hold thousands of subscriptions created by ServerTransferClass.Subscribe without limits, exhausting file descriptors, memory, and goroutines and blocking agent gRPC reconnections. | 16 Oct |
| CVE-2026-114637 | 7.0 high | 0.00% | traefik | Traefik from v3.2.0 before v3.7.14 contains an authentication bypass vulnerability in the experimental FastProxy connection pool, which fails to pin NTLM/Negotiate-authenticated backend connections to their frontend connection. Unauthenticated clients can be handed a pooled keep-alive backend connection where a victim completed an NTLM or Negotiate handshake, letting them read victim data and act as that victim. | Wed 28 Oct |
| CVE-2025-55702 | 7.0 high | 0.00% | no CPE yet | When a client sends a POST with Expect: 100-continue and the origin answers before reading the body, Apache Traffic Server parses the unread body left on the client connection as the next request. An attacker behind a front-end proxy that shares connections to Traffic Server can use this to smuggle requests past the front end and desynchronize responses for other users. This issue affects Apache Traffic Server: from 8.0.0 through 8.1.11, from 9.0.0 through 9.2.15, from 10.0.0 through 10.1.4, 10.2.0. Users are recommended to upgrade to version 9.2.16, 10.1.5, or 10.2.1, which fix the issue. | Wed 28 Oct |
| CVE-2026-114639 | 7.0 high | 0.00% | traefik | Traefik 2.11.0 before 2.11.58 and 3.0.0 before 3.7.14 contains an authentication bypass because a first request preauthenticated with an Authorization: Negotiate token authenticates a socket in the globally shared backend connection pool, which is never isolated. Unauthenticated attackers on separate frontend connections can be assigned that NTLM/Kerberos-bound socket and perform reads or writes with the victim's identity. | Tue 27 Oct |
| CVE-2026-40875 | 7.0 high | 0.00% | no CPE yet | mailcow: dockerized is an open source groupware/email suite based on docker. In versions prior to 2026-03b, the user dashboard's "Seen successful connections" (login history) renders the client IP from login logs without HTML escaping. Because the server trusts the X-Real-IP header as the source IP for logging, an attacker can inject HTML/JS into this field. This Self-XSS can be exploited by a Login CSRF to force the victim into the attacker's account, and then read emails in a previous browser tab. Version 2026-03b fixes the vulnerability. | Mon 26 Oct |
| CVE-2026-16792 | 7.0 high | 0.00% | no CPE yet | An improper certificate validation vulnerability was reported in multiple Lenovo XClarity Orchestrator (LXCO) 2.2.0 microservices that could allow an adjacent network attacker to intercept sensitive communications by performing a machine-in-the-middle attack against HTTPS connections during TLS certificate validation under certain circumstances. | 24 Oct |
| CVE-2025-14821 | 7.0 high | 0.00% | libssh, redhat, hardened_images | A flaw was found in libssh. This vulnerability allows local man-in-the-middle attacks, security downgrades of SSH (Secure Shell) connections, and manipulation of trusted host information, posing a significant risk to the confidentiality, integrity, and availability of SSH communications via an insecure default configuration on Windows systems where the library automatically loads configuration files from the C:\etc directory, which can be created and modified by unprivileged local users. | 14 Oct |
| CVE-2026-106036 | 6.9 medium | 0.00% | krajowa izba rozliczeniowa, szafir | Szafir accepts any client or server certificate without performing certificate and hostname validation, allowing HTTPS connections without authenticating the remote server. An attacker can provide an arbitrary SSL/TLS certificate and cause the application to download an update file from their server. This issue was fixed in version 2.0 build 708. | Thu 29 Oct |
| CVE-2026-70380 | 6.9 medium | 0.00% | no CPE yet | A denial-of-service vulnerability has been identified in the Miracast over Infrastructure Connection Establishment (MICE) service. An unauthenticated attacker with network access to the MICE service could consume available connection capacity, preventing legitimate users from establishing MICE-based Miracast connections while the condition persists. Miracast P2P is not affected. MICE is disabled in the default configuration and must be explicitly enabled by the customer. On most devices, Miracast P2P is available independently of MICE, but a complete disruption of Miracast can occur on some devices when WLAN is configured for Infrastructure mode. | Tue 27 Oct |
| CVE-2026-40435 | 6.9 medium | 0.00% | f5, big-ip_access_policy_manager, big-ip_advanced_firewall_manager, big-ip_advanced_web_application_firewall | When configured, IP-based access restrictions for httpd do not cover all endpoints, which may allow connections from blocked addresses. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | Mon 26 Oct |
| CVE-2026-57024 | 6.9 medium | 0.00% | juniper, junos | A Use of Multiple Resources with Duplicate Identifier vulnerability in the IKE daemon (iked) of Juniper Networks Junos OS on MX with SPC3 and SRX Series allows an unauthenticated, network-based attacker to cause a Denial-of-Service (DoS). On an MX with SPC3 and SRX devices configured for VPN service, when a large number of VPN negotiations fail a peer index rollover will eventually occur. As a result, new peers are assigned index values that are already in use and the iked process starts to crash repeatedly. This results in failure to establish new VPN connections and rekeying existing ones. To restore service the system must be rebooted. Please note that the index value can't be monitored, so customers should monitor tunnel up and down events and if a lot of events occur over an extended period of time it becomes likely that this issue occurs. To be exposed to this issue the system needs to run iked (vs. kmd which is not affected), which can be verified with: user@host> show system processes extensive | match "KMD|IKED" This issue affects Junos OS on MX with SPC3, SRX Series: * all versions before 23.2R2-S7, * 23.4 versions before 23.4R2-S6, * 24.2 versions before 24.2R2-S3, * 24.4 versions before 24.4R2-S4, * 25.2 versions before 25.2R1-S1. | Sun 25 Oct |
| CVE-2026-63096 | 6.9 medium | 0.00% | no CPE yet | Dendrite through 0.13.8 contains a server-side request forgery vulnerability that allows unauthenticated attackers to cause the server to open outbound TLS connections to arbitrary hosts and ports by supplying an unvalidated serverName parameter to the legacy media download endpoint. Attackers can exploit distinguishable error response classes and leaked internal IP addresses in error messages to perform blind port scanning and enumerate internal network topology. | 24 Oct |
| CVE-2026-13074 | 6.9 medium | 0.00% | mongodb | An unauthenticated remote client can cause excessive CPU consumption on a MongoDB server by sending a specific combination of parameters to the awaitable hello command in exhaust mode. The server's handling of this combination results in a response loop that bypasses normal throttling, allowing a small number of connections to degrade server availability. | 24 Oct |
| CVE-2026-111065 | 6.9 medium | 0.00% | no CPE yet | AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.4, Max-Age processing can overflow and skip closing a connection. An attacker can consequently exhaust the connection pool temporarily until garbage collection resolves the connections. This issue is fixed in version 3.14.4. | 19 Oct |
| CVE-2025-10695 | 6.9 medium | 0.00% | opensupports | Two unauthenticated diagnostic endpoints allow arbitrary backend-initiated network connections to an attacker‑supplied destination. Both endpoints are exposed with permission => 'any', enabling unauthenticated SSRF for internal network scanning and service interaction. This issue affects OpenSupports: 4.11.0. | 19 Oct |
| CVE-2026-34964 | 6.9 medium | 0.00% | no CPE yet | Adminer before 5.5.0 contains a server-side request forgery vulnerability in the login form's server field validator, which only inspects leading integers for privileged ports and fails to reject non-numeric port values. Attackers can inject PDO DSN keys like host= and port= into the server parameter to bypass the privileged-port restriction and establish TCP connections to arbitrary internal hosts and ports before authentication. | 12 Oct |
| CVE-2026-85479 | 6.9 medium | 0.00% | no CPE yet | The STTP-based data publisher on openPDC accepts network connections without authentication in its default configuration. An unauthenticated network attacker can connect to this interface and exchange data with it. | 11 Oct |
| CVE-2026-100251 | 6.9 medium | 0.00% | no CPE yet | Wormhole.app as deployed before 2026-08-22 misconfigures the coturn TURN server and does not properly restrict TCP relay peers, allowing an unauthenticated attacker to access instance metadata or to source TCP connections from the Wormhole relay's IP. | 11 Oct |
Download these 395 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.