Export limit exceeded: 13730 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (13730 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-80899 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: erofs: remove fscache backend entirely EROFS over fscache was introduced to provide image lazy pulling functionality. After the feature landed, the fscache subsystem made netfs a new hard dependency, which is unexpected for a local filesystem and has an kernel-defined caching hierarchy which could be inflexible compared to the fanotify pre-content hooks. Therefore, this feature has been deprecated for almost two years. As EROFS file-backed mounts and fanotify pre-content hooks both upstream for a while and already providing equivalent functionality (erofs-utils has supported fanotify pre-content hooks), let's remove the fscache backend now. The main application of this feature is Nydus [1], and they plan to move to use fanotify pre-content hooks in the near future too. I hope this patch can be merged into Linux 7.2, which is also motivated by newly found implementation issues [2][3] that are not worth investigating given the deprecation and limited development resources. The associated fscache/cachefiles cleanup patch will follow separately through the vfs tree (netfs) later: it seems fine since the codebase is isolated by CONFIG_CACHEFILES_ONDEMAND. [1] https://github.com/dragonflyoss/nydus/blob/v2.1.0/docs/nydus-fscache.md [2] https://github.com/dragonflyoss/nydus/pull/1824 [3] https://lore.kernel.org/r/20260619135800.1594811-1-michael.bommarito@gmail.com | ||||
| CVE-2026-52130 | 2 Ggml, Ggml-org | 2 Llama.cpp, Llama.cpp | 2026-09-04 | 7.5 High |
| llama.cpp b5693 and before is vulnerable to Uncontrolled Recursion in common/json-schema-to-grammar.cpp, resulting in a denial of service. | ||||
| CVE-2026-52131 | 2 Ggml, Ggml-org | 2 Llama.cpp, Llama.cpp | 2026-09-04 | 7.5 High |
| llama.cpp b5693 and before has a Reachable Assertion via the gguf_reader::read function. | ||||
| CVE-2026-72657 | 1 Elastic | 1 Fleet Server | 2026-09-04 | 6.5 Medium |
| Authorization Bypass Through User-Controlled Key (CWE-639) in Fleet Server can lead to information disclosure via Manipulating User-Controlled Variables (CAPEC-77). The authorization decision for artifact downloads relied on a client-supplied value that was persisted without being validated against the server-side record of the requesting agent's assignment. An authenticated party in possession of a valid enrolled agent credential could therefore retrieve a policy the agent is not assigned to. | ||||
| CVE-2026-79684 | 1 Dell | 12 Powerstore 1000t, Powerstore 1200t, Powerstore 3000t and 9 more | 2026-09-04 | 8.8 High |
| Dell PowerStore contains a Protection Mechanism Failure vulnerability. An authenticated user with limited privileges could potentially exploit this vulnerability to bypass access restrictions and gain escalated privileges. | ||||
| CVE-2026-52132 | 2 Ggml, Ggml-org | 2 Llama.cpp, Llama.cpp | 2026-09-04 | 7.5 High |
| llama.cpp through commit 97f06e9, when started with the --reranking flag, allows remote attackers to cause a denial of service (std::bad_alloc and HTTP 500) via a negative top_n value in a POST request to /rerank. | ||||
| CVE-2026-47851 | 2 Spring, Vmware | 2 Spring Ai, Spring Ai | 2026-09-04 | 7.5 High |
| Analyzing a PDF with a deeply nested or cyclic table of contents can cause a StackOverflowError in the ingestion thread. Spring AI 2.0.0 Spring AI 1.1.0 - 1.1.8 Spring AI 1.0.0 - 1.0.9 | ||||
| CVE-2026-80904 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net/tls: Fail tls_sw_splice_read() after a failed async decrypt When an async decrypt fails, tls_decrypt_done() records the error in ctx->async_wait.err and calls tls_err_abort(), which stores it in sk_err. tls_sw_recvmsg() and tls_sw_read_sock() each read async_wait.err once they hold the reader lock and fail the call: a record that did not authenticate breaks the connection. tls_sw_splice_read() has no such check, and sk_err does not stand in for one. tls_rx_rec_wait() tests sk_err only inside the loop it skips whenever a record is already parsed, and the first reader to reach sock_error() clears it, while async_wait.err persists. A splice therefore keeps delivering records on a connection that recvmsg() and read_sock() refuse to read. Read async_wait.err in tls_sw_splice_read() as the other two readers do. | ||||
| CVE-2026-61699 | 2026-09-04 | 8.1 High | ||
| nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. Prior to version 0.7.1, revocation is the only in-band mechanism that isolates a compromised/offboarded host from a Nebula mesh. Because the blocklist never reaches any peer's config.yml, a Blocked host retains full overlay reachability to every peer under its CA (and internal services on the mesh) for up to 30d (agent) / 365d (mobile). An attacker who exfiltrates host.key+host.crt can run stock slackhq/nebula directly, ignore the agent's 403/410 poll responses, and stay connected after the operator revokes the host. Operator-visible state (UI shows blocked, audit log records it) is misleading. This issue has been patched in version 0.7.1. | ||||
| CVE-2026-55513 | 2026-09-04 | 5.4 Medium | ||
| nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. From version 0.3.0 to before version 0.5.0, the nebula-mgmt Web UI host-creation path ignores both the server-wide enrollment_token_ttl security setting and per-network network_config.enrollment_token_ttl overrides. API host creation and token-regeneration paths use the configured TTL resolver, but POST /ui/hosts hardcodes now.Add(24 * time.Hour) for newly minted agent enrollment tokens. In deployments that intentionally reduce enrollment-token lifetime, any authenticated operator who can create a host through the Web UI can still mint a bearer enrollment token valid for about 24 hours. This issue has been patched in version 0.5.0. | ||||
| CVE-2026-80848 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: xfrm: espintcp: fix UAF during close ZDI reported and analyzed a race condition during close for espintcp sockets: espintcp_close() frees emsg->skb via kfree_skb() without holding any socket lock. Concurrently, the xfrm_trans_reinject work queue invokes esp_output_tcp_finish() -> espintcp_push_skb() -> espintcp_push_msgs() -> skb_send_sock_locked(), which reads the same skb as a data source. Fix this by adding a synchronize_rcu() call after resetting sk_prot, since esp_output_tcp_finish() runs under RCU and won't use a socket with sk_prot == &tcp_prot. Simply taking the socket lock in espintcp_close() could lead to leaks, if esp_output_tcp_finish() re-adds an skb in the slot we just freed. After this, the existing barrier() is no longer needed. | ||||
| CVE-2026-80855 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: fuse: fix invalidate lock leak on open O_TRUNC DAX failure fuse_open() takes filemap_invalidate_lock() for a DAX truncate (dax_truncate = true) and releases it before the out_inode_unlock label. But when fuse_dax_break_layouts() fails, the goto out_inode_unlock skips the unlock and leaks the rwsem, so any later fault or truncate on the file stalls on the stale lock. fuse_dax_break_layouts() can fail with -ERESTARTSYS when a signal interrupts the wait for busy DAX pages to drain: open("file", O_RDWR | O_TRUNC) └─ fuse_open() ├─ filemap_invalidate_lock() # dax_truncate └─ fuse_dax_break_layouts() └─ dax_break_layout() └─ wait_page_idle() # TASK_INTERRUPTIBLE └─ fuse_wait_dax_page() # unlock, schedule, re-lock └─ signal → -ERESTARTSYS goto out_inode_unlock # <- lock leaked Fix this by moving filemap_invalidate_unlock() below the label so that all error paths release the lock, and rename the label to out_unlock as it now covers more than just the inode lock. | ||||
| CVE-2026-59305 | 2 Spring, Vmware | 2 Spring Cloud Stream, Spring Cloud Stream | 2026-09-04 | 3.1 Low |
| Partition interceptor may be improperly added while sending message. Spring Cloud Stream 5.0.0 - 5.0.2 Spring Cloud Stream 4.3.0 - 4.3.3 Spring Cloud Stream 4.2.0 - 4.2.6 | ||||
| CVE-2026-27432 | 2026-09-04 | 5.4 Medium | ||
| Authorization Bypass Through User-Controlled Key vulnerability in sc Internet Vivoo WP Rentals allows Exploiting Incorrectly Configured Access Control Security Levels. This issue affects WP Rentals: from n/a before 3.16.0. | ||||
| CVE-2026-80831 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: mxs-dcp - fix source scatterlist length access mxs_dcp_aes_block_crypt() uses sg_dma_len() without mapping the source scatterlist with dma_map_sg() first. Therefore, sg_dma_len() is invalid and could return zero or a stale DMA length, causing encryption and decryption to process the wrong number of bytes when CONFIG_NEED_SG_DMA_LENGTH=y. Use the original scatterlist length instead. | ||||
| CVE-2026-85638 | 1 Jofpin | 1 Trape | 2026-09-04 | 7.3 High |
| A weakness has been identified in jofpin trape 2.0. This affects an unknown part of the file core/user.py. This manipulation of the argument vId/id causes authorization bypass. Remote exploitation of the attack is possible. The exploit has been made available to the public and could be used for attacks. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-80810 | 1 Linux | 1 Linux Kernel | 2026-09-04 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: io_uring/rsrc: fix folio size overflow in io_vec_fill_bvec() io_vec_fill_bvec() computes the folio size with a plain int 1: unsigned long folio_size = 1 << imu->folio_shift; imu->folio_shift is unsigned int and comes from folio_shift() of the folio backing the registered buffer, so it can be 32 or more on a 64 bit kernel. Shifting int 1 that far is undefined, and on x86 and arm64 the count is taken modulo 32, so a shift of 34 yields 4 rather than 16G. Every other folio_shift shift in this file already uses 1UL. The result is that the segment estimate and the fill loop disagree. io_estimate_bvec_size() sizes the bvec array with the real shift: max_segs += (iov[i].iov_len >> shift) + 2; so a 1M iovec on a 16G folio is charged 2 segments, while io_vec_fill_bvec() then walks the same iovec in folio_size chunks of 4 bytes and writes res_bvec[bvec_idx] a quarter of a million times, past the end of the array it was given. src_bvec is advanced once per iteration as well, so imu->bvec is read past its end at the same time. validate_fixed_range() only checks that the range is inside the registered buffer and does not bound the segment count. Reaching it needs a folio with a shift of at least 32, which means a gigantic hugetlb page: 16G on arm64 with 64K pages, where CONT_PMD_SHIFT is 34 and hugetlb_add_hstate(CONT_PMD_SHIFT - PAGE_SHIFT) registers that size, and likewise on powerpc. x86_64 tops out at 1G, so a shift of 30, which still fits in int and is unaffected. Use 1UL, as the rest of the file does. | ||||
| CVE-2026-85730 | 2026-09-04 | 7.5 High | ||
| smol-toml is a small, fast, and correct TOML parser and serializer. Prior to 1.7.1, parse() can enter an infinite loop when a value inside an array or inline table is followed by a comment with no trailing newline. In src/util.ts, skipUntil() calls indexOfNewline(), receives -1 at the end of input, and resets the cursor to the beginning of the string instead of leaving the structure scan. The parser then hangs indefinitely and can consume a service's processing capacity when an application parses attacker-controlled TOML. This issue is fixed in version 1.7.1. | ||||
| CVE-2026-40998 | 2 Broadcom, Spring | 2 Spring Web Services, Spring Web Services | 2026-09-04 | 8.2 High |
| Jaxp13XPathTemplate evaluated XPath expressions for StreamSource and SAXSource inputs using a code path that parsed attacker-controlled XML with the JDK's default DocumentBuilderFactory behavior instead of Spring's hardened parser configuration. Applications that evaluate XPath against untrusted XML payloads could therefore be exposed to XML External Entity (XXE) style attacks. Affected versions: Spring Web Services 5.0.0 through 5.0.1; 4.1.0 through 4.1.3; 4.0.0 through 4.0.18; 3.1.0 through 3.1.8. | ||||
| CVE-2026-85649 | 1 Chewkeanho | 1 Software-actualizer | 2026-09-04 | 7.9 High |
| (Holloway) Chew, Kean Ho's Actualizer v1.2.0 and earlier contains a fail-open password validation vulnerability in the Alpha user and root user password loops of Shell/debian-minbase-install.sh. The installer invokes mkpasswd to generate yescrypt password hashes but does not check the command's return value and unconditionally accepts the result. If mkpasswd fails to generate a yescrypt hash, for example because an incompatible mkpasswd implementation or an environment without yescrypt support is used, the resulting password hash variable can be empty and the build proceeds. The resulting image can therefore contain empty password fields for the root and alpha accounts, potentially permitting passwordless authentication depending on the authentication configuration. | ||||