Export limit exceeded: 395931 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (3198 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-0481 | 1 Amd | 6 Instinct Mi210, Instinct Mi250, Instinct Mi300a and 3 more | 2026-05-15 | N/A |
| Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability | ||||
| CVE-2026-44005 | 2 Patriksimek, Vm2 Project | 2 Vm2, Vm2 | 2026-05-15 | 10 Critical |
| vm2 is an open source vm/sandbox for Node.js. From 3.9.6 to 3.10.5, vm2's bridge exposes mutable proxies for real host-realm intrinsic prototypes and then forwards sandbox writes into the underlying host objects with otherReflectSet() and otherReflectDefineProperty(), which lets attacker-controlled JavaScript running in a default VM or inherited NodeVM mutate shared host Object.prototype, Array.prototype, and Function.prototype from inside the sandbox This vulnerability is fixed in 3.11.0. | ||||
| CVE-2026-43291 | 1 Linux | 1 Linux Kernel | 2026-05-14 | 8.3 High |
| In the Linux kernel, the following vulnerability has been resolved: net: nfc: nci: Fix parameter validation for packet data Since commit 9c328f54741b ("net: nfc: nci: Add parameter validation for packet data") communication with nci nfc chips is not working any more. The mentioned commit tries to fix access of uninitialized data, but failed to understand that in some cases the data packet is of variable length and can therefore not be compared to the maximum packet length given by the sizeof(struct). | ||||
| CVE-2026-43097 | 1 Linux | 1 Linux Kernel | 2026-05-14 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: PCI: hv: Fix double ida_free in hv_pci_probe error path If hv_pci_probe() fails after storing the domain number in hbus->bridge->domain_nr, there is a call to free this domain_nr via pci_bus_release_emul_domain_nr(), however, during cleanup, the bridge release callback pci_release_host_bridge_dev() also frees the domain_nr causing ida_free to be called on same ID twice and triggering following warning: ida_free called for id=28971 which is not allocated. WARNING: lib/idr.c:594 at ida_free+0xdf/0x160, CPU#0: kworker/0:2/198 Call Trace: pci_bus_release_emul_domain_nr+0x17/0x20 pci_release_host_bridge_dev+0x4b/0x60 device_release+0x3b/0xa0 kobject_put+0x8e/0x220 devm_pci_alloc_host_bridge_release+0xe/0x20 devres_release_all+0x9a/0xd0 device_unbind_cleanup+0x12/0xa0 really_probe+0x1c5/0x3f0 vmbus_add_channel_work+0x135/0x1a0 Fix this by letting pci core handle the free domain_nr and remove the explicit free called in pci-hyperv driver. | ||||
| CVE-2025-71299 | 1 Linux | 1 Linux Kernel | 2026-05-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: spi: cadence-quadspi: Parse DT for flashes with the rest of the DT parsing The recent refactoring of where runtime PM is enabled done in commit f1eb4e792bb1 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") made the fact that when we do a pm_runtime_disable() in the error paths of probe() we can trigger a runtime disable which in turn results in duplicate clock disables. This is particularly likely to happen when there is missing or broken DT description for the flashes attached to the controller. Early on in the probe function we do a pm_runtime_get_noresume() since the probe function leaves the device in a powered up state but in the error path we can't assume that PM is enabled so we also manually disable everything, including clocks. This means that when runtime PM is active both it and the probe function release the same reference to the main clock for the IP, triggering warnings from the clock subsystem: [ 8.693719] clk:75:7 already disabled [ 8.693791] WARNING: CPU: 1 PID: 185 at /usr/src/kernel/drivers/clk/clk.c:1188 clk_core_disable+0xa0/0xb ... [ 8.694261] clk_core_disable+0xa0/0xb4 (P) [ 8.694272] clk_disable+0x38/0x60 [ 8.694283] cqspi_probe+0x7c8/0xc5c [spi_cadence_quadspi] [ 8.694309] platform_probe+0x5c/0xa4 Dealing with this issue properly is complicated by the fact that we don't know if runtime PM is active so can't tell if it will disable the clocks or not. We can, however, sidestep the issue for the flash descriptions by moving their parsing to when we parse the controller properties which also save us doing a bunch of setup which can never be used so let's do that. | ||||
| CVE-2026-44351 | 1 Nearform | 1 Fast-jwt | 2026-05-14 | 9.1 Critical |
| fast-jwt provides fast JSON Web Token (JWT) implementation. Prior to 6.2.4, a critical authentication-bypass vulnerability in fast-jwt's async key-resolver flow allows any unauthenticated attacker to forge arbitrary JWTs that are accepted as authentic. When the application's key resolver returns an empty string (''), for example via the common keys[decoded.header.kid] || '' JWKS-style fallback, fast-jwt converts it to a zero-length Buffer, hands it to crypto.createSecretKey, derives allowedAlgorithms = ['HS256','HS384','HS512'] from it, and then verifies the token's signature against an empty-key HMAC. The attacker simply computes HMAC-SHA256(key='', input='${header}.${payload}'), which Node accepts without complaint — and the verifier returns the attacker-chosen payload (sub, admin, scopes, etc.) as authentic. This vulnerability is fixed in 6.2.4. | ||||
| CVE-2026-45714 | 1 Cubecart | 1 Cubecart | 2026-05-14 | 9.1 Critical |
| CubeCart is an ecommerce software solution. Prior to 6.7.0, an Authenticated Server-Side Template Injection (SSTI) vulnerability exists in multiple modules of CubeCart (including Email Templates, Invoices, Documents, and Contact Forms). The application unsafely evaluates user-supplied input using the Smarty template engine without enabling Smarty Security Policies. This allows any authenticated user with administrative privileges to execute arbitrary operating system commands (RCE) on the server. This vulnerability is fixed in 6.7.0. | ||||
| CVE-2026-40618 | 1 F5 | 27 Big-ip, Big-ip Access Policy Manager, Big-ip Advanced Firewall Manager and 24 more | 2026-05-14 | 7.5 High |
| When an SSL profile is configured on a virtual server on BIG-IP Virtual Edition (VE) without Intel QuickAssist Technology (QAT) or on BIG-IP hardware platforms with the database variable crypto.hwacceleration set to disabled, undisclosed traffic can cause the Traffic Management Microkernel (TMM) to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated. | ||||
| CVE-2026-44377 | 1 Cubecart | 1 Cubecart | 2026-05-14 | 9.1 Critical |
| CubeCart is an ecommerce software solution. Prior to 6.7.0, an Authenticated Server-Side Template Injection (SSTI) vulnerability exists in multiple modules of CubeCart (including Email Templates and Documents). The application unsafely evaluates user-supplied input directly through the Smarty template engine. By leveraging this, an authenticated attacker with administrative privileges can bypass current restrictions and call native PHP functions within the templates, such as readgzfile() to read sensitive configuration files, or error_log() to write a malicious PHP web shell, ultimately achieving Information Disclosure and full Remote Code Execution (RCE). This vulnerability is fixed in 6.7.0. | ||||
| CVE-2026-44290 | 2 Protobuf, Protobufjs Project | 2 Protobuf, Protobufjs | 2026-05-14 | 7.5 High |
| protobufjs compiles protobuf definitions into JavaScript (JS) functions. Prior to 7.5.6 and 8.0.2, protobufjs allowed certain schema option paths to traverse through inherited object properties while applying options. A crafted protobuf schema or JSON descriptor could cause option handling to write to properties on global JavaScript constructors, corrupting process-wide built-in functionality. This vulnerability is fixed in 7.5.6 and 8.0.2. | ||||
| CVE-2026-8199 | 1 Mongodb | 2 Mongodb, Mongodb Server | 2026-05-13 | 6.5 Medium |
| An authenticated user can cause excess memory usage via bitwise match expression AST processing of $bitsAllSet, $bitsAnySet, $bitsAllClear, and $bitsAnyClear. This contributes to memory pressure and may lead to availability loss by OOM. This issue impacts MongoDB Server v7.0 versions prior to 7.0.34, v8.0 versions prior to 8.0.23, v8.2 versions prior to 8.2.9 and v8.3 versions prior to 8.3.2. | ||||
| CVE-2026-43158 | 1 Linux | 1 Linux Kernel | 2026-05-13 | 8.8 High |
| In the Linux kernel, the following vulnerability has been resolved: xfs: fix freemap adjustments when adding xattrs to leaf blocks xfs/592 and xfs/794 both trip this assertion in the leaf block freemap adjustment code after ~20 minutes of running on my test VMs: ASSERT(ichdr->firstused >= ichdr->count * sizeof(xfs_attr_leaf_entry_t) + xfs_attr3_leaf_hdr_size(leaf)); Upon enabling quite a lot more debugging code, I narrowed this down to fsstress trying to set a local extended attribute with namelen=3 and valuelen=71. This results in an entry size of 80 bytes. At the start of xfs_attr3_leaf_add_work, the freemap looks like this: i 0 base 448 size 0 rhs 448 count 46 i 1 base 388 size 132 rhs 448 count 46 i 2 base 2120 size 4 rhs 448 count 46 firstused = 520 where "rhs" is the first byte past the end of the leaf entry array. This is inconsistent -- the entries array ends at byte 448, but freemap[1] says there's free space starting at byte 388! By the end of the function, the freemap is in worse shape: i 0 base 456 size 0 rhs 456 count 47 i 1 base 388 size 52 rhs 456 count 47 i 2 base 2120 size 4 rhs 456 count 47 firstused = 440 Important note: 388 is not aligned with the entries array element size of 8 bytes. Based on the incorrect freemap, the name area starts at byte 440, which is below the end of the entries array! That's why the assertion triggers and the filesystem shuts down. How did we end up here? First, recall from the previous patch that the freemap array in an xattr leaf block is not intended to be a comprehensive map of all free space in the leaf block. In other words, it's perfectly legal to have a leaf block with: * 376 bytes in use by the entries array * freemap[0] has [base = 376, size = 8] * freemap[1] has [base = 388, size = 1500] * the space between 376 and 388 is free, but the freemap stopped tracking that some time ago If we add one xattr, the entries array grows to 384 bytes, and freemap[0] becomes [base = 384, size = 0]. So far, so good. But if we add a second xattr, the entries array grows to 392 bytes, and freemap[0] gets pushed up to [base = 392, size = 0]. This is bad, because freemap[1] hasn't been updated, and now the entries array and the free space claim the same space. The fix here is to adjust all freemap entries so that none of them collide with the entries array. Note that this fix relies on commit 2a2b5932db6758 ("xfs: fix attr leaf header freemap.size underflow") and the previous patch that resets zero length freemap entries to have base = 0. | ||||
| CVE-2026-43149 | 1 Linux | 1 Linux Kernel | 2026-05-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: wan/fsl_ucc_hdlc: Fix dma_free_coherent() in uhdlc_memclean() The priv->rx_buffer and priv->tx_buffer are alloc'd together as contiguous buffers in uhdlc_init() but freed as two buffers in uhdlc_memclean(). Change the cleanup to only call dma_free_coherent() once on the whole buffer. | ||||
| CVE-2026-43150 | 1 Linux | 1 Linux Kernel | 2026-05-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: perf/arm-cmn: Reject unsupported hardware configurations So far we've been fairly lax about accepting both unknown CMN models (at least with a warning), and unknown revisions of those which we do know, as although things do frequently change between releases, typically enough remains the same to be somewhat useful for at least some basic bringup checks. However, we also make assumptions of the maximum supported sizes and numbers of things in various places, and there's no guarantee that something new might not be bigger and lead to nasty array overflows. Make sure we only try to run on things that actually match our assumptions and so will not risk memory corruption. We have at least always failed on completely unknown node types, so update that error message for clarity and consistency too. | ||||
| CVE-2026-42050 | 1 Imagemagick | 1 Imagemagick | 2026-05-13 | 5.5 Medium |
| ImageMagick is free and open-source software used for editing and manipulating digital images. Prior to 7.1.2-21 and 6.9.13-46, a malicious MIFF file could trigger an overflow when a user opens it in the display tool and right-clicks a tile to invoke the Load / Update menu item. This vulnerability is fixed in 7.1.2-21 and 6.9.13-46. | ||||
| CVE-2026-42203 | 2 Berriai, Litellm | 2 Litellm, Litellm | 2026-05-13 | 8.8 High |
| LiteLLM is a proxy server (AI Gateway) to call LLM APIs in OpenAI (or native) format. From version 1.80.5 to before version 1.83.7, the POST /prompts/test endpoint accepted user-supplied prompt templates and rendered them without sandboxing. A crafted template could run arbitrary code inside the LiteLLM Proxy process. The endpoint only checks that the caller presents a valid proxy API key, so any authenticated user could reach it. Depending on how the proxy is deployed, this could expose secrets in the process environment (such as provider API keys or database credentials) and allow commands to be run on the host. This issue has been patched in version 1.83.7. | ||||
| CVE-2026-43169 | 1 Linux | 1 Linux Kernel | 2026-05-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/buddy: Prevent BUG_ON by validating rounded allocation When DRM_BUDDY_CONTIGUOUS_ALLOCATION is set, the requested size is rounded up to the next power-of-two via roundup_pow_of_two(). Similarly, for non-contiguous allocations with large min_block_size, the size is aligned up via round_up(). Both operations can produce a rounded size that exceeds mm->size, which later triggers BUG_ON(order > mm->max_order). Example scenarios: - 9G CONTIGUOUS allocation on 10G VRAM memory: roundup_pow_of_two(9G) = 16G > 10G - 9G allocation with 8G min_block_size on 10G VRAM memory: round_up(9G, 8G) = 16G > 10G Fix this by checking the rounded size against mm->size. For non-contiguous or range allocations where size > mm->size is invalid, return -EINVAL immediately. For contiguous allocations without range restrictions, allow the request to fall through to the existing __alloc_contig_try_harder() fallback. This ensures invalid user input returns an error or uses the fallback path instead of hitting BUG_ON. v2: (Matt A) - Add Fixes, Cc stable, and Closes tags for context | ||||
| CVE-2026-8159 | 2 Multiparty, Pillarjs | 2 Multiparty, Multiparty | 2026-05-13 | 7.5 High |
| multiparty@4.2.3 and lower versions are vulnerable to denial of service via regular expression backtracking in the Content-Disposition filename parameter parser. A crafted multipart upload with a long header value can cause regex matching to take seconds, blocking the event loop. Impact: any service accepting multipart uploads via multiparty is affected. Workarounds: limiting upload sizes at the proxy or gateway layer reduces but does not eliminate the attack surface, since a small header of around 8 KB is sufficient to trigger the vulnerable backtracking. Upgrade to multiparty@4.3.0 or higher. | ||||
| CVE-2026-8161 | 2 Multiparty, Pillarjs | 2 Multiparty, Multiparty | 2026-05-13 | 7.5 High |
| multiparty@4.2.3 and lower versions are vulnerable to denial of service via uncaught exception. By sending a multipart/form-data request with a field name that collides with an inherited Object.prototype property such as __proto__, constructor, or toString, the parser invokes .push() on the inherited prototype value rather than an array, throwing a TypeError that propagates as an uncaught exception and crashes the process. Impact: any service accepting multipart uploads via multiparty is affected. Workarounds: none. Upgrade to multiparty@4.3.0 or higher. | ||||
| CVE-2022-4988 | 1 Kmx | 1 Alien::freeimage | 2026-05-13 | 7.3 High |
| Alien::FreeImage versions through 1.001 for Perl contains several vulnerable libraries. Alien::FreeImage contains version 3.17.0 of the FreeImage library from 2017, which has known vulnerabilities such as CVE-2015-0852 and CVE-2025-65803. The library embeds other images libraries that also have known vulnerabilities. | ||||