Total
304758 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2025-41240 | 2025-07-25 | N/A | N/A | ||
Three Bitnami Helm charts mount Kubernetes Secrets under a predictable path (/opt/bitnami/*/secrets) that is located within the web server document root. In affected versions, this can lead to unauthenticated access to sensitive credentials via HTTP/S. A remote attacker could retrieve these secrets by accessing specific URLs if the application is exposed externally. The issue affects deployments using the default value of usePasswordFiles=true, which mounts secrets as files into the container filesystem. | |||||
CVE-2025-7959 | 2025-07-25 | N/A | 6.4 MEDIUM | ||
The Station Pro plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘width' and 'height’ parameter in all versions up to, and including, 2.4.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | |||||
CVE-2025-4411 | 2025-07-25 | N/A | 6.5 MEDIUM | ||
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Dataprom Informatics PACS-ACSS allows Cross-Site Scripting (XSS).This issue affects PACS-ACSS: before 16.05.2025. | |||||
CVE-2025-38402 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: idpf: return 0 size for RSS key if not supported Returning -EOPNOTSUPP from function returning u32 is leading to cast and invalid size value as a result. -EOPNOTSUPP as a size probably will lead to allocation fail. Command: ethtool -x eth0 It is visible on all devices that don't have RSS caps set. [ 136.615917] Call Trace: [ 136.615921] <TASK> [ 136.615927] ? __warn+0x89/0x130 [ 136.615942] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.615953] ? report_bug+0x164/0x190 [ 136.615968] ? handle_bug+0x58/0x90 [ 136.615979] ? exc_invalid_op+0x17/0x70 [ 136.615987] ? asm_exc_invalid_op+0x1a/0x20 [ 136.616001] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616016] ? __alloc_frozen_pages_noprof+0x322/0x330 [ 136.616028] __alloc_pages_noprof+0xe/0x20 [ 136.616038] ___kmalloc_large_node+0x80/0x110 [ 136.616072] __kmalloc_large_node_noprof+0x1d/0xa0 [ 136.616081] __kmalloc_noprof+0x32c/0x4c0 [ 136.616098] ? rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616105] rss_prepare_get.constprop.0+0xb9/0x170 [ 136.616114] ethnl_default_doit+0x107/0x3d0 [ 136.616131] genl_family_rcv_msg_doit+0x100/0x160 [ 136.616147] genl_rcv_msg+0x1b8/0x2c0 [ 136.616156] ? __pfx_ethnl_default_doit+0x10/0x10 [ 136.616168] ? __pfx_genl_rcv_msg+0x10/0x10 [ 136.616176] netlink_rcv_skb+0x58/0x110 [ 136.616186] genl_rcv+0x28/0x40 [ 136.616195] netlink_unicast+0x19b/0x290 [ 136.616206] netlink_sendmsg+0x222/0x490 [ 136.616215] __sys_sendto+0x1fd/0x210 [ 136.616233] __x64_sys_sendto+0x24/0x30 [ 136.616242] do_syscall_64+0x82/0x160 [ 136.616252] ? __sys_recvmsg+0x83/0xe0 [ 136.616265] ? syscall_exit_to_user_mode+0x10/0x210 [ 136.616275] ? do_syscall_64+0x8e/0x160 [ 136.616282] ? __count_memcg_events+0xa1/0x130 [ 136.616295] ? count_memcg_events.constprop.0+0x1a/0x30 [ 136.616306] ? handle_mm_fault+0xae/0x2d0 [ 136.616319] ? do_user_addr_fault+0x379/0x670 [ 136.616328] ? clear_bhb_loop+0x45/0xa0 [ 136.616340] ? clear_bhb_loop+0x45/0xa0 [ 136.616349] ? clear_bhb_loop+0x45/0xa0 [ 136.616359] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 136.616369] RIP: 0033:0x7fd30ba7b047 [ 136.616376] Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d bd d5 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44 [ 136.616381] RSP: 002b:00007ffde1796d68 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 136.616388] RAX: ffffffffffffffda RBX: 000055d7bd89f2a0 RCX: 00007fd30ba7b047 [ 136.616392] RDX: 0000000000000028 RSI: 000055d7bd89f3b0 RDI: 0000000000000003 [ 136.616396] RBP: 00007ffde1796e10 R08: 00007fd30bb4e200 R09: 000000000000000c [ 136.616399] R10: 0000000000000000 R11: 0000000000000202 R12: 000055d7bd89f340 [ 136.616403] R13: 000055d7bd89f3b0 R14: 000055d78943f200 R15: 0000000000000000 | |||||
CVE-2025-4395 | 2025-07-25 | N/A | N/A | ||
Medtronic MyCareLink Patient Monitor has a built-in user account with an empty password, which allows an attacker with physical access to log in with no password and access modify system functionality. This issue affects MyCareLink Patient Monitor models 24950 and 24952: before June 25, 2025 | |||||
CVE-2025-8132 | 2025-07-25 | N/A | N/A | ||
A vulnerability was found in yanyutao0402 ChanCMS up to 3.1.2. It has been rated as critical. Affected by this issue is the function delfile of the file app/extend/utils.js. The manipulation leads to path traversal. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 3.1.3 is able to address this issue. The name of the patch is c8a282bf02a62b59ec60b4699e91c51aff2ee9cd. It is recommended to upgrade the affected component. | |||||
CVE-2025-5254 | 2025-07-25 | N/A | 6.1 MEDIUM | ||
Improper Neutralization of Input During Web Page Generation (XSS or 'Cross-site Scripting') vulnerability in Kron Technologies Kron PAM allows Stored XSS.This issue affects Kron PAM: before 3.7. | |||||
CVE-2025-38382 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix iteration of extrefs during log replay At __inode_add_ref() when processing extrefs, if we jump into the next label we have an undefined value of victim_name.len, since we haven't initialized it before we did the goto. This results in an invalid memory access in the next iteration of the loop since victim_name.len was not initialized to the length of the name of the current extref. Fix this by initializing victim_name.len with the current extref's name length. | |||||
CVE-2025-45702 | 2025-07-25 | N/A | N/A | ||
SoftPerfect Pty Ltd Connection Quality Monitor v1.1 was discovered to store all credentials in plaintext. | |||||
CVE-2025-38364 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: maple_tree: fix MA_STATE_PREALLOC flag in mas_preallocate() Temporarily clear the preallocation flag when explicitly requesting allocations. Pre-existing allocations are already counted against the request through mas_node_count_gfp(), but the allocations will not happen if the MA_STATE_PREALLOC flag is set. This flag is meant to avoid re-allocating in bulk allocation mode, and to detect issues with preallocation calculations. The MA_STATE_PREALLOC flag should also always be set on zero allocations so that detection of underflow allocations will print a WARN_ON() during consumption. User visible effect of this flaw is a WARN_ON() followed by a null pointer dereference when subsequent requests for larger number of nodes is ignored, such as the vma merge retry in mmap_region() caused by drivers altering the vma flags (which happens in v6.6, at least) | |||||
CVE-2025-38420 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: wifi: carl9170: do not ping device which has failed to load firmware Syzkaller reports [1, 2] crashes caused by an attempts to ping the device which has failed to load firmware. Since such a device doesn't pass 'ieee80211_register_hw()', an internal workqueue managed by 'ieee80211_queue_work()' is not yet created and an attempt to queue work on it causes null-ptr-deref. [1] https://syzkaller.appspot.com/bug?extid=9a4aec827829942045ff [2] https://syzkaller.appspot.com/bug?extid=0d8afba53e8fb2633217 | |||||
CVE-2025-38423 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: ASoC: codecs: wcd9375: Fix double free of regulator supplies Driver gets regulator supplies in probe path with devm_regulator_bulk_get(), so should not call regulator_bulk_free() in error and remove paths to avoid double free. | |||||
CVE-2025-38406 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: wifi: ath6kl: remove WARN on bad firmware input If the firmware gives bad input, that's nothing to do with the driver's stack at this point etc., so the WARN_ON() doesn't add any value. Additionally, this is one of the top syzbot reports now. Just print a message, and as an added bonus, print the sizes too. | |||||
CVE-2025-38353 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix taking invalid lock on wedge If device wedges on e.g. GuC upload, the submission is not yet enabled and the state is not even initialized. Protect the wedge call so it does nothing in this case. It fixes the following splat: [] xe 0000:bf:00.0: [drm] device wedged, needs recovery [] ------------[ cut here ]------------ [] DEBUG_LOCKS_WARN_ON(lock->magic != lock) [] WARNING: CPU: 48 PID: 312 at kernel/locking/mutex.c:564 __mutex_lock+0x8a1/0xe60 ... [] RIP: 0010:__mutex_lock+0x8a1/0xe60 [] mutex_lock_nested+0x1b/0x30 [] xe_guc_submit_wedge+0x80/0x2b0 [xe] | |||||
CVE-2025-38373 | 2025-07-25 | N/A | N/A | ||
In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix potential deadlock in MR deregistration The issue arises when kzalloc() is invoked while holding umem_mutex or any other lock acquired under umem_mutex. This is problematic because kzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke mmu_notifier_invalidate_range_start(). This function can lead to mlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again, resulting in a deadlock. The problematic flow: CPU0 | CPU1 ---------------------------------------|------------------------------------------------ mlx5_ib_dereg_mr() | ? revoke_mr() | ? mutex_lock(&umem_odp->umem_mutex) | | mlx5_mkey_cache_init() | ? mutex_lock(&dev->cache.rb_lock) | ? mlx5r_cache_create_ent_locked() | ? kzalloc(GFP_KERNEL) | ? fs_reclaim() | ? mmu_notifier_invalidate_range_start() | ? mlx5_ib_invalidate_range() | ? mutex_lock(&umem_odp->umem_mutex) ? cache_ent_find_and_store() | ? mutex_lock(&dev->cache.rb_lock) | Additionally, when kzalloc() is called from within cache_ent_find_and_store(), we encounter the same deadlock due to re-acquisition of umem_mutex. Solve by releasing umem_mutex in dereg_mr() after umr_revoke_mr() and before acquiring rb_lock. This ensures that we don't hold umem_mutex while performing memory allocations that could trigger the reclaim path. This change prevents the deadlock by ensuring proper lock ordering and avoiding holding locks during memory allocation operations that could trigger the reclaim path. The following lockdep warning demonstrates the deadlock: python3/20557 is trying to acquire lock: ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at: mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib] but task is already holding lock: ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at: unmap_vmas+0x7b/0x1a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}: fs_reclaim_acquire+0x60/0xd0 mem_cgroup_css_alloc+0x6f/0x9b0 cgroup_init_subsys+0xa4/0x240 cgroup_init+0x1c8/0x510 start_kernel+0x747/0x760 x86_64_start_reservations+0x25/0x30 x86_64_start_kernel+0x73/0x80 common_startup_64+0x129/0x138 -> #2 (fs_reclaim){+.+.}-{0:0}: fs_reclaim_acquire+0x91/0xd0 __kmalloc_cache_noprof+0x4d/0x4c0 mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib] mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib] mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib] __mlx5_ib_add+0x4b/0x190 [mlx5_ib] mlx5r_probe+0xd9/0x320 [mlx5_ib] auxiliary_bus_probe+0x42/0x70 really_probe+0xdb/0x360 __driver_probe_device+0x8f/0x130 driver_probe_device+0x1f/0xb0 __driver_attach+0xd4/0x1f0 bus_for_each_dev+0x79/0xd0 bus_add_driver+0xf0/0x200 driver_register+0x6e/0xc0 __auxiliary_driver_register+0x6a/0xc0 do_one_initcall+0x5e/0x390 do_init_module+0x88/0x240 init_module_from_file+0x85/0xc0 idempotent_init_module+0x104/0x300 __x64_sys_finit_module+0x68/0xc0 do_syscall_64+0x6d/0x140 entry_SYSCALL_64_after_hwframe+0x4b/0x53 -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}: __mutex_lock+0x98/0xf10 __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib] mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib] ib_dereg_mr_user+0x85/0x1f0 [ib_core] ---truncated--- | |||||
CVE-2025-31955 | 2025-07-25 | N/A | N/A | ||
HCL iAutomate is affected by a sensitive data exposure vulnerability. This issue may allow unauthorized access to sensitive information within the system. | |||||
CVE-2025-8128 | 2025-07-25 | N/A | 6.3 MEDIUM | ||
A vulnerability, which was classified as critical, has been found in zhousg letao up to 7d8df0386a65228476290949e0413de48f7fbe98. This issue affects some unknown processing of the file routes\bf\product.js. The manipulation of the argument pictrdtz leads to unrestricted upload. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. This product takes the approach of rolling releases to provide continious delivery. Therefore, version details for affected and updated releases are not available. | |||||
CVE-2016-15044 | 2025-07-25 | N/A | N/A | ||
A remote code execution vulnerability exists in Kaltura versions prior to 11.1.0-2 due to unsafe deserialization of user-controlled data within the keditorservices module. An unauthenticated remote attacker can exploit this issue by sending a specially crafted serialized PHP object in the kdata GET parameter to the redirectWidgetCmd endpoint. Successful exploitation leads to execution of arbitrary PHP code in the context of the web server process. | |||||
CVE-2025-54294 | 2025-07-25 | N/A | N/A | ||
A SQLi vulnerability in Komento component 4.0.0-4.0.7for Joomla was discovered. The issue allows unprivileged users to execute arbitrary SQL commands. | |||||
CVE-2025-7695 | 2025-07-25 | N/A | 8.8 HIGH | ||
The Dataverse Integration plugin for WordPress is vulnerable to Privilege Escalation due to missing authorization checks within its reset_password_link REST endpoint in versions 2.77 through 2.81. The endpoint’s handler accepts a client-supplied id, email, or login, looks up that user, and calls get_password_reset_key() unconditionally. Because it only checks that the caller is authenticated, and not that they own or may edit the target account, any authenticated attacker, with Subscriber-level access and above, can obtain a password reset link for an administrator and hijack that account. |