Export limit exceeded: 419993 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (419993 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2019-16475 | 2026-11-05 | N/A | ||
| Reserved ID never published and not linked to any VULN ticket - quota reclaim 2026-11-05 | ||||
| CVE-2019-16474 | 2026-11-05 | N/A | ||
| Reserved ID never published and not linked to any VULN ticket - quota reclaim 2026-11-05 | ||||
| CVE-2019-16473 | 2026-11-05 | N/A | ||
| Reserved ID never published and not linked to any VULN ticket - quota reclaim 2026-11-05 | ||||
| CVE-2019-16472 | 2026-11-05 | N/A | ||
| Reserved ID never published and not linked to any VULN ticket - quota reclaim 2026-11-05 | ||||
| CVE-2019-16447 | 2026-11-05 | N/A | ||
| Reserved ID never published and not linked to any VULN ticket - quota reclaim 2026-11-05 | ||||
| CVE-2026-93748 | 1 Http-cache-semantics Project | 1 Http-cache-semantics | 2026-11-05 | 7.5 High |
| http-cache-semantics through 4.2.0 fails to properly validate security-zeroed cache entries when processing client max-stale directives, allowing unauthenticated attackers to retrieve cached responses belonging to other users. Attackers can request the same URL with a large max-stale value to obtain another user's Set-Cookie session credentials from shared-cache entries that were deliberately zeroed for security reasons. | ||||
| CVE-2026-93687 | 2 Jonschlinkert, Micromatch | 2 Braces, Braces | 2026-11-05 | 7.5 High |
| braces through 3.0.3 contains a stack overflow vulnerability in the recursive AST walkers that lack depth guards. Attackers can supply deeply nested brace patterns under the character limit to exhaust the call stack and terminate the Node.js process with an uncaught RangeError. | ||||
| CVE-2026-117953 | 1 Mozilla | 1 Firefox | 2026-11-05 | 8.8 High |
| Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117952 | 1 Mozilla | 1 Firefox | 2026-11-05 | 8.1 High |
| Uninitialized memory in the Networking component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117951 | 1 Mozilla | 1 Firefox | 2026-11-05 | 8.8 High |
| Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117949 | 1 Mozilla | 1 Firefox | 2026-11-05 | 8.8 High |
| Use-after-free in the DOM: Core & HTML component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117948 | 1 Mozilla | 1 Firefox | 2026-11-05 | 6.3 Medium |
| Use-after-free in the SVG component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117947 | 1 Mozilla | 1 Firefox | 2026-11-05 | 6.3 Medium |
| Use-after-free in the XML component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117945 | 1 Mozilla | 1 Firefox | 2026-11-05 | 9.8 Critical |
| Incorrect boundary conditions in the XML component. This vulnerability was fixed in Firefox 159, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117944 | 1 Mozilla | 1 Firefox | 2026-11-05 | 6.3 Medium |
| Use-after-free in the Layout component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117941 | 1 Mozilla | 1 Firefox | 2026-11-05 | 8.8 High |
| Use-after-free in the DOM: CSS Object Model component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117935 | 1 Mozilla | 1 Firefox | 2026-11-05 | 6.3 Medium |
| Use-after-free in the DOM: Bindings (WebIDL) component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-117934 | 1 Mozilla | 1 Firefox | 2026-11-05 | 6.3 Medium |
| Use-after-free in the Layout component. This vulnerability was fixed in Firefox 159, Firefox ESR 115.44, Firefox ESR 153.6, Thunderbird 159, and Thunderbird 153.6. | ||||
| CVE-2026-99253 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-05 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/cancel: rearm local work wake up before sleep io_uring_try_cancel_requests() sets ->cq_wait_nr to 1 so that the next io_req_local_work_add() wakes the cancelling task. The add that takes the count to zero is the only one that wakes, later ones see a count <= 0 and return. io_uring_cancel_generic() however only becomes TASK_INTERRUPTIBLE much later, so the one wake up can be spent on a running task. That is fine as long as the entry of that add is still queued, as the io_local_work_pending() check then skips the sleep. It is not if the add was delayed after queueing its entry: CPU0 (submitter in exec or exit) CPU1 (io_req_local_work_add) mpscq_push(req A) io_uring_try_cancel_requests() io_run_local_work() // runs req A io_uring_try_cancel_requests() atomic_set(&ctx->cq_wait_nr, 1) atomic_read(&ctx->cq_wait_nr) == 1 count taken, wake_up_state() // task is running, no-op prepare_to_wait(TASK_INTERRUPTIBLE) io_local_work_pending() == false schedule() mpscq_push(req B) cq_wait_nr <= 0, return Only the sleeping task can run req B, so it is stuck in execve() until a signal happens to wake it. An exiting task doesn't even get that. Arm the count again once the task state is set and before the work list is checked, for the rings whose local work this task is the one to run. | ||||
| CVE-2026-99255 | 1 Linux | 2 Linux, Linux Kernel | 2026-11-05 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/io-wq: don't hide a link from cancellations A task that exits cancels its tracked requests and waits until they are gone. io_uring_cancel_generic() looks everywhere a request can be, and goes to sleep if it found nothing to cancel. It is woken up each time one of the requests of the task is completed by task work or freed. When io-wq is done with a request that has a link, there is a time in which the next request of the link can't be found: io_worker_handle_work() io_assign_current_work(worker, NULL) io_wq_free_work(work) io_req_find_next() // takes the link off the request io_free_req() // task work for the task io_assign_current_work(worker, linked) io_run_task_work() cond_resched() worker->cur_work = linked It is not pending, it is not the current work of a worker, and it is not yet on the list that it is about to be parked on. If the pass that the exiting task makes because of io_free_req() falls into that time, it finds nothing and the task goes to sleep. The worker then runs the link, which IO_WQ_BIT_EXIT doesn't prevent for bounded work. If that parks the request nothing is completed or freed, and nobody wakes up the task. If it is the process that exits it can't be killed any more either. NOP, IOSQE_ASYNC | IOSQE_IO_LINK FUTEX_WAIT, FUTEX2_PRIVATE exit of the thread, or of the process, up to 63us later With four of these per round 5 to 8 of 10,000 rounds hang (4 CPUs, KVM): io_uring_cancel_generic do_exit Commit f8b632e89a10 ("io_uring: tighten task exit cancellations") is about the same gap, and makes the task look again for whatever happens before io_free_req(). Free the request once the link is the current work of the worker, or pending. Whoever is woken up by that can find the link, until it is parked where cancellations look as well. To do so split io_wq_free_work() in two. | ||||