Export limit exceeded: 36461 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1420 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-63282 | 2026-11-10 | 6.5 Medium | ||
| Improper shell quote escaping when processing user-controlled input, potentially allowing command injection, which could lead to privilege escalation. | ||||
| CVE-2026-14543 | 2026-11-10 | 3.9 Low | ||
| The VAPIX Edge storage API, enabling the escalation of user privileges by circumventing filesystem isolation, granting unauthorized access to protected system resources. This flaw can only be exploited after authenticating with an admin-privileged service account. | ||||
| CVE-2026-14542 | 2026-11-10 | 6.7 Medium | ||
| The VAPIX SIP configuration API lacked sufficient input validation, which could potentially lead to privilege escalation. This flaw can only be exploited after authenticating with an admin-privileged service account. | ||||
| CVE-2026-123011 | 1 Stmicroelectronics | 1 St-mems-android-linux-sensors-hal | 2026-11-09 | 4.2 Medium |
| STMicroelectronics st-mems-android-linux-sensors-hal before 7bdf334 does not check whether the allowed number of channels is exceeded. | ||||
| CVE-2026-120646 | 2026-11-09 | 7.5 High | ||
| CGI versions from 4.71 before 5.00 for Perl allow denial of service via a plain string dereferenced as a symbolic reference in uploadInfo. uploadInfo dereferences its argument and calls its filename method without checking that it is an upload filehandle. A plain string naming a defined global variable, such as the parameter value from ?upload=0, is treated as a symbolic reference, and the method call on it dies. | ||||
| CVE-2026-46350 | 1 Dcmjs-org | 1 Dcmjs | 2026-11-09 | 9.1 Critical |
| dcmjs is a JavaScript implementation of DICOM manipulation. Prior to 0.52.0, the DecimalString and IntegerString implementations in src/ValueRepresentation.js sanitize text with a permissive regular expression and pass the result to JavaScript's Number constructor without validating finiteness or the DICOM value-representation rules. Scientific notation overflow in a DS or IS field can produce positive or negative Infinity, while stripping alphabetic characters from signed infinity text can leave a sign-only string that converts to NaN. IntegerString also accepts exponent notation and values outside the DICOM signed 32-bit IS range. Applications that trust these parsed values can propagate invalid numbers into spatial geometry, display windowing, dose scaling, frame counts, rescaling, or volume reconstruction, causing incorrect calculations or disrupted processing. This issue is fixed in version 0.52.0. | ||||
| CVE-2026-70659 | 1 Leejet | 1 Stable-diffusion.cpp | 2026-11-09 | 7.8 High |
| stable-diffusion.cpp is a pure C/C++ library for running diffusion model (Stable Diffusion, Flux, Wan, Qwen Image, Z-Image, and more) inference. From master-742-1a13107 until master-763-4fcc6fe, IMatrixCollector::load_imatrix in src/runtime/imatrix.cpp reuses the values and counts vectors for entries with the same tensor name but resizes them only when they are empty. An untrusted .imatrix file can provide a small nval for the first entry and a larger nval for a second entry with the same name, causing the accumulation loop to write attacker-controlled floating-point and integer values beyond both heap buffers. Loading the file through the --imat-in conversion path can corrupt the heap or crash the process before a model is required. This issue is fixed in master-763-4fcc6fe. | ||||
| CVE-2025-36075 | 1 Ibm | 1 Safer Payments | 2026-11-09 | 5.3 Medium |
| IBM Safer Payments 6.4.0.00 through 6.4.2.11, 6.5.0.00 through 6.5.0.09, 6.6.0.00 through 6.6.0.07, 6.7.0.00 through 6.7.0.03, and 6.8.0.00 could allow an authenticated user to obtain sensitive information, caused by improper user input validation. By using a set of API requests the user could exploit this vulnerability to decrypt sensitive information. | ||||
| CVE-2026-123572 | 1 Hickory-dns | 1 Hickory-dns | 2026-11-09 | 7.5 High |
| Hickory-dns from 0.20.1 before 0.26.2 contains a denial of service vulnerability in the hickory-proto SVCB and HTTPS record presentation format parser, which panics on malformed alpn values. Attackers can supply untrusted zone files with unbalanced quotes, consecutive commas, or invalid escapes in alpn parameters to crash parsing processes. | ||||
| CVE-2024-5953 | 1 Redhat | 6 Directory Server, Directory Server E4s, Directory Server Eus and 3 more | 2026-11-07 | 5.7 Medium |
| A denial of service vulnerability was found in the 389-ds-base LDAP server. This issue may allow an authenticated user to cause a server denial of service while attempting to log in with a user with a malformed hash in their password. | ||||
| CVE-2026-48175 | 1 Samsung Semiconductor | 11 Exynos 1280, Exynos 1330, Exynos 1380 and 8 more | 2026-11-06 | 5.5 Medium |
| Processing a malformed RRC message leads to an out-of-bounds read, resulting in a denial-of-service condition. | ||||
| CVE-2026-3632 | 3 Gnome, Libsoup, Redhat | 4 Libsoup, Libsoup, Enterprise Linux and 1 more | 2026-11-06 | 3.9 Low |
| A flaw was found in libsoup, a library used by applications to send network requests. This vulnerability occurs because libsoup does not properly validate hostnames, allowing special characters to be injected into HTTP headers. A remote attacker could exploit this to perform HTTP smuggling, where they can send hidden, malicious requests alongside legitimate ones. In certain situations, this could lead to Server-Side Request Forgery (SSRF), enabling an attacker to force the server to make unauthorized requests to other internal or external systems. The impact is low, as SoupServer is not actually used in internet infrastructure. | ||||
| CVE-2025-8556 | 1 Redhat | 23 Acm, Advanced Cluster Security, Ceph Storage and 20 more | 2026-11-06 | 3.7 Low |
| A flaw was found in CIRCL's implementation of the FourQ elliptic curve. This vulnerability allows an attacker to compromise session security via low-order point injection and incorrect point validation during Diffie-Hellman key exchange. | ||||
| CVE-2026-15943 | 1 Redhat | 8 Build Keycloak, Build Of Keycloak, Data Grid and 5 more | 2026-11-06 | 5.5 Medium |
| A flaw was found in the Keycloak keycloak-services component, which handles the management of identity providers. The issue occurs when a delegated administrator updates an OIDC identity provider using a masked client secret sentinel value. Due to improper validation, Keycloak reuses the existing real secret even if security-sensitive fields like the token URL have been changed, allowing an attacker to redirect and capture the secret. | ||||
| CVE-2026-72428 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix stack slot index in nospec checks check_stack_write_fixed_off() computes the byte slot for a fixed-offset stack write as -off - 1, and records each written byte in slot_type[] with (slot - i) % BPF_REG_SIZE. The Spectre v4 sanitization pre-check uses slot_type[i] instead. For a 4-byte write at fp-8 after the lower half of fp-8 has been zeroed, the pre-check scans bytes 0..3 and sees STACK_ZERO while the actual write updates bytes 7..4. That can leave the second half-slot write without nospec_result even though the bytes being overwritten still require sanitization. Use the same slot index in the sanitization pre-check that the write path uses when updating slot_type[]. | ||||
| CVE-2026-68247 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 4.4 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/bios: range check LFP Data Block panel_type2 While the panel_type from LFP Data Block is range checked, panel_type2 is not. Add a few helpers for range checking, and use them to not only check panel_type2, but also improve clarity and correctness in the panel type selection. Discovered using AI-assisted static analysis confirmed by Intel Product Security. v2: - Fix commit message typo (Michał) - Add is_panel_type_pnp() (Ville) (cherry picked from commit c9ebe5d2f25729d6cfbbb1235d640bf67f9275df) | ||||
| CVE-2026-53317 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921: Place upper limit on station AID Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds. In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash. This crash was only seen on IFTYPE_AP interfaces, and the fix does not appear to have an effect on IFTYPE_STATION behavior. | ||||
| CVE-2026-53304 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scsi: sg: Resolve soft lockup issue when opening /dev/sgX The parameter def_reserved_size defines the default buffer size reserved for each Sg_fd and should be restricted to a range between 0 and 1,048,576 (see https://tldp.org/HOWTO/SCSI-Generic-HOWTO/proc.html). Although the function sg_proc_write_dressz enforces this limit, it is possible to bypass it by directly modifying the module parameter as shown below, which then causes a soft lockup: echo -1 > /sys/module/sg/parameters/def_reserved_size exec 4<> /dev/sg0 watchdog: BUG: soft lockup - CPU#5 stuck for 26 seconds! [bash:537] Modules loaded: CPU: 5 UID: 0 PID: 537 Command: bash, kernel version 6.19.0-rc3+ #134, PREEMPT disabled Hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS version 1.16.1-2.fc37 dated 04/01/2014 ... Call Trace: sg_build_reserve+0x5c/0xa0 sg_add_sfp+0x168/0x270 sg_open+0x16e/0x340 chrdev_open+0xbe/0x230 do_dentry_open+0x175/0x480 vfs_open+0x34/0xf0 do_open+0x265/0x3d0 path_openat+0x110/0x290 do_filp_open+0xc3/0x170 do_sys_openat2+0x71/0xe0 __x64_sys_openat+0x6d/0xa0 do_syscall_64+0x62/0x310 entry_SYSCALL_64_after_hwframe+0x76/0x7e The fix is to use module_param_cb to validate and reject invalid values assigned to def_reserved_size. | ||||
| CVE-2026-53283 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Bounds-check devid in __rlookup_amd_iommu() iommu_device_register() walks every device on the PCI bus via bus_for_each_dev() and calls amd_iommu_probe_device() for each. The inlined check_device() path computes the device's sbdf, calls rlookup_amd_iommu() to find the owning IOMMU, and only afterwards verifies devid <= pci_seg->last_bdf. __rlookup_amd_iommu() indexes rlookup_table[devid] with no bounds check of its own, so for a PCI device whose BDF is not described by the IVRS, the lookup reads past the end of the allocation before the caller's bounds check can run. This was harmless before commit e874c666b15b ("iommu/amd: Change rlookup, irq_lookup, and alias to use kvalloc()"): the table was a zeroed page-order allocation, so the over-read returned NULL and the caller's NULL check skipped the device. After that commit the table is a tight kvcalloc() and the over-read returns adjacent slab contents, which check_device() then dereferences as a struct amd_iommu *, causing a boot-time GPF. Seen on Google Compute Engine ct6e VMs, where the virtualized IVRS describes only the four TPU endpoints 00:04.0-07.0; the gVNIC at 00:08.0 (devid 0x40) indexes 56 bytes past the 456-byte allocation, into the adjacent kmalloc-512 slab object: pci 0000:00:04.0: Adding to iommu group 0 pci 0000:00:05.0: Adding to iommu group 1 pci 0000:00:06.0: Adding to iommu group 2 pci 0000:00:07.0: Adding to iommu group 3 Oops: general protection fault, probably for non-canonical address 0x3a64695f78746382: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.18.22 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 12/06/2025 RIP: 0010:amd_iommu_probe_device+0x54/0x3a0 Call Trace: __iommu_probe_device+0x107/0x520 probe_iommu_group+0x29/0x50 bus_for_each_dev+0x7e/0xe0 iommu_device_register+0xc9/0x240 iommu_go_to_state+0x9c0/0x1c60 amd_iommu_init+0x14/0x40 pci_iommu_init+0x16/0x60 do_one_initcall+0x47/0x2f0 Guard the array access in __rlookup_amd_iommu(). With the fix applied on 6.18.22, the gVNIC at 00:08.0 is skipped cleanly and the VM boots. | ||||
| CVE-2026-53245 | 1 Linux | 1 Linux Kernel | 2026-11-06 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net/802/mrp: fix vector attribute parsing in mrp_pdu_parse_vecattr In mrp_pdu_parse_vecattr(), vector attribute events are encoded three per byte and valen tracks the number of events left to process. The parser decrements valen after processing the first and second events from each event byte, but not after processing the third one. When valen is exactly a multiple of three, the loop continues after the last valid event and consumes the next byte as a new event byte, applying a spurious event to the MRP applicant state. Additionally, when valen is zero the parser unconditionally consumes attrlen bytes as FirstValue and advances the offset, even though per IEEE 802.1ak a VectorAttribute with only a LeaveAllEvent has valen of zero and no FirstValue or Vector fields. This corrupts the offset for subsequent PDU parsing. Also, when valen exceeds three the loop crosses byte boundaries but the attribute value is not incremented between the last event of one byte and the first event of the next. This causes the first event of the next byte to use the same attribute value as the third event rather than the next consecutive value. Decrement valen after processing the third event, skip FirstValue consumption when valen is zero, and increment the attribute value at the end of each loop iteration. | ||||