Export limit exceeded: 75830 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (75830 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-23162 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/nvm: Fix double-free on aux add failure After a successful auxiliary_device_init(), aux_dev->dev.release (xe_nvm_release_dev()) is responsible for the kfree(nvm). When there is failure with auxiliary_device_add(), driver will call auxiliary_device_uninit(), which call put_device(). So that the .release callback will be triggered to free the memory associated with the auxiliary_device. Move the kfree(nvm) into the auxiliary_device_init() failure path and remove the err goto path to fix below error. " [ 13.232905] ================================================================== [ 13.232911] BUG: KASAN: double-free in xe_nvm_init+0x751/0xf10 [xe] [ 13.233112] Free of addr ffff888120635000 by task systemd-udevd/273 [ 13.233120] CPU: 8 UID: 0 PID: 273 Comm: systemd-udevd Not tainted 6.19.0-rc2-lgci-xe-kernel+ #225 PREEMPT(voluntary) ... [ 13.233125] Call Trace: [ 13.233126] <TASK> [ 13.233127] dump_stack_lvl+0x7f/0xc0 [ 13.233132] print_report+0xce/0x610 [ 13.233136] ? kasan_complete_mode_report_info+0x5d/0x1e0 [ 13.233139] ? xe_nvm_init+0x751/0xf10 [xe] ... " v2: drop err goto path. (Alexander) (cherry picked from commit a3187c0c2bbd947ffff97f90d077ac88f9c2a215) | ||||
| CVE-2026-25750 | 2 Langchain, Langchain-ai | 2 Langsmith, Helm | 2026-03-18 | 8.1 High |
| Langchain Helm Charts are Helm charts for deploying Langchain applications on Kubernetes. Prior to langchain-ai/helm version 0.12.71, a URL parameter injection vulnerability existed in LangSmith Studio that could allow unauthorized access to user accounts through stolen authentication tokens. The vulnerability affected both LangSmith Cloud and self-hosted deployments. Authenticated LangSmith users who clicked on a specially crafted malicious link would have their bearer token, user ID, and workspace ID transmitted to an attacker-controlled server. With this stolen token, an attacker could impersonate the victim and access any LangSmith resources or perform any actions the user was authorized to perform within their workspace. The attack required social engineering (phishing, malicious links in emails or chat applications) to convince users to click the crafted URL. The stolen tokens expired after 5 minutes, though repeated attacks against the same user were possible if they could be convinced to click malicious links multiple times. The fix in version 0.12.71 implements validation requiring user-defined allowed origins for the baseUrl parameter, preventing tokens from being sent to unauthorized servers. No known workarounds are available. Self-hosted customers must upgrade to the patched version. | ||||
| CVE-2026-23156 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: efivarfs: fix error propagation in efivar_entry_get() efivar_entry_get() always returns success even if the underlying __efivar_entry_get() fails, masking errors. This may result in uninitialized heap memory being copied to userspace in the efivarfs_file_read() path. Fix it by returning the error from __efivar_entry_get(). | ||||
| CVE-2026-25546 | 1 Coding-solo | 2 Godot-mcp, Godot Mcp | 2026-03-18 | 7.8 High |
| Godot MCP is a Model Context Protocol (MCP) server for interacting with the Godot game engine. Prior to version 0.1.1, a command injection vulnerability in godot-mcp allows remote code execution. The executeOperation function passed user-controlled input (e.g., projectPath) directly to exec(), which spawns a shell. An attacker could inject shell metacharacters like $(command) or &calc to execute arbitrary commands with the privileges of the MCP server process. This affects any tool that accepts projectPath, including create_scene, add_node, load_sprite, and others. This issue has been patched in version 0.1.1. | ||||
| CVE-2026-25536 | 2 Lfprojects, Modelcontextprotocol | 2 Mcp Typescript Sdk, Typescript-sdk | 2026-03-18 | 7.1 High |
| MCP TypeScript SDK is the official TypeScript SDK for Model Context Protocol servers and clients. From version 1.10.0 to 1.25.3, cross-client response data leak when a single McpServer/Server and transport instance is reused across multiple client connections, most commonly in stateless StreamableHTTPServerTransport deployments. This issue has been patched in version 1.26.0. | ||||
| CVE-2026-23158 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: gpio: virtuser: fix UAF in configfs release path The gpio-virtuser configfs release path uses guard(mutex) to protect the device structure. However, the device is freed before the guard cleanup runs, causing mutex_unlock() to operate on freed memory. Specifically, gpio_virtuser_device_config_group_release() destroys the mutex and frees the device while still inside the guard(mutex) scope. When the function returns, the guard cleanup invokes mutex_unlock(&dev->lock), resulting in a slab use-after-free. Limit the mutex lifetime by using a scoped_guard() only around the activation check, so that the lock is released before mutex_destroy() and kfree() are called. | ||||
| CVE-2026-23076 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: ctxfi: Fix potential OOB access in audio mixer handling In the audio mixer handling code of ctxfi driver, the conf field is used as a kind of loop index, and it's referred in the index callbacks (amixer_index() and sum_index()). As spotted recently by fuzzers, the current code causes OOB access at those functions. | UBSAN: array-index-out-of-bounds in /build/reproducible-path/linux-6.17.8/sound/pci/ctxfi/ctamixer.c:347:48 | index 8 is out of range for type 'unsigned char [8]' After the analysis, the cause was found to be the lack of the proper (re-)initialization of conj field. This patch addresses those OOB accesses by adding the proper initializations of the loop indices. | ||||
| CVE-2026-23078 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ALSA: scarlett2: Fix buffer overflow in config retrieval The scarlett2_usb_get_config() function has a logic error in the endianness conversion code that can cause buffer overflows when count > 1. The code checks `if (size == 2)` where `size` is the total buffer size in bytes, then loops `count` times treating each element as u16 (2 bytes). This causes the loop to access `count * 2` bytes when the buffer only has `size` bytes allocated. Fix by checking the element size (config_item->size) instead of the total buffer size. This ensures the endianness conversion matches the actual element type. | ||||
| CVE-2026-23083 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: fou: Don't allow 0 for FOU_ATTR_IPPROTO. fou_udp_recv() has the same problem mentioned in the previous patch. If FOU_ATTR_IPPROTO is set to 0, skb is not freed by fou_udp_recv() nor "resubmit"-ted in ip_protocol_deliver_rcu(). Let's forbid 0 for FOU_ATTR_IPPROTO. | ||||
| CVE-2026-23897 | 1 Apollographql | 2 Apollo Explorer, Apollo Server | 2026-03-18 | 7.5 High |
| Apollo Server is an open-source, spec-compliant GraphQL server that's compatible with any GraphQL client, including Apollo Client. In versions from 2.0.0 to 3.13.0, 4.2.0 to before 4.13.0, and 5.0.0 to before 5.4.0, the default configuration of startStandaloneServer from @apollo/server/standalone is vulnerable to denial of service (DoS) attacks through specially crafted request bodies with exotic character set encodings. This issue does not affect users that use @apollo/server as a dependency for integration packages, like @as-integrations/express5 or @as-integrations/next, only direct usage of startStandaloneServer. | ||||
| CVE-2025-62847 | 2 Qnap, Qnap Systems Inc. | 4 Qts, Quts Hero, Qts and 1 more | 2026-03-18 | 7.5 High |
| An improper neutralization of argument delimiters in a command vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to alter execution logic. We have already fixed the vulnerability in the following versions: QTS 5.2.7.3297 build 20251024 and later QuTS hero h5.2.7.3297 build 20251024 and later QuTS hero h5.3.1.3292 build 20251024 and later | ||||
| CVE-2026-28676 | 1 Opensift | 1 Opensift | 2026-03-18 | 8.8 High |
| OpenSift is an AI study tool that sifts through large datasets using semantic search and generative AI. Prior to version 1.6.3-alpha, multiple storage helpers used path construction patterns that did not uniformly enforce base-directory containment. This created path-injection risk in file read/write/delete flows if malicious path-like values were introduced. This issue has been patched in version 1.6.3-alpha. | ||||
| CVE-2026-28677 | 1 Opensift | 1 Opensift | 2026-03-18 | 8.2 High |
| OpenSift is an AI study tool that sifts through large datasets using semantic search and generative AI. Prior to version 1.6.3-alpha, the URL ingest pipeline accepted user-controlled remote URLs with incomplete destination restrictions. Although private/local host checks existed, missing restrictions for credentialed URLs, non-standard ports, and cross-host redirects left SSRF-class abuse paths in non-localhost deployments. This issue has been patched in version 1.6.3-alpha. | ||||
| CVE-2024-9675 | 2 Buildah Project, Redhat | 21 Buildah, Enterprise Linux, Enterprise Linux Eus and 18 more | 2026-03-18 | 7.8 High |
| A vulnerability was found in Buildah. Cache mounts do not properly validate that user-specified paths for the cache are within our cache directory, allowing a `RUN` instruction in a Container file to mount an arbitrary directory from the host (read/write) into the container as long as those files can be accessed by the user running Buildah. | ||||
| CVE-2026-3094 | 1 Deltaww | 1 Cncsoft-g2 | 2026-03-18 | 7.8 High |
| Delta Electronics CNCSoft-G2 lacks proper validation of the user-supplied file. If a user opens a malicious file, an attacker can leverage this vulnerability to execute code in the context of the current process. | ||||
| CVE-2025-47728 | 2 Delta Electronics, Deltaww | 2 Cncsoft-g2, Cncsoft-g2 | 2026-03-18 | 7.3 High |
| Delta Electronics CNCSoft-G2 lacks proper validation of the user-supplied file. If a user opens a malicious file, an attacker can leverage this vulnerability to execute code in the context of the current process. | ||||
| CVE-2025-58317 | 2 Delta Electronics, Deltaww | 2 Cncsoft-g2, Cncsoft-g2 | 2026-03-18 | 7.8 High |
| Delta Electronics CNCSoft-G2 lacks proper validation of the user-supplied file. If a user opens a malicious file, an attacker can leverage this vulnerability to execute code in the context of the current process. | ||||
| CVE-2025-62848 | 2 Qnap, Qnap Systems Inc. | 4 Qts, Quts Hero, Qts and 1 more | 2026-03-18 | 7.5 High |
| A NULL pointer dereference vulnerability has been reported to affect several QNAP operating system versions. The remote attackers can then exploit the vulnerability to launch a denial-of-service (DoS) attack. We have already fixed the vulnerability in the following versions: QTS 5.2.7.3297 build 20251024 and later QuTS hero h5.2.7.3297 build 20251024 and later QuTS hero h5.3.1.3292 build 20251024 and later | ||||
| CVE-2024-5037 | 1 Redhat | 4 Logging, Openshift, Openshift Container Platform and 1 more | 2026-03-18 | 7.5 High |
| A flaw was found in OpenShift's Telemeter. If certain conditions are in place, an attacker can use a forged token to bypass the issue ("iss") check during JSON web token (JWT) authentication. | ||||
| CVE-2025-71201 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early read unlock of page with EOF in middle The read result collection for buffered reads seems to run ahead of the completion of subrequests under some circumstances, as can be seen in the following log snippet: 9p_client_res: client 18446612686390831168 response P9_TREAD tag 0 err 0 ... netfs_sreq: R=00001b55[1] DOWN TERM f=192 s=0 5fb2/5fb2 s=5 e=0 ... netfs_collect_folio: R=00001b55 ix=00004 r=4000-5000 t=4000/5fb2 netfs_folio: i=157f3 ix=00004-00004 read-done netfs_folio: i=157f3 ix=00004-00004 read-unlock netfs_collect_folio: R=00001b55 ix=00005 r=5000-5fb2 t=5000/5fb2 netfs_folio: i=157f3 ix=00005-00005 read-done netfs_folio: i=157f3 ix=00005-00005 read-unlock ... netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=c netfs_collect_stream: R=00001b55[0:] cto=5fb2 frn=ffffffff netfs_collect_state: R=00001b55 col=5fb2 cln=6000 n=8 ... netfs_sreq: R=00001b55[2] ZERO SUBMT f=000 s=5fb2 0/4e s=0 e=0 netfs_sreq: R=00001b55[2] ZERO TERM f=102 s=5fb2 4e/4e s=5 e=0 The 'cto=5fb2' indicates the collected file pos we've collected results to so far - but we still have 0x4e more bytes to go - so we shouldn't have collected folio ix=00005 yet. The 'ZERO' subreq that clears the tail happens after we unlock the folio, allowing the application to see the uncleared tail through mmap. The problem is that netfs_read_unlock_folios() will unlock a folio in which the amount of read results collected hits EOF position - but the ZERO subreq lies beyond that and so happens after. Fix this by changing the end check to always be the end of the folio and never the end of the file. In the future, I should look at clearing to the end of the folio here rather than adding a ZERO subreq to do this. On the other hand, the ZERO subreq can run in parallel with an async READ subreq. Further, the ZERO subreq may still be necessary to, say, handle extents in a ceph file that don't have any backing store and are thus implicitly all zeros. This can be reproduced by creating a file, the size of which doesn't align to a page boundary, e.g. 24998 (0x5fb2) bytes and then doing something like: xfs_io -c "mmap -r 0 0x6000" -c "madvise -d 0 0x6000" \ -c "mread -v 0 0x6000" /xfstest.test/x The last 0x4e bytes should all be 00, but if the tail hasn't been cleared yet, you may see rubbish there. This can be reproduced with kafs by modifying the kernel to disable the call to netfs_read_subreq_progress() and to stop afs_issue_read() from doing the async call for NETFS_READAHEAD. Reproduction can be made easier by inserting an mdelay(100) in netfs_issue_read() for the ZERO-subreq case. AFS and CIFS are normally unlikely to show this as they dispatch READ ops asynchronously, which allows the ZERO-subreq to finish first. 9P's READ op is completely synchronous, so the ZERO-subreq will always happen after. It isn't seen all the time, though, because the collection may be done in a worker thread. | ||||