Vulnerabilities (CVE)

Filtered by NVD-CWE-noinfo
Total 35967 CVE
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2025-24106 1 Apple 1 Macos 2026-06-17 N/A 5.5 MEDIUM
This issue was addressed with additional entitlement checks. This issue is fixed in macOS Sequoia 15.3, macOS Sonoma 14.7.3, macOS Ventura 13.7.3. An app may be able to cause unexpected system termination.
CVE-2025-24100 1 Apple 1 Macos 2026-06-17 N/A 3.3 LOW
A logic issue was addressed with improved restrictions. This issue is fixed in macOS Sequoia 15.3, macOS Sonoma 14.7.3, macOS Ventura 13.7.3. An app may be able to access information about a user's contacts.
CVE-2025-24096 1 Apple 1 Macos 2026-06-17 N/A 5.5 MEDIUM
This issue was addressed through improved state management. This issue is fixed in macOS Sequoia 15.3. A malicious app may be able to access arbitrary files.
CVE-2025-24086 1 Apple 6 Ipados, Iphone Os, Macos and 3 more 2026-06-17 N/A 5.5 MEDIUM
The issue was addressed with improved memory handling. This issue is fixed in iOS 18.3 and iPadOS 18.3, iPadOS 17.7.4, macOS Sequoia 15.3, macOS Sonoma 14.7.3, macOS Ventura 13.7.3, tvOS 18.3, visionOS 2.3, watchOS 11.3. Processing an image may lead to a denial-of-service.
CVE-2025-24036 1 Microsoft 1 Autoupdate 2026-06-17 N/A 7.0 HIGH
Microsoft AutoUpdate (MAU) Elevation of Privilege Vulnerability
CVE-2025-23385 1 Jetbrains 4 Dottrace, Etw Host Service, Resharper and 1 more 2026-06-17 N/A 7.8 HIGH
In JetBrains ReSharper before 2024.3.4, 2024.2.8, and 2024.1.7, Rider before 2024.3.4, 2024.2.8, and 2024.1.7, dotTrace before 2024.3.4, 2024.2.8, and 2024.1.7, ETW Host Service before 16.43, Local Privilege Escalation via the ETW Host Service was possible
CVE-2025-23375 1 Dell 1 Powerprotect Data Manager 2026-06-17 N/A 7.8 HIGH
Dell PowerProtect Data Manager Reporting, version(s) 19.17, contain(s) an Incorrect Use of Privileged APIs vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Elevation of privileges.
CVE-2025-23367 1 Redhat 2 Jboss Enterprise Application Platform, Wildfly 2026-06-17 N/A 6.5 MEDIUM
A flaw was found in the Wildfly Server Role Based Access Control (RBAC) provider. When authorization to control management operations is secured using the Role Based Access Control provider, a user without the required privileges can suspend or resume the server. A user with a Monitor or Auditor role is supposed to have only read access permissions and should not be able to suspend the server. The vulnerability is caused by the Suspend and Resume handlers not performing authorization checks to validate whether the current user has the required permissions to proceed with the action.
CVE-2025-23336 3 Linux, Microsoft, Nvidia 3 Linux Kernel, Windows, Triton Inference Server 2026-06-17 N/A 4.4 MEDIUM
NVIDIA Triton Inference Server for Windows and Linux contains a vulnerability where an attacker could cause a denial of service by loading a misconfigured model. A successful exploit of this vulnerability might lead to denial of service.
CVE-2025-23243 2 Linux, Nvidia 2 Linux Kernel, Riva 2026-06-17 N/A 6.5 MEDIUM
NVIDIA Riva contains a vulnerability where a user could cause an improper access control issue. A successful exploit of this vulnerability might lead to data tampering or denial of service.
CVE-2025-23242 2 Linux, Nvidia 2 Linux Kernel, Riva 2026-06-17 N/A 7.3 HIGH
NVIDIA Riva contains a vulnerability where a user could cause an improper access control issue. A successful exploit of this vulnerability might lead to escalation of privileges, data tampering, denial of service, or information disclosure.
CVE-2025-23212 1 Tandoor 1 Recipes 2026-06-17 N/A 7.7 HIGH
Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. The external storage feature allows any user to enumerate the name and content of files on the server. This vulnerability is fixed in 1.5.28.
CVE-2025-23208 1 Zotregistry 1 Zot 2026-06-17 N/A 7.3 HIGH
zot is a production-ready vendor-neutral OCI image registry. The group data stored for users in the boltdb database (meta.db) is an append-list so group revocations/removals are ignored in the API. SetUserGroups is alled on login, but instead of replacing the group memberships, they are appended. This may be due to some conflict with the group definitions in the config file, but that wasn't obvious to me if it were the case. Any Zot configuration that relies on group-based authorization will not respect group remove/revocation by an IdP. This issue has been addressed in version 2.1.2. All users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2025-23184 1 Apache 1 Cxf 2026-06-17 N/A 5.9 MEDIUM
A potential denial of service vulnerability is present in versions of Apache CXF before 3.5.10, 3.6.5 and 4.0.6. In some edge cases, the CachedOutputStream instances may not be closed and, if backed by temporary files, may fill up the file system (it applies to servers and clients).
CVE-2025-23162 1 Linux 1 Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: drm/xe/vf: Don't try to trigger a full GT reset if VF VFs don't have access to the GDRST(0x941c) register that driver uses to reset a GT. Attempt to trigger a reset using debugfs: $ cat /sys/kernel/debug/dri/0000:00:02.1/gt0/force_reset or due to a hang condition detected by the driver leads to: [ ] xe 0000:00:02.1: [drm] GT0: trying reset from force_reset [xe] [ ] xe 0000:00:02.1: [drm] GT0: reset queued [ ] xe 0000:00:02.1: [drm] GT0: reset started [ ] ------------[ cut here ]------------ [ ] xe 0000:00:02.1: [drm] GT0: VF is trying to write 0x1 to an inaccessible register 0x941c+0x0 [ ] WARNING: CPU: 3 PID: 3069 at drivers/gpu/drm/xe/xe_gt_sriov_vf.c:996 xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] RIP: 0010:xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] Call Trace: [ ] <TASK> [ ] ? show_regs+0x6c/0x80 [ ] ? __warn+0x93/0x1c0 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? report_bug+0x182/0x1b0 [ ] ? handle_bug+0x6e/0xb0 [ ] ? exc_invalid_op+0x18/0x80 [ ] ? asm_exc_invalid_op+0x1b/0x20 [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_sriov_vf_write32+0xc6/0x580 [xe] [ ] ? xe_gt_tlb_invalidation_reset+0xef/0x110 [xe] [ ] ? __mutex_unlock_slowpath+0x41/0x2e0 [ ] xe_mmio_write32+0x64/0x150 [xe] [ ] do_gt_reset+0x2f/0xa0 [xe] [ ] gt_reset_worker+0x14e/0x1e0 [xe] [ ] process_one_work+0x21c/0x740 [ ] worker_thread+0x1db/0x3c0 Fix that by sending H2G VF_RESET(0x5507) action instead.
CVE-2025-23154 1 Linux 1 Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: io_uring/net: fix io_req_post_cqe abuse by send bundle [ 114.987980][ T5313] WARNING: CPU: 6 PID: 5313 at io_uring/io_uring.c:872 io_req_post_cqe+0x12e/0x4f0 [ 114.991597][ T5313] RIP: 0010:io_req_post_cqe+0x12e/0x4f0 [ 115.001880][ T5313] Call Trace: [ 115.002222][ T5313] <TASK> [ 115.007813][ T5313] io_send+0x4fe/0x10f0 [ 115.009317][ T5313] io_issue_sqe+0x1a6/0x1740 [ 115.012094][ T5313] io_wq_submit_work+0x38b/0xed0 [ 115.013223][ T5313] io_worker_handle_work+0x62a/0x1600 [ 115.013876][ T5313] io_wq_worker+0x34f/0xdf0 As the comment states, io_req_post_cqe() should only be used by multishot requests, i.e. REQ_F_APOLL_MULTISHOT, which bundled sends are not. Add a flag signifying whether a request wants to post multiple CQEs. Eventually REQ_F_APOLL_MULTISHOT should imply the new flag, but that's left out for simplicity.
CVE-2025-23153 1 Linux 1 Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: arm/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch() Fix a silly bug where an array was used outside of its scope.
CVE-2025-23152 1 Linux 1 Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: arm64/crc-t10dif: fix use of out-of-scope array in crc_t10dif_arch() Fix a silly bug where an array was used outside of its scope.
CVE-2025-23149 1 Linux 1 Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: tpm: do not start chip while suspended Checking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can lead to a spurious tpm_chip_start() call: [35985.503771] i2c i2c-1: Transfer while suspended [35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810 [35985.503802] Modules linked in: [35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G W 6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f [35985.503814] Tainted: [W]=WARN [35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023 [35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810 [35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5 [35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246 [35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000 [35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001 [35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820 [35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120 [35985.503846] FS: 0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000 [35985.503849] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0 [35985.503855] Call Trace: [35985.503859] <TASK> [35985.503863] ? __warn+0xd4/0x260 [35985.503868] ? __i2c_transfer+0xbe/0x810 [35985.503874] ? report_bug+0xf3/0x210 [35985.503882] ? handle_bug+0x63/0xb0 [35985.503887] ? exc_invalid_op+0x16/0x50 [35985.503892] ? asm_exc_invalid_op+0x16/0x20 [35985.503904] ? __i2c_transfer+0xbe/0x810 [35985.503913] tpm_cr50_i2c_transfer_message+0x24/0xf0 [35985.503920] tpm_cr50_i2c_read+0x8e/0x120 [35985.503928] tpm_cr50_request_locality+0x75/0x170 [35985.503935] tpm_chip_start+0x116/0x160 [35985.503942] tpm_try_get_ops+0x57/0x90 [35985.503948] tpm_find_get_ops+0x26/0xd0 [35985.503955] tpm_get_random+0x2d/0x80 Don't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless TPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in such a failure case.
CVE-2025-23144 2 Debian, Linux 2 Debian Linux, Linux Kernel 2026-06-17 N/A 5.5 MEDIUM
In the Linux kernel, the following vulnerability has been resolved: backlight: led_bl: Hold led_access lock when calling led_sysfs_disable() Lockdep detects the following issue on led-backlight removal: [ 142.315935] ------------[ cut here ]------------ [ 142.315954] WARNING: CPU: 2 PID: 292 at drivers/leds/led-core.c:455 led_sysfs_enable+0x54/0x80 ... [ 142.500725] Call trace: [ 142.503176] led_sysfs_enable+0x54/0x80 (P) [ 142.507370] led_bl_remove+0x80/0xa8 [led_bl] [ 142.511742] platform_remove+0x30/0x58 [ 142.515501] device_remove+0x54/0x90 ... Indeed, led_sysfs_enable() has to be called with the led_access lock held. Hold the lock when calling led_sysfs_disable().