Export limit exceeded: 24315 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 16303 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 400212 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 400212 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (400212 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-97973 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: macb: destroy the phylink instance on the probe error path macb_mii_init() creates a phylink instance on both of its success paths, but the probe unwind frees the netdev without destroying it, so a failing macb_alloc_tieoff() or register_netdev() leaks the instance. Destroy it at err_out_unregister_mdio, which is only reachable once macb_mii_init() has succeeded, so bp->phylink is valid there. | ||||
| CVE-2026-97978 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: eth: ice: don't dereference pointers from TP_printk() After forwarding net-next during the v7.3 merge window we started seeing: TRACE EVENT ERROR: Event ice_tx_dim_work has double dereference in TP_printk: REC->q_vector->tx.tx_ring->q_index WARNING: kernel/trace/trace_events.c:420 at test_double_dereference.cold+0x39/0x4b this is due to extra checks added in tracing subsystem in commit b5cc230af5e5 ("tracing: Warn when an event dereferences a pointer in TP_printk()"). Printing happens long after the event was recorded, by which point the pointers may be invalid (the ring or the dim instance). Copy the eight scalars into the event instead. | ||||
| CVE-2026-97997 | 1 Linux | 1 Linux Kernel | 2026-10-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: virtio_ring: fix stale descriptor flags after a failed packed add In a packed ring the AVAIL and USED bits sit in the descriptor itself, so writing them makes that descriptor available. Those bit combinations flip meaning on every round of the ring, tracked by a wrap counter, so invalidating or validating a descriptor means inverting both bits. Commit 1ce9e6055fa0 ("virtio_ring: introduce packed ring support") has virtqueue_add_packed() make every descriptor of a chain available as it maps the chain, and write the head last. The device consumes the ring in order and stops at a head that is not available yet, so it never reaches the rest. When vring_map_one_sg() fails partway, unmap_release unmaps the segments and restores avail_used_flags, but the descriptors it wrote to in the ring stay marked with AVAIL and USED bits. The head is now the only entry that keeps the device from consuming these stale entries. For example, the ring would look like this now. Z - pre-previous command A - previous command B - aborted command C - current command [A1 DONE] [A2 DONE] <C1 EMPTY> [B2] [B3] [Z1 DONE] When the driver now attempts to issue the C command, the next add starts at the same head as B. If C spans less descriptors than B, there is no end marker because AVAIL and USED bits were still in place. And that means the device will start interpreting these stale entries (B2/B3) as another command entry, which then blocks the queue. This effect typically happens in swiotlb configurations under memory pressure, because vring_map_one_sg() can then fail with larger I/O requests which then leads to command abortions. There are broadly 2 ways to avoid leaving those flags behind: 1) Defer those flags too until the chain is complete. 2) Rewrite those flags for the previous wrap counter. Implement the second option in both packed add paths. The first option traverses the chain a second time on every successful add. The second option invalidates all added descriptors when any add fails. With this patch applied, a packed virtqueue keeps completing requests after a failed add. | ||||
| CVE-2026-102124 | 1 Kiteworks | 1 Core | 2026-10-01 | 6.5 Medium |
| A Kiteworks appliance setup interface did not enforce authentication once the appliance had completed initial configuration. An unauthenticated attacker with network access to the appliance could read and modify a limited set of setup records, including a contact name and email address captured during initial configuration. | ||||
| CVE-2026-102123 | 1 Kiteworks | 1 Core | 2026-10-01 | 7.4 High |
| A Kiteworks appliance setup interface did not confine a user-supplied file path to its intended directory, which could allow an unauthenticated attacker to write a file to any location writable by the affected service account, potentially compromising the integrity of the appliance or rendering it unavailable until an operator intervenes. Exploitation requires network access to the affected interface, which is not reachable on a fully configured appliance in its default configuration; reaching it depends on either the transient window while an appliance is first being provisioned or a non-default appliance configuration. | ||||
| CVE-2026-102122 | 1 Kiteworks | 1 Core | 2026-10-01 | 4.3 Medium |
| Kiteworks did not correctly enforce which roles a shared folder's manager was permitted to assign. In a default configuration, an authenticated user holding the Manager role on a folder could grant the Owner role to themselves or to other members of that folder. | ||||
| CVE-2026-102121 | 1 Kiteworks | 1 Secure Data Forms | 2026-10-01 | 8.6 High |
| A form-rendering interface in the Advanced Forms component is reachable without authentication so that published forms can be displayed to anonymous visitors, but it returned more data than the form itself required. Anyone who knew the web address of a published form could potentially retrieve the form owner's Kiteworks account profile, including personal details, along with parts of the deployment's configuration settings; no passwords, authentication tokens, or multi-factor secrets were exposed. | ||||
| CVE-2026-102118 | 1 Kiteworks | 1 Core | 2026-10-01 | 7.8 High |
| A local privilege escalation vulnerability in Kiteworks could have allowed an attacker with an existing shell under a low-privileged service account to escalate to root privileges on the appliance. | ||||
| CVE-2026-102115 | 1 Kiteworks | 1 Core | 2026-10-01 | 9.8 Critical |
| Kiteworks Core did not correctly validate a parameter submitted to the password reset workflow. An unauthenticated attacker who knew the email address of a user with a locally stored password could potentially reset that account's password without access to the emailed reset link and then authenticate as that user, including where the account holds administrative privileges. | ||||
| CVE-2026-102114 | 1 Kiteworks | 1 Core | 2026-10-01 | 7.2 High |
| A command injection vulnerability in Kiteworks could allow a high-privileged authenticated administrator to execute arbitrary operating-system commands as root on the affected appliance node. Successful exploitation requires an administrative account with elevated privileges. | ||||
| CVE-2026-102113 | 1 Kiteworks | 1 Core | 2026-10-01 | 7.8 High |
| A privilege escalation vulnerability in Kiteworks could allow an attacker who has already obtained code execution as an unprivileged backend service account on the appliance to escalate to root. A privileged routine did not safely handle a filesystem path that the lower-privileged account could influence, allowing the attacker to cause a root-owned operation to run arbitrary commands with the highest privileges. Exploitation requires existing local access to that service account. | ||||
| CVE-2026-102112 | 1 Kiteworks | 1 Core | 2026-10-01 | 7.8 High |
| A privilege escalation vulnerability in Kiteworks could allow an attacker who has already obtained code execution as an unprivileged backend service account on the appliance to escalate to root and run arbitrary commands with the highest privileges. Exploitation requires existing local access to that service account. | ||||
| CVE-2026-102111 | 1 Kiteworks | 1 Core | 2026-10-01 | 4.9 Medium |
| Kiteworks did not enforce the maximum permitted value for a configurable security-policy setting. An authenticated administrator could set this value outside its intended range so that the associated control never activated, while the control continued to appear enabled in the administrative interface and audit log, allowing it to be silently rendered ineffective. | ||||
| CVE-2026-103541 | 1 Form Tools | 1 Form Tools | 2026-10-01 | 6.3 Medium |
| A vulnerability was detected in formtools.org Form Tools up to 3.1.1. This issue affects the function Files::uploadFile of the file global/code/actions.php of the component Ajax Handler. The manipulation results in unrestricted upload. It is possible to launch the attack remotely. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet. | ||||
| CVE-2026-67075 | 2026-10-01 | 6.5 Medium | ||
| HCL Digital Experience is affected by improper input sanitation. This can result in HTML injection which could be leveraged in content spoofing from a trusted domain. Apply HCL Digital Experience 9.5 CF238 or later to address this. | ||||
| CVE-2026-79403 | 1 Kilo-org | 1 Kilocode | 2026-10-01 | 8.4 High |
| An issue in Kilo Code before v7.4.1 allows a local attacker to execute arbitrary code via the permission/allow-everything endpoint | ||||
| CVE-2026-100269 | 1 Jetbrains | 1 Youtrack | 2026-10-01 | 4.3 Medium |
| In JetBrains YouTrack before 2026.2.19197 helpdesk project's Authorized Reporters list could be bypassed | ||||
| CVE-2026-100273 | 1 Jetbrains | 1 Youtrack | 2026-10-01 | 8.2 High |
| In JetBrains YouTrack before 2026.2.19197 authorisation bypass in the scripts debugger allowed arbitrary code execution | ||||
| CVE-2026-47500 | 1 Nvidia | 7 Geforce, Guest Driver, Nvs and 4 more | 2026-10-01 | 7.8 High |
| NVIDIA GPU Display Driver for Windows and Linux contains a vulnerability in the kernel mode layer where improper cleanup of reference counts during error paths could lead to a use-after-free condition. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering. | ||||
| CVE-2026-102110 | 1 Kiteworks | 1 Core | 2026-10-01 | 5.9 Medium |
| An endpoint used during initial appliance setup did not require authentication and did not correctly enforce its intended state precondition, so during the initial activation window an unauthenticated network attacker could repeatedly re-trigger the privileged activation process. This could disrupt setup and leave the appliance in an incompletely configured state. The issue is only reachable while an appliance is being activated for the first time and not yet fully configured. | ||||