Search vulnerabilities

Use the Query Builder to create your own search query, or check out the documentation to learn the search syntax.

Results 10,968

Export CSV
CVE-2026-116332

PostgreSQL portal setup use-after-free executes arbitrary code

Use after free in PostgreSQL portal setup allows an object creator to execute arbitrary code as the operating system user running the database, via running user-defined code during planning or executor startup that closes the portal currently being prepared. Versions before PostgreSQL 18.7, 17.12, 16.16, 15.20, and 14.25 are affected.

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Postgresql
Products
Postgresql
CVE-2026-64523

net/handshake: Take a long-lived file reference at submit

In the Linux kernel, the following vulnerability has been resolved: net/handshake: Take a long-lived file reference at submit handshake_nl_accept_doit() needs the file pointer backing req->hr_sk->sk_socket to survive the window between handshake_req_next() and the subsequent FD_PREPARE() and get_file(). The submit-side sock_hold() does not provide that. sk_refcnt keeps struct sock alive, but struct socket is owned by sock->file: when the consumer fputs the last file reference, sock_release() tears the socket down regardless of any sock_hold. Add an hr_file pointer to struct handshake_req and acquire an explicit reference on sock->file during handshake_req_submit(). handshake_complete() and handshake_req_cancel() release the reference on the completion-bit-winning path. The submit error path must also release the file reference, but after rhashtable insertion a concurrent handshake_req_cancel() can discover the request and race the error path. Gate the error-path cleanup -- sk_destruct restoration, fput, and request destruction -- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same serialization handshake_complete() and handshake_req_cancel() already use. When cancel has already claimed ownership, the submit error path returns without touching the request; socket teardown handles final destruction. The accept-side dereferences are not yet retargeted; that change comes in the next patch.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-64475

vfio/pci: Release the VGA arbiter client on register_device() failure

In the Linux kernel, the following vulnerability has been resolved: vfio/pci: Release the VGA arbiter client on register_device() failure The re-order in the Fixes commit below displaced vfio_pci_vga_init() as the last failure point of what is now vfio_pci_core_register_device() without introducing an unwind for the VGA arbiter registration. In current kernels this is mostly benign because vfio_pci_set_decode() only uses pci_dev state, but the original failure path could leave a callback with a freed vdev cookie. The stale registration also becomes unsafe again once the callback follows drvdata to the vfio device. Add the required VGA unwind callout.

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-124917

Sandbox escape due to use-after-free in the Widget: Gtk component

Sandbox escape due to use-after-free in the Widget: Gtk component. This vulnerability was fixed in Firefox 160, Firefox ESR 153.7, Thunderbird 160, and Thunderbird 153.7.

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-124861

Sandbox escape due to use-after-free in the Audio/Video: cubeb component

Sandbox escape due to use-after-free in the Audio/Video: cubeb component. This vulnerability was fixed in Firefox 160, Firefox ESR 115.45, Firefox ESR 153.7, Thunderbird 160, and Thunderbird 153.7.

CVSS 3.1 · 9.6 Critical EPSS < 1% KEV · Not listed
Vendors
—
Products
—
CVE-2026-64564

sctp: don't free the ASCONF's own transport in DEL-IP processing

In the Linux kernel, the following vulnerability has been resolved: sctp: don't free the ASCONF's own transport in DEL-IP processing sctp_process_asconf() caches the transport the ASCONF chunk is processed against in asconf->transport (== chunk->transport, set once in sctp_rcv()). For an ASCONF located through its Address Parameter by __sctp_rcv_asconf_lookup(), that cached transport corresponds to the Address Parameter, which need not be the packet's source address. sctp_process_asconf_param() rejects a DEL-IP for the packet source address (ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport. A single ASCONF can therefore carry, in order: [Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0] where L differs from the source. The DEL-IP for L passes the D8 check and calls sctp_assoc_rm_peer() on the transport that asconf->transport still points at, freeing it (RCU-deferred). The following wildcard DEL-IP then reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed transport (->ipaddr, ->state) and plants the dangling pointer into asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping only the pointer that is no longer on the list, removes every real transport, leaving the association with a transport_count of 0 and primary_path/active_path pointing at freed memory. Reject a DEL-IP that targets the transport the ASCONF is being processed against, mirroring the existing source-address guard, so the wildcard branch can never reuse a freed transport.

CVSS 3.1 · 9.8 Critical EPSS 1.4% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-126861

chromium-browser: chromium-browser: Arbitrary code execution via crafted HTML page

Use after free in Media in Google Chrome on on Android prior to 157.0.8103.78 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: High)

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Google
Products
Android Chrome
CVE-2026-126877

chromium-browser: Use after free in Dawn

Use after free in Dawn in Google Chrome prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Google
Products
Chrome
CVE-2026-126879

chromium-browser: chromium-browser: Arbitrary code execution via crafted HTML page

Use after free in Layout in Google Chrome prior to 157.0.8103.78 allowed a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page. (Chromium security severity: Critical)

CVSS 3.1 · 8.8 High EPSS < 1% KEV · Not listed
Vendors
Google
Products
Chrome
CVE-2026-126883

chromium-browser: chromium-browser: Arbitrary code execution via use-after-free in Core

Use after free in Core in Google Chrome on on Windows prior to 157.0.8103.78 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Google Microsoft
Products
Chrome Windows
CVE-2026-63979

net/handshake: hand off the pinned file reference to accept_doit

In the Linux kernel, the following vulnerability has been resolved: net/handshake: hand off the pinned file reference to accept_doit handshake_req_next() removes the request from the per-net pending list and drops hn_lock before handshake_nl_accept_doit() reads req->hr_sk->sk_socket and dereferences sock->file (once in FD_PREPARE() and again in get_file()). In that window a consumer running tls_handshake_cancel() followed by sockfd_put() (svc_sock_free) or __fput_sync() (xs_reset_transport) releases sock->file. sock_release() then runs sock_orphan(), zeroing sk_socket, and frees the struct socket. The accept-side code either reads NULL through sk_socket or chases freed memory. The submit-side sock_hold() does not prevent this. sk_refcnt protects struct sock, but struct socket and sock->file are independently refcounted via the file descriptor the consumer owns. Pinning sk leaves sock and sock->file unprotected. Retarget the accept-side dereferences at req->hr_file, which was pinned at submit time, instead of req->hr_sk->sk_socket->file. Pinning on its own is not sufficient: a consumer that cancels between handshake_req_next() returning and accept_doit reaching FD_PREPARE() takes the !remove_pending() branch in handshake_req_cancel() and drops hr_file before the accept side takes its own reference. Hand off an additional file reference inside handshake_req_next(), under hn_lock, so the accept side operates on a reference that no concurrent handshake_req_cancel() can revoke. FD_PREPARE() consumes that handed-off reference, either by transferring it to the new fd in fd_publish() or by dropping it in the cleanup destructor on error; the explicit get_file() that previously balanced FD_PREPARE() is therefore redundant and goes away. Update handshake_req_cancel_test2 and _test3 to simulate the FD_PREPARE() consumption with an fput() so the kunit file-count assertions stay balanced.

CVSS 3.1 · 9.8 Critical EPSS < 1% KEV · Not listed
Vendors
Linux
Products
Linux Kernel
CVE-2026-123864

Node.js is vulnerable to cross-connection memory disclosure via TLS write re-entrancy in the HTTPS request parser

A re-entrancy flaw in Node.js HTTPS lets an unauthenticated client read memory belonging to other connections, including TLS private keys and other users' requests. TLSWrap::DoWrite() calls ClearOut() directly when asked to write zero bytes; if that write is issued from JavaScript running inside the HTTP parser's on_body callback, ClearOut() decrypts the next TLS record while the parser is still mid-body, re-entering llhttp_execute() and causing a use-after-free and an out-of-bounds heap read. The server then copies that freed or unrelated heap memory into the response for the request body. Triggering it requires a handler that calls res.flushHeaders() before the request body ends and later calls res.end() with a non-empty chunk, and reading the leaked memory requires any ordinary route that echoes or stores a request body. Cleartext node:http is not affected. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS 3.1 · 7.4 High EPSS < 1% KEV · Not listed
Vendors
Nodejs
Products
Nodejs
CVE-2026-123866

Node.js is vulnerable to HTTP/2 response memory disclosure via a use-after-free during stream teardown

A use-after-free in Node.js HTTP/2 stream teardown can leak response memory, including the contents of other connections' response buffers, to a peer. When a stream is torn down while a write is still backpressured, for example by a peer RST_STREAM or by the server's own per-stream timeout destroying the stream, the stream's response buffer is freed but a reference to it is still used, so freed or unrelated heap memory is written to the socket instead of the intended response. On Node.js 26.x and 24.x the teardown can be driven purely by a remote peer once the window-size change from 26.9.0 and 24.22.0 is present, and on all supported lines the same defect is reachable through an application-initiated teardown such as a per-stream idle timeout. This vulnerability affects Node.js 26.x, 24.x, and 22.x.

CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
Vendors
Nodejs
Products
Nodejs